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

From: "Allison, Art" <[email-masked]>
Date: Mon, 21 Jul 2008 09:09:07 -0400

Further, in some other SDOs, replacement of 'may'  with 'need not' has
been found to be helpful wording to clearly assert that something is
optional.
Art Allison

Director Advanced Engineering, Science and Technology
 
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981
www.nab.org

Advocacy  Education  Innovation

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On 
|Behalf Of Dave Singer
|Sent: Friday, July 18, 2008 4:40 PM
|To: [email-masked]
|Subject: Re: [AVT] I-D Action:draft-ietf-avt-rtp-svc-13.txt
|
|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
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt
|
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt