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

[<Ye-Kui.Wang at nokia.com>]

The first item has been discussed. Is it possible to have some feedback
on all other items?

BR, YK


>-----Original Message-----
>From: Wang Ye-Kui (Nokia-NRC/Tampere) 
>Sent: Thursday, March 27, 2008 11:40 PM
>To: IETF AVT WG
>Subject: Some comments to subsection 8.1.1 in 
>draft-ietf-avt-rtp-svc-08 
>
>
>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
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt