[AVT] Some comments to subsection 8.1.1 in draft-ietf-avt-rtp-svc-08

[<[e-mail]>]

Hi,

It's somehow funny for a co-author to send comments to the reflector.
However, as people interested in the draft know, we authors have deep
disagreement regarding this issue of decoding order recovery for session
multiplexing, and the issue has made the progress of this work very slow
for quite some time. I hope public discussions could be more helpful for
the group (i.e. AVT) to have a better common understanding of the issue.


Here are some comments to subsection 8.1.1 in draft-ietf-avt-rtp-svc-08,
titled "The Classical RTP Decoding Order Recovery Mode". Basically I
don't understand many details of the process described in the draft -
for those I could guess I have made some suggestions below on how to
improve the description. 

1. In the following copied text, NTP timestamps of NAL units or
operation point representations are mentioned. However, NAL units are
not directly assoicated with NTP timestamps, which are only directly
assoicated with RTCP SRs. The NTP timestamp for each NAL unit must be
defined.

"o NAL units with the same (RTP or NTP) timestamp are grouped in
decoding order to operation point representations in each RTP stream.

o Operation point representations with the same (NTP) timestamp  SHALL
be grouped to access units in order of the SVC RTP session dependency,
from lowest to highest."

2. Informative example, paragraph 1. The following sentence mentions
different session jitters. How are different session jitters seen from
the figure (and the description)?

"Figure 2. shows an example for buffering with different jitter between
sessions, i.e. at buffering startup not all packets of the same time
instance are available."

3. Informative example, paragraph 2. The first sentence says "The
process first proceeds to TS [8] and remove/ignore all preceding NAL
units in each of the buffers of RTP session A,B, and C." 
3.1. How does the process know that it proceeds to TS[8] and start
removing/ingoring stuff? Is it because that TS[8] is the first access
unit appearing in the buffer that has packets in all the sessions? If
yes, say so in the draft. 
3.2 This part of the process indicates that in the process additional
buffer is needed for each of the sessions to enable the finding of this
first access unit. 
3.3. In "and remove all preceding NAL units ...", "preceding" means in
what order (decoding order, presentation order or transmission order)? 
3.4. What are "the buffers"? Are they something that should be specified
by this document or they are implementation issues hence no need to be
specified? If implementation issue, what additional buffer sizes an
implmentation should typically prepare for this purpose?

4. Informative example, paragraph 2, sentence 2 (copied below). Wasn't
TS[1] removed accroding to the first sentence in this paragraph? If not,
which NAL units were actually removed by the first sentence in this
example?

"Then starting from session C, the first timestamp available in decoding
order (TS [1]) is selected and all operation point representations in
lower RTP sessions A and B are moved in order of the RTP session
dependency (in the example form session A -> B -> C) into the decoder."

5. Informative example, paragraph 2. Sentence 3 says "Then the next
timestamp in the highest RTP session C is selected and the process
described above is repeated."  The next timestamp in what order
(decoding order, presentation order or transmission order, or increasing
or decreasing of NTP timestamp order)?

6. Informative example, paragraph 2. Sentence 4 starts with "In case of
"real" packet loss at TS[4] and TS[2], ..." 
6.1. "packet loss" ->  "packet losses"?
6.2. Packet losses of which of the RTP sessions? Maybe it is easier to
list exactly which NAL units are lost.

7. I think the half-finished sentence "Decoding order and dependency of
NAL units per received RTP session with different jitter in sessions at
buffering startup time:" are there above Figure 2 should be removed or
better phrased. 

BR, YK
_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt