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

From: [email-masked]
Date: Fri, 1 Feb 2008 15:15:02 -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-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
[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.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sat, 16 Feb 2008 14:01:17 +0000

> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-07.txt

I had a couple of comments on section 8.1.1.  This section is much  
improved from the previous version, but is still unclear on what  
timestamp should be used for various stages of the process.  In  
particular, the bullets in part two need clarification:

      o NAL units with the same timestamp are grouped in decoding order
      to Operation Point representations in each RTP stream.

Since this refers to order within an RTP stream, I assume the RTP  
timestamp of the NAL units is used?

      o Operation Point representations with the same timestamp SHALL be
      grouped to access units in order of the RTP session dependency
      from lowest to highest Enhancement RTP session, where the highest
      Enhancement RTP session is the one which no other RTP session
      depends on and the lowest Enhancement RTP session may be the Base
      RTP session.

Since this is ordering data across RTP sessions, it presumably maps  
the RTP timestamp to an NTP format wall-clock value using the  
information contained in RTCP SR packets, and then uses those NTP  
format timestamps for ordering?

-- 
Colin Perkins
http://csperkins.org/

---

From: "Thomas Schierl" <[email-masked]>
Date: Sun, 17 Feb 2008 13:48:09 +0100

Colin Perkins writes
> format timestamps for ordering?

Your assumption is correct. As far as I understand RFC3550, NTP timestamps
SHOULD be used for inter session synchronization. Since random RTP timestamp
offsets SHOUDLD be used per RTP stream, the usage of RTP timestamps for any
inter session processing is not possible.

Actually 8.1.1. describes the usage of session multiplexing for a layered
video codec with RFC3550. Besides the requirement of using the SDP
dependency signaling instead of standard SDP RFC4566, 8.1.1. does only rely
on mechanisms defined in RFC3550. Thus, I still believe that this mode
should be always allowed, whatever the exact gain using any other method may
be.

Thomas Schierl
--------------
Fraunhofer HHI

----
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