[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] I-D Action:draft-ietf-avt-rtp-svc-13.txt
Hi Dave,
Thanks for your comments - which are helpful :-). See inline, please.
>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...
>
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.
>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).
>
Done. At some places "may not" has been changed to "may or may not".
>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]
>
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.
>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).
>
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 :-)
>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
>
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?
>5.6.1: [minor] says that the second new NAL unit is...but this is
>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.
>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.
>
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?
>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?
>
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.
>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.
>
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.
>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).
>
Agreed. We are working to improve in this aspect...
BR, YK
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt