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

From: [email-masked]
Date: Tue, 3 Jun 2008 02:30: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-10.txt
	Pages           : 79
	Date            : 2008-06-03

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. 

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-10.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: Colin Perkins <[email-masked]>
Date: Tue, 10 Jun 2008 12:35:17 +0100

> A New Internet-Draft is available from the on-line Internet-Drafts  
...
> 	Filename        : draft-ietf-avt-rtp-svc-10.txt

I have a few comments on this draft that are separate from the main  
open issues being discussed by the design team. Some of these are  
editorial, some are more substantive.

Section 3.2 talks about NAL unit types 15 and 20 before those NAL  
unit types have been introduced. The draft would be clearer if it  
contained a table of NAL unit types, showing which are defined in H. 
264, which in RFC 3984, which in SVC, and which in this draft. A good  
place for this table would be after the third paragraph of section 3.1.

The second paragraph of section 3.3 says "SVC extends the one-byte H. 
264/AVC NAL unit header by three additional octets". This implies  
that all types of NAL unit header are extended, which seems to be at  
odds with the later statement that "NAL unit types 14 and 20 indicate  
the presence of three additional octets in the NAL unit header".

The last paragraph of section 3.4 states that the semantics of the F  
bit are extended in section 6.4, but section 6.4 references RFC 3984  
without extension.

Section 5.1.1 defines the base layer as containing all the NAL units  
"with the nal_unit_type syntax element equals to 1 and 5". This  
should presumably be "1 or 5"?

The term "session multiplexing" (defined in section 4 and used  
throughout) is unfortunate, since it implies that sessions are  
somehow combined together a one single bundle, but is actually used  
to mean the opposite.

Following on from this, the definition of session multiplexing in  
section 5.1.2 is incorrect and prohibits bidirectional communication  
(it states that "each RTP session carries a single RTP packet stream"  
but a two-party video conferences is a single RTP session with two  
RTP packet streams: one from A to B, one from B to A).

I would suggest that the draft would be clearer, and more compliant  
with the RTP specification if, instead of talking about session  
multiplexing, it specified that the SVC bitstream can be distributed  
across multiple RTP packet streams, with each stream having a unique  
SSRC, and its own timestamp and sequence number spaces. Those  
multiple streams can be associated using the RTCP CNAME, or explicit  
signalling of the SSRC used. They can be multiplexed onto a single  
transport layer connection, or split across multiple transport layer  
connections, as appropriate. In all cases, you have a single RTP  
session (and hence a single SSRC space).

Section 6.1 uses the term "MANE" without definition. Needs a cross- 
reference to RFC 3984 (which, when RFC 3984bis is done, should  
specify that a MANE is an RTP translator in the RFC 3550 sense).

In section 6.5.1, why is the signalling for packetization modes  
defined in a number manner rather than using symbolic names? Also,  
why such long parameter names? Instead of:

   a=fmtp:96 session-multiplexing-packetization-mode=0 ...

I would have thought that something like:

   a=fmtp:96 pmode=NI-T ...

would be clearer?

In section 9.1, the media subtype needs to be "H264-SVC" not "H264- 
SVC or H264", since this is a registration for the H264-SVC type. The  
paragraph specifying which subtype should be used for which type of  
stream should be moved out of the media type registration.

SDP examples in section 9.3 are all incorrect, since they include  
white space around the = sign. Each example should be made into a  
complete SDP file, and the \ characters at the end of lines should be  
removed.

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