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

From: [email-masked]
Date: Fri, 26 Sep 2008 04:15:01 -0700 (PDT)

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-14.txt
	Pages           : 96
	Date            : 2008-09-26

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 RFC 3984 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 RFC 3984 
as each individual session still uses a packetization mode defined 
in RFC 3984.  The packetization modes defined in RFC 3984 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 RFC 3984 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 RFC 3984.  
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-14.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: Fri, 26 Sep 2008 14:33:48 +0300

Hi All,

Detailed changes compared to -13 are listed in the Changes Log section.
We authors think that the text for all the sections until section 7 (on
signaling) is now in a good shape. Therefore, reviews to sections until
section 7 are solicited. For the signaling part, we plan to make text
for RFC3984bis available first (the current plan is to submit the next
RFC3984bis draft - WG version 00 by 6 Oct.), then signaling text for
this SVC draft will be made and submitted as -15. 

BR, YK

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext [email-masked]
>Sent: 26 September, 2008 14:15
>To: [email-masked]
>Cc: [email-masked]
>Subject: [AVT] I-D Action:draft-ietf-avt-rtp-svc-14.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 
>transmission the packetization modes of RFC 3984 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 RFC 3984 as each individual 
>session still uses a packetization mode defined in RFC 3984.  
>The packetization modes defined in RFC 3984 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 RFC 3984 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 RFC 3984.  
>The payload format has wide 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.
>