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

From: [email-masked]
Date: Mon, 14 Jul 2008 11:30:02 -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-13.txt
	Pages           : 86
	Date            : 2008-07-14

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 
streams the packetization modes of RFC 3984 are used, whereas for 
multi-session streams four different packetization modes are defined 
in this memo.  The multi-session packetization modes extend the 
packetization modes defined in RFC 3984.  The payload format is 
backwards compatible to RFC 3984, and 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-13.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: Dave Singer <[email-masked]>
Date: Fri, 18 Jul 2008 13:39:53 -0700

I did a one-pass review on this, this week.  Here are some comments, 
I hope they are helpful.

Minor comment:  it needs spell-checking ('bistream'), consistency of 
pucntuation (both double-quote " and two single-quotes '' are used), 
page-break checking (doesn't XML2RFC stop page breaks after heading 
or before captions?), and english ('allows to stop' -> 'allows 
stopping', and so on, and subjunctive 'would be' should be 'were' in 
a few places).  Also, in 3.2:  the table isn't aligned...

Less minor:  it uses 'may not' to express that something is permitted 
not to happen, which it not the common english usage and hence is at 
best ambiguous.  Please change this to "It is permissible to not" or 
"The absence of X is permitted..." or the like (several places).

3.1.2:  I don't understand the first few sentences at all.  [Not that 
I wish to imply that I understood all other sentences]

3.1.2:  AVC base layer:  surely an AVC base layer can reasonably 
contain prefix NAL units, as an AVC reader will ignore them and they 
are small and harmless.  However, it shouldn't contain SVC coding NAL 
units (type 20).

5.5.2:  says that I-C allows interleaving and thus is OK if latency 
isn't an issue, but it should say what advantage it offers, as well

5.6.1:  [minor] says that the second new NAL unit is...but this is 
the first new one in document order

major comment:  the PACSI seems, at first reading, a mess.  much of 
its documentation seems to imply that it can encapsulate other coding 
NAL units, but the intro says it can contain SEIs only.  However, I 
feel that that is a mess too;  it's a mistake to have fields and 
inclusions in the same NAL unit.  suggest saying that a PACSI is just 
the fields, but it's OK to be placed into a STAP if it must be 
grouped with SEIs or other NAL units.  maybe I need to re-0read this 
section.

major comment:  it would be good to discuss the placement of prefix 
NAL units in the AVC compatible base layer.  Can single-NAL RTP 
packets be used?  where does the prefix go?  if it's consistent for 
all the NALs in this layer, how about in the signalling?  or a header 
extension?  or must STAPs be used all the time?

overall:  this document is rather large;  does it need to be this 
complex?  especially since it effectively augments 3984, the overall 
material here is huge.  and hard to check mentally...this is just one 
read-through, and to check that it's consistent would take many many 
days.  I worry about RTP if this is the way we are going.

overall:  it desperately needs an introduction, explaining roughly 
how SVC streams would be sent in various scenarios, and what the 
motivation for the new structures is, and so on.  As it is, we plunge 
into new structures and so on without a clear roadmap of the problems 
we are solving (or the opportunities we are presenting).

I hope this helps.

-- 
David Singer
Apple/QuickTime

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 16:30:38 +0300

Hi Dave,

Thanks for your comments - which are helpful :-). See inline, please. 

>a few places).  Also, in 3.2:  the table isn't aligned...

Done, except for 1) page-breaking - will be checked later on, and 2)
"the table isn't algined..." - I don't understand this comment. Section
3.2 has no table. 

>"The absence of X is permitted..." or the like (several places).

Done. At some places "may not" has been changed to "may or may not".

>I wish to imply that I understood all other sentences]

I found no problem in those sentences. Obviously the reason that they
are not so easy to understand is the use of terms from the SVC coding
standard. But how can we do otherwise? Redefine the terms in the coding
spec? But that would probably cause more confusions. Anyway, improving
suggestions are welcome. 

>are small and harmless.  However, it shouldn't contain SVC coding NAL 

The term as it is defined, which is the same as in the SVC coding
standard, does not prohibit you from sending prefix NAL units to
H.264/AVC decoders. The way it is defined makes it easier to describe
things in the draft (and in the SVC coding standard as well). You will
probably agree with this after your second-pass review :-) 

>isn't an issue, but it should say what advantage it offers, as well

Added "The benefits of allowing interleaving are the same as that of the
Interleaved Mode specified in RFC 3984." Do we need to be more specific
to repeat what was said in RFC 3984? 

>the first new one in document order

Changed to "One new NAL unit ...". The language will be further tuned
after including text for NAL unit type extensions agreed earlier. 

>grouped with SEIs or other NAL units.  maybe I need to re-0read this 

I don't see text in draft saying that PACSI can encapsulate other NAL
units than SEIs. What is wrong to have both fields and possible
inclusion of SEI NAL units? Aren't STAPs and MTAPs in RFC 3984 the same?

>extension?  or must STAPs be used all the time?

I think most of these aspects are discussed in the draft. For example,
rules for  prefix NAL units are discussed in sections 6.1 (for
single-session transmission) and 6.2 (for multi-session transmission).
It should be clear that it is possible to use other packets than STAPs,
depending on the transmission mode (SST or MST) and the packetization
modes (both MST modes and session modes) in use. 

I don't understand the questions about signaling or header extension. 

>days.  I worry about RTP if this is the way we are going.

I guess your impression of the complexity of the draft has changed, more
or less, after the discussion in Hannover last week. Anyway,
simplification suggestions are warmly welcome.  

>we are solving (or the opportunities we are presenting).

Agreed. We are working to improve in this aspect...

BR, YK