[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] I-D Action:draft-ietf-avt-rtp-svc-19.txt
Hi YK,
Thanks for the response. I have been looking into
sprop-operation-point-info in more detail, but I unclear on a few key
concepts that I hope you can clarify for me. Taking the example in
7.3.2, the following sprop-operation-point-info may be offered.
a=rtpmap:97 H264-SVC/90000
a=fmtp:97 profile-level-id=53000c; packetization-mode=1;
sprop-parameter-sets={sps0},{sps1},{pps0},{pps1};
sprop-operation-point-info=<1,0,0,0,4d400a,3200,176,144,128,
256>,<2,1,1,0,53000c,6400,352,288,256,512>;
First, take the simple case in which the receiver supports SVC and wants
to choose the highest operation point. In this case, the answer includes
scalable-layer-id=2. Does this imply that a base layer should be sent
corresponding to scalable-layer-id=1, with one of more enhancement
layers being sent to a maximum of scalable-layer-id=2?
If the receiver supports something higher than scalable-layer-id=1 but
lower than scalable-layer-id=2, does it respond with scalable-layer-id=1
and send a base layer corresponding to scalable-layer-id=1 but send one
of more enhancement layers exceeding that defined for
scalable-layer-id=1, or does it respond with scalable-layer-id=2 and
send a base layer corresponding to scalable-layer-id=1 and one or more
enhancement layers but stops short of that defined for
scalable-layer-id=2.
Is it legal to include more than two operation points in the
sprop-operation-point-info? The following text makes it sound to me as
if there is a limit of two.
If the sprop-operation-point-info is followed by exactly one
operation-
point-description vector, this describes the highest operation
point contained in the RTP session. If there are exactly two
operation-point-description vectors, the first describes the
lowest and the second describes the highest operation point
contained in the RTP session.
Thanks,
Charles
> -----Original Message-----
> From: Ye-Kui Wang [mailto:yekuiwang at huawei.com]
> Sent: Wednesday, October 21, 2009 7:04 AM
> To: Charles Eckel (eckelcu); avt at ietf.org
> Subject: RE: [AVT] I-D Action:draft-ietf-avt-rtp-svc-19.txt
>
>
> Once you are able to signal layering scheme in SDP, you are able to
> negotiate layering scheme. To indicate specific resolution and frame
rate
> values, you can use the media type parameter
sprop-operation-point-info.
> When providing an SVC stream, it is by default (and mandated) that the
base
> layer is AVC compatible. Therefore I don't see anything missing.
>
> If the above does not answer your question well, perhaps you could try
to
> re-elaborate your question.
>
> BR, YK
>
> > -----Original Message-----
> > From: Charles Eckel (eckelcu) [mailto:eckelcu at cisco.com]
> > Sent: Tuesday, October 20, 2009 6:59 PM
> > To: Ye-Kui Wang; avt at ietf.org
> > Subject: RE: [AVT] I-D Action:draft-ietf-avt-rtp-svc-19.txt
> > Importance: Low
> >
> > Perhaps I am missing some fundamental aspects of the draft;
> > however, in reading over it, I do not understand how one
> > would convey the desired layering scheme. For example, if
> > when using SVC it is desired for the base layer to be AVC
> > compatible with a given resolution and frame rate, then for
> > temporal and spatial enhancement layers to be added on top,
> > how would one signal that. The example in section 7.3.1
> > illustrates offering an AVC compatible stream and an SVC
> > compatible stream; however, it does not illustrate how to
> > request that if SVC is supported (97) a specific layering
> > scheme is used that includes an AVC compatible base layer
> > with a specific resolution and frame rate.
> > Being able to negotiate the layering scheme in SDP seems useful to
me.
> > Was this considered?
> >
> > Thanks,
> > Charles
> >
> > > -----Original Message-----
> > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > Behalf Of
> > Ye-Kui Wang
> > > Sent: Thursday, September 17, 2009 9:57 AM
> > > To: avt at ietf.org
> > > Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-svc-19.txt
> > >
> > >
> > >
> > > Changes compared to -18 are list below, among other minor
editorial
> > changes:
> > >
> > > - alignment of recent changes to the RFC 3984bis draft
> > > - update of some references for which the RFCs are now available
> > > - SDP examples are now in line with RFC5583
> > > - change of Stephan's affiliation and address
> > > - change of Thomas' email address
> > >
> > > I hope Chairs could issue a second WGLC for this draft.
> > >
> > > BR,YK
> > >
> > > > -----Original Message-----
> > > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]
> > On Behalf
> > > > Of Internet-Drafts at ietf.org
> > > > Sent: Thursday, September 17, 2009 12:45 PM
> > > > To: i-d-announce at ietf.org
> > > > Cc: avt at ietf.org
> > > > Subject: [AVT] I-D Action:draft-ietf-avt-rtp-svc-19.txt
> > > >
> > > > A New Internet-Draft is available from the on-line
> > Internet-Drafts
> > > > directories.
> > > > This draft is a work item of the Audio/Video Transport
> > Working Group
> > > > of the IETF.
> > > >
> > > >
> > > > Title : RTP Payload Format for SVC Video
> > > > Author(s) : S. Wenger, et al.
> > > > Filename : draft-ietf-avt-rtp-svc-19.txt
> > > > Pages : 103
> > > > Date : 2009-09-17
> > > >
> > > > This memo describes an RTP payload format for Scalable
> > Video Coding
> > > > (SVC) as defined in_Annex G of ITU-T Recommendation
> > H.264, which is
> > > > technically identical to Amendment 3 of ISO/IEC International
> > > > Standard 14496-10. The RTP payload format allows for
> > packetization
> > > > of one or more Network Abstraction Layer (NAL) units in each RTP
> > > > packet payload, as well as fragmentation of a NAL unit in
> > multiple
> > > > RTP packets.
> > > > Furthermore, it supports transmission of an SVC stream
> > over a single
> > > > as well as multiple RTP sessions. The payload format
> > defines a new
> > > > media subtype name "H264-SVC", but is still backwards
> > compatible to
> > > > [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when
> > > > encapsulated in its own RTP stream, must use the H.264
> > media subtype
> > > > name ("H264") and the packetization method specified in [I-
> > > > D.ietf-avt-rtp-rfc3984bis]. The payload format has wide
> > > > applicability in videoconferencing, Internet video streaming,
and
> > > > high bit-rate entertainment-quality video, among others.
> > > >
> > > > A URL for this Internet-Draft is:
> > > >
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-19.txt
> > > >
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > >
> > > > Below is the data which will enable a MIME compliant mail reader
> > > > implementation to automatically retrieve the ASCII version of
the
> > > > Internet-Draft.
> > > >
> > >
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > avt at ietf.org
> > > https://www.ietf.org/mailman/listinfo/avt
> >
>