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

From: [email-masked]
Date: Tue, 16 Dec 2008 04:45: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-16.txt
	Pages           : 103
	Date            : 2008-12-16

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.  For single-session 
transmission the packetization modes of [I-D.ietf-avt-rtp-
rfc3984bis] are used.  For multi-session transmission four different 
modes are defined in this memo.  The modes differ depending on 
whether the SVC data are allowed to be interleaved, i.e., to be 
transmitted in an order different than the intended decoding order, 
and they also differ in the mechanisms provided in order to recover 
the correct decoding order of the NAL units across the multiple RTP 
sessions.  Specifically, decoding order recovery is performed using 
either timestamp alignment or Cross-Session Decoding Order Numbers 
(CS-DON), although in one of the modes both schemes are used in 
order to allow receivers to use their preferred method.  The multi-
session transmission modes use the packetization modes defined in 
[I-D.ietf-avt-rtp-rfc3984bis] as each individual session still uses 
a packetization mode defined in [I-D.ietf-avt-rtp-rfc3984bis].  The 
packetization modes defined in [I-D.ietf-avt-rtp-rfc3984bis] are 
slightly extended such that the three new NAL unit types defined in 
this memo can be included in the RTP packet streams.  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 
Copyright Notice..................................................1 
Abstract..........................................................2

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-16.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
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Tue, 16 Dec 2008 15:11:19 +0200

Dear All,

We authors think that the draft is now ready for WGLC. Comments are
solicited. 

Changes from -15:
-	Added a reference to [I-D.perkins-avt-rapid-rtp-sync]
-	Updated the semantics of the sprop-operation-point-info
parameter
-	Updated the usage of sprop-operation-point-info,
sprop-scalability-info in SDP Offer/Answer
-	Added the usage rule of sprop-layer-id in SDP Offer/Answer
-	Added some SDP Offer/Answer examples
-	Updated the MST and SST definitions
-	Updated SSRC setting for MST
-	Removed the sprop-ssrc parameter
-	Added that sprop-parameter-sets and sprop-level-parameter-sets
may be conveyed using the "fmtp" source attribute as specified in
section 6.3 of [I-D.ietf-mmusic-sdp-source-attributes].
-	Added the usage of sprop-parameter-sets and
sprop-level-parameter-sets when conveyed using the "fmtp" source
attribute in SDP Offer/Answer.
-	Updated the parameter set considerations section (7.4)
-	Updated the IANA consideration section (10)
-	Updated the text for the informative application example on
mobile TV (section 11.4) 
-	Added section 12 and acknowledgements therein (some moved from
elsewhere)
-	Added a reference to [I-D.ietf-mmusic-sdp-source-attributes]
-	Updated Table 13 to make it more clear which combinations
correspond to the same sub-profile
-	Updated Section 9, Congestion Control
-	Added the text for 11.4, Videoconferencing application example
-	Added informative references to G.114 and Packet Video workshop
paper
-	Updated the summary rules for the usage of parameters in
offer-answer so that the cases where "scalable-layer-id" is used are
listed separately. 
-	Removed open issues and changes log

BR, YK

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext [email-masked]
>Sent: 16 December, 2008 14:45
>To: [email-masked]
>Cc: [email-masked]
>Subject: [AVT] I-D Action:draft-ietf-avt-rtp-svc-16.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.  For single-session 
>rfc3984bis] are used.  For multi-session transmission four 
>different modes are defined in this memo.  The modes differ 
>depending on whether the SVC data are allowed to be 
>interleaved, i.e., to be transmitted in an order different 
>than the intended decoding order, and they also differ in the 
>mechanisms provided in order to recover the correct decoding 
>order of the NAL units across the multiple RTP sessions.  
>Specifically, decoding order recovery is performed using 
>either timestamp alignment or Cross-Session Decoding Order 
>Numbers (CS-DON), although in one of the modes both schemes 
>are used in order to allow receivers to use their preferred 
>method.  The multi- session transmission modes use the 
>packetization modes defined in [I-D.ietf-avt-rtp-rfc3984bis] 
>as each individual session still uses a packetization mode 
>defined in [I-D.ietf-avt-rtp-rfc3984bis].  The packetization 
>modes defined in [I-D.ietf-avt-rtp-rfc3984bis] are slightly 
>extended such that the three new NAL unit types defined in 
>this memo can be included in the RTP packet streams.  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 
>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.
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 16 Dec 2008 09:02:15 -0500

Congratulations to the team for all their hard work. I think I'll run the WGLC 
after the holidays to provide just a little more digestion time. One or two 
other items are in the queue for WGLC first.