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

From: "Thomas Schierl" <[email-masked]>
Date: Sat, 2 Feb 2008 00:25:16 +0100

Dear all,

We just submitted version -07 of the RTP Payload for SVC video.
Major changes and updates can be found in section 4, 5.1.2, and 8.
See also open issues (section 21) and the change log (section 22).

Regards,
Thomas

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Saturday, February 02, 2008 12:15 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] I-D Action:draft-ietf-avt-rtp-svc-07.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-07.txt
> 	Pages           : 73
> 	Date            : 2008-02-01
>
> This memo describes an RTP payload format for scalable video coding
> (SVC) defined in_Annex G of the ITU-T Recommendation H.264 video codec
> 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, produced by the
> video encoder, in each RTP packet payload.  The payload format has wide
> applicability, such as low bit-rate conversational, Internet video
> streaming, or high bit-rate entertainment quality video.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-07.txt
>
> To remove yourself from the I-D Announcement list, send a message to i-
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-avt-rtp-svc-07.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-
> sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-avt-rtp-svc-07.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

----
Visit us at

GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February 2008 / Broadcast Mobile Convergence Forum / Booth 2B82
http://www.mobileworldcongress.com/homepage.htm

OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / Booth 411/415
http://www.ofcnfoec.org
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: "LEPROVOST YANN" <[email-masked]>
Date: Mon, 4 Feb 2008 17:09:10 +0100

Folks,

I have a comment regarding the method proposed for "classical RTP Decoding Order Recovery Mode".

In 7.1, I. a. is written:
"If an access unit of sampling time instance X is present in RTP session A, this access unit MUST be also present in any RTP session, which depends on RTP session A."
And "Informative note:  Restriction a. may be achieved for pre-encoded content by inserting filler data NAL units (of NAL unit type equal to 12 decimal) as defined in [SVC].  This insertion can be achieved by encoders, servers, as well as by MANEs."

IMHO, this limitation can be addressed without using extra-bandwidth and extra-processing due to Filler NAL units by considering the knowledge of frame rates contained in each RTP sessions. 
Currently, the proposed process is based on the fact that next access unit timestamp is retrieved by reading the next RTP packet in sequence number order of the highest dependent RTP session, which should be also the session of highest frame rate (really or by using filler data NAL units to simulate access units in highest session). In my view, it would be better to use the knowledge of frame rates contained in SDP (a=framerate), in order to get the RTP session where to find the TS of the next access unit in decoding order. Hence, there is no limitation on the distribution of frame rates along RTP sessions, and there is no need to use filler NAL units. If, a=framerate lines are not present in SDP, it is possible to compute the frame rates of each RTP sessions, by computing the minimun TS difference between any RTP packets in each buffer... but using SDP is an easier way to proceed.

The proposed method also handles the case of packet loss and address the limitation that was present in draft version 6, problem which is no more explicitly addressed in draft version 7. In draft 6, we found the following limitation: "Informative note: In case of packet loss, the essential connection between RTP sessions and packets cannot be kept, for that reason, we propose the reduce the reordering process only up to the session which the packet loss contains.  After finding a S0 Synchronization point, the reordering can be applied without restrictions."
As I understand, packets associated to sessions Sx (Sx>Sy) are not outputted to the decoder after a packet loss is detected in session Sy, until a new S0 synchronisation point is retrieved... I think it is important to output any well received packets of any session because it can be useful for SVC decoder using error concealment technics. This is possible, in my view, using the following process.

The proposed process consists of two steps:
1) identify the session of highest frame rate (using SDP a=framerate lines) and retrieve the next packet of the RTP buffer associated to the session with highest frame rate. This packet belongs to the next access unit in decoding order and thus we get its associated TS value. The selection of the session of highest frame rate should take into account packet losses, in order to not skip an access unit when a packet loss occurs in the session of highest frame rate. Hence, I suggest to select the session Ssync as the session of highest frame rate among sessions where no packet loss detection occurs for current access unit. The process to determine Ssync is repeated for each new access unit.
2) output all packets of same TS value (output of step 1) across sessions using the session dependency path defined by SDP. This is equivalent to the reordering process currently defined in draft 6 and 7, except the fact that reordering process is not reduced only up to the session which the packet loss contains. With this last method, all received NAL units are sent to the SVC decoder in the correct decoding order, enabling error concealment technics within each scalable layers.

The full method is depicted in a PPT presentation (that I will try to send in a separate mail for approval by moderators, or I can send indivually to anyone interested).

Regards

Yann Leprovost

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Thomas Schierl
Envoyé : samedi 2 février 2008 00:25
À : [email-masked]
Cc : [email-masked]; 'Even, Roni'; [email-masked]; [email-masked]
Objet : [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-07.txt

Dear all,

Regards,
Thomas

> This draft is a work item of the Audio/Video Transport Working Group 
> of the IETF.
>
>
> video encoder, in each RTP packet payload.  The payload format has 
> wide applicability, such as low bit-rate conversational, Internet 
> video streaming, or high bit-rate entertainment quality video.
>
> To remove yourself from the I-D Announcement list, send a message to 
> i- [email-masked] with the word unsubscribe in the body 
> of the message.
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers

----
Visit us at

GSMA Mobile World Congress / Barcelona, Spain / 11 - 14 February 2008 / Broadcast Mobile Convergence Forum / Booth 2B82 http://www.mobileworldcongress.com/homepage.htm

OFC 2008 / San Diego, California, USA / 26 - 28 February 2008 / Booth 411/415 http://www.ofcnfoec.org _______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt