Subject: [AVT] I-D Action:draft-ietf-avt-rtp-svc-17.txt

From: [email-masked]
Date: Mon, 23 Feb 2009 09:15:01 -0800 (PST)

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-17.txt
	Pages           : 101
	Date            : 2009-02-23

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. 

Table of Contents 

Status of this Memo...............................................1 
Abstract..........................................................2

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-17.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.

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 23 Feb 2009 14:04:03 -0500

We have addressed all the WGLC comments sent to the mailing list, as well as
some comments for the 3984bis draft but also affecting this draft. Many
thanks again to all who have reviewed this draft and provided WGLC comments!

Here is a summary of our responses to all the WGLC comments:

******************************************************
*  Start of WGLC Comments and responses  *
******************************************************

*** Colin Perkins 1/17/09:

       As Roni mentioned, the abstract is too long. I suggest keeping the
first
       and last sentences, and deleting the rest.

Ok, done.

       In Section 1, on page 5, the informative note suggests that a MANE
can
       convert a media stream from SVC to H.264/AVC "simply by eliminating
RTP
       packets", provided the stream is structured in a particular way. This
is
       not correct: the MANE is an RTP translator, and so must follow the
rules
       defined in Section 7 of RFC 3550, which mandate rewriting RTCP to
match
       changes made to the RTP stream.

Ok, done.

	Similarly, RFC 3550 section 7 should be referenced from the last
	bullet point of Section 1.2.1, and from section 3.1.2 at the top of
	page 21.

Ok, done.

	Editorial: Section 4.7.1, bottom of page 35, do you mean figure 2,
	rather than figure 3?

Done.

	The discussion of NI-T and NI-TC packetization rules in section
5.2.1
	is unclear in places. In particular:

	- The paragraph after the bullet list on page 49 (starting "If a
            packet must be inserted for satisfying...") could be clarified.
RTP
            packets don't directly contain an NTP timestamp. It might be
better
            phrased as "...the inserted packet must have an RTP timestamp
that
            maps to the same wall-clock (NTP-format) time as the RTP
timestamp
            of a packet of the access unit..."

Ok, done.

	  - The discussion at the end of page 50 and start of page 51,
showing
              how to generate the timestamp for the inserted packet looks
              correct, but I'm not sure it's helpful. The calculation seems
to
              be that which a receiver would do to estimate the timestamp. A
              sender would, on the other hand, know the exact mapping from
              wall-clock (NTP) time to RTP time, and so doesn't need to
              calculate the correct offset from the RTCP SR packets.

We considered that this calculation may have to be done be a MANE, and
that's why it was included. The text is left as-is.

	     - It would be helpful, I think, if section 5.2.1 explained that
                 the mapping between wall-clock (NTP format) timestamps and
RTP
                 timestamps is conveyed from sender to receiver using RTCP
SR
                 packets, or the RTP proposed header extensions.

Ok, done.

	Following on from this, the informative note in section 6.2.1 (page
	54) would perhaps be clearer written as "The mapping between RTP and
	NTP format timestamps is conveyed in RTCP SR packets. In addition,
the
	mechanisms for faster media timestamp synchronisation discussed in
	[...] may be used to speed to acquisition of the RTP-to-wall-clock
	mapping".

Ok, done. We moved the changed informative note to section 5.2.1.

	Also in section 6.2.1, second bullet point on page 55, clarify that
	the "media timestamp" is the NTP-format timestamp derived from the
RTP
	timestamps of the NAL units.

Ok, done.

	Section 7.2.3 discusses how to signal multi-session transmissions of
	SVC in SDP. RFC 4566 section 5.7 defines an alternative mechanism to
	signal such sessions. Is it legal for that alternative to be used?
If
	so, if should be referenced, if not, this draft should explicitly
	prohibit that use.

Done. We explicitly prohibited it.

       Section 11.6 disallows "SSRC multiplexing", but the discussion of MST
in
       section 1.2.2 seems to allow it. I see no reason to disallow it.

Section deleted, since it discusses technical background- it's not an
example, and it's not a specification item.

*** Roni Even (Sri Dharmasanam), 1/16/09:

      The paragraph "The term "layer" is used in various ..." can be moved
      higher up so that its clarified sooner before being used in the doc.

OK, done.

      What does "forbidden_zero_bit" mean and how is it diff from
      "reserved_one_bit" aside from the fact that one must be zero and the
      other one?

These are specified by the SVC coding spec, the payload draft, we only
summarize them. The situation in the coding spec is as follows. The
"forbidden_zero_bit" is specified there as "unspecified", and
"reserved_one_bit" is specified as "reserved". System specs, e.g. RTP
payload format, can specify those fields unspecified in the coding spec, but
must never touch those fields reservied in the coding spec. The value being
zero or one may be randomly chosen, and may also be chosen to avoid
emulation of start codes. 

       "MANEs can aggregate multiple RTP streams, possibly from multiple RTP
      sessions". Not sure if a clear distinction of RTP stream and RTP
session
      has been made.

The distinction is clear per RFC 3550. There may multiple RTP streams
involved one RTP session, wherein all the RTP streams share the same SSRC
value space.

*** Jonathan Lennox, 1/16/09

     Section 4.9 (PACSI), p. 38, first full paragraph following the figure:
     As mentioned later, the bits S and E are defined if the bit Y is 1, not
     if the bit X is 1.  I suggest the wording:

     The bits A, P, and C are specified only if the bit X is equal to 1.
The
     fields TL0PICIDX and IDRPICID are present, and the bits S and E are
     specified, only if the bit Y is equal to 1.

Ok, done.

     Section 5.1 (Packetization rules for SST), p. 47, Paragraph 3
     (Informative note):  This note should mention NI-MTAP as well.

Ok, done.

     Section 7.2.1 (Mapping of Payload Type Parameters to SDP):  I believe
it
     would be useful to be able to represent sprop-scalability-info and
     sprop-operation-point-info in the fmtp source attribute as well.  I
     don't currently see any motivation for including
     sprop-no-NAL-reordering-required or sprop-avc-ready in the fmtp source
     attribute, but they might be worth considering.

Ok, we have enabled all the four parameters to be source specific.

     Editorial: Section 1.1.2, p. 7, third para, last line:
     "conforming to one or more of the profile specified in"... should be
     "profiles"

Ok, done.

     Section 4.3, p. 26, 2nd paragraph: "Fragment Unit" should be
     "Fragmentation Unit".

Ok, done.

******************************************************
*  End of WGLC Comments and responses    *
******************************************************

BR, YK
(on behalf of all authors)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Monday, February 23, 2009 12:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] I-D Action:draft-ietf-avt-rtp-svc-17.txt
> 
> (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- 
> applicability in videoconferencing, Internet video streaming, 
> and high bit-rate entertainment-quality video, among others. 
> 
>  
> 
> Table of Contents 
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>