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

<Ye-Kui.Wang@nokia.com> Sun, 06 April 2008 09:04 UTC

Return-Path: <avt-bounces@ietf.org>
X-Original-To: avt-archive@optimus.ietf.org
Delivered-To: ietfarch-avt-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3263A6A7F; Sun, 6 Apr 2008 02:04:11 -0700 (PDT)
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5AE3A6B58 for <avt@core3.amsl.com>; Sun, 6 Apr 2008 02:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.134
X-Spam-Level:
X-Spam-Status: No, score=-4.134 tagged_above=-999 required=5 tests=[AWL=2.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grE5RleziVqK for <avt@core3.amsl.com>; Sun, 6 Apr 2008 02:04:08 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 087DB3A6A87 for <avt@ietf.org>; Sun, 6 Apr 2008 02:04:07 -0700 (PDT)
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3694EPQ022192 for <avt@ietf.org>; Sun, 6 Apr 2008 12:04:15 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Apr 2008 12:04:14 +0300
Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Apr 2008 12:04:14 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 06 Apr 2008 12:04:11 +0300
Message-ID: <44C96BEE548AC8429828A37623150347727907@vaebe101.NOE.Nokia.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Some comments to subsection 8.1.1 in draft-ietf-avt-rtp-svc-08
Thread-Index: AciPlXXfu5lqKGNNR3OHb/YaJWawggAs/CqwAd7ZOvA=
References: <70765B7ABD04E845863F69CAC91A5ADB01B0DAA4@Xms1.etsihq.org><12919642-CFC2-492C-9FC0-E1381B30CBFA@csperkins.org><1FEB9B9F2EC38343955D02B2AE86AACB7656DF@lan-ex-02.panasonic.de><50365D40-4B93-4B00-A68D-10BF08468D6D@csperkins.org><1FEB9B9F2EC38343955D02B2AE86AACB7FD805@lan-ex-02.panasonic.de> <8BD6448C-729E-4565-990F-8602B931ABE1@csperkins.org>
From: Ye-Kui.Wang@nokia.com
To: avt@ietf.org
X-OriginalArrivalTime: 06 Apr 2008 09:04:14.0653 (UTC) FILETIME=[2FCF5ED0:01C897C5]
X-Nokia-AV: Clean
Subject: Re: [AVT] Some comments to subsection 8.1.1 in draft-ietf-avt-rtp-svc-08
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: avt-bounces@ietf.org
Errors-To: avt-bounces@ietf.org

 
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@ietf.org
https://www.ietf.org/mailman/listinfo/avt