RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-04.txt

<Ye-Kui.Wang@nokia.com> Fri, 04 January 2008 18:43 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArWL-00047k-D2; Fri, 04 Jan 2008 13:43:53 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JArWJ-00047f-LC for avt@ietf.org; Fri, 04 Jan 2008 13:43:51 -0500
Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JArWI-0001F1-1Y for avt@ietf.org; Fri, 04 Jan 2008 13:43:51 -0500
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m04IgifR010139; Fri, 4 Jan 2008 20:43:45 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 20:43:43 +0200
Received: from vaebe101.NOE.Nokia.com ([10.160.244.11]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Jan 2008 20:43:43 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-04.txt
Date: Fri, 04 Jan 2008 20:43:42 +0200
Message-ID: <44C96BEE548AC8429828A37623150347169750@vaebe101.NOE.Nokia.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C0537C54E@IsrExch01.israel.polycom.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-04.txt
Thread-Index: AchLFgN9xL59/TwnTg6hvtnYmPKN/QCTxBDgACklUHAAFG6f4AAeO5FAAAp806A=
References: <44C96BEE548AC8429828A37623150347169103@vaebe101.NOE.Nokia.com> <144ED8561CE90C41A3E5908EDECE315C0537C54E@IsrExch01.israel.polycom.com>
From: Ye-Kui.Wang@nokia.com
To: roni.even@polycom.co.il, schierl@hhi.fhg.de, csp@csperkins.org
X-OriginalArrivalTime: 04 Jan 2008 18:43:43.0881 (UTC) FILETIME=[BB77C790:01C84F01]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07
Cc: avt@ietf.org, tom.taylor@rogers.com
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.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://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

Hi Roni,

Ah, I overlooked this. You are right, we should say "Receivers SHOULD
ignore the value of RR." 

BR, YK 

>-----Original Message-----
>From: ext Even, Roni [mailto:roni.even@polycom.co.il] 
>Sent: Friday, January 04, 2008 3:22 PM
>To: Wang Ye-Kui (Nokia-OCTO/Tampere); schierl@hhi.fhg.de; 
>csp@csperkins.org
>Cc: avt@ietf.org; tom.taylor@rogers.com
>Subject: RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-04.txt 
>
>YK,
>
>- Regarding the RR bits, if you meant for the difference 
>between "Receivers SHOULD discard NAL units with RR not equal 
>to '11'." in the payload draft and "Decoders shall ignore the 
>value of reserved_three_2bits." in the SVC spec, then I would 
>say that having the difference is correct, because herein the 
>intention is to specify the RTP receiver's operation not the 
>decoder's operation, and "SHOULD"
>should be used in stead of "SHALL".
>
>There is a major difference here. According to the text in SVC 
>you do not discard NAL which do not have 11 you just ignore the field.
>
>Roni
>
>> -----Original Message-----
>> From: Ye-Kui.Wang@nokia.com [mailto:Ye-Kui.Wang@nokia.com]
>> Sent: Friday, January 04, 2008 1:46 AM
>> To: Even, Roni; schierl@hhi.fhg.de; csp@csperkins.org
>> Cc: avt@ietf.org; tom.taylor@rogers.com
>> Subject: RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-04.txt
>> 
>> 
>> Hi Roni,
>> 
>> Thanks for reading the new draft and for your new comments.
>> 
>> - Our intention was to summarize the definitions in a way easier to 
>> understand - that's why we did not copy those definitions 
>from the SVC 
>> coding spec. However, if you (and others don't disagree) would like 
>> those definitions to be phrased same as in the SVC coding 
>spec, we can 
>> certainly do that. I will do this change to the next version 
>if no one 
>> disagrees.
>> 
>> - Similarly as above, the semantics of the U bit was phrased as 
>> currently in the payload draft also to make it easier to understand.
>The
>> semantics from the SVC spec is as follows:
>> 
>> use_ref_base_pic_flag equal to 1 specifies that reference base
>pictures
>> are used as reference pictures for the inter prediction process.
>> use_ref_base_pic_flag equal to 0 specifies that decoded pictures are 
>> used as reference pictures during the inter prediction process.
>> The values of use_ref_base_pic_flag shall be the same for all NAL
>units
>> of a dependency representation. use_ref_base_pic_flag shall be equal
>to
>> 0 in filler prefix NAL units.
>> 
>> While the current semantics in the payload draft is as follows:
>> 
>> use_ref_base_pic_flag.  A value of 1 indicates that only reference
>base
>> pictures are used during the inter prediction process.  A value of 0 
>> indicates that the reference base pictures are not used during the
>inter
>> prediction process.
>> 
>> Except for the last sentence of the semantics in the SVC spec (which
>is
>> a limit to a conforming bitstream therefore no need to be 
>mentioned in 
>> the payload draft), both semantics are equivalent. In the payload
>draft,
>> I avoided having the sentence "use_ref_base_pic_flag equal to 0 
>> specifies that decoded pictures are used as reference 
>pictures during 
>> the inter prediction process.", which could be confusing to 
>people not 
>> deeply familiar with the SVC spec, wherein "decoded picture" in SVC 
>> context refers to the reconstructed picture used for output, while 
>> another (optional) reconstructed picture from decoding of the same 
>> access unit, "reference base picture", used for inter prediction but
>not
>> for output, is not a "decoded picture". I have checked the SVC spec, 
>> found that a new definition of "decoded picture" is 
>unfortunately not 
>> present in Annex G.3.
>> 
>> I therefore think it is a little bit better to have the current 
>> semantics in the payload draft, unless a new definition of "decoded 
>> picture" is added in the SVC spec (Annex G).
>> 
>> - Regarding the RR bits, if you meant for the difference between 
>> "Receivers SHOULD discard NAL units with RR not equal to 
>'11'." in the 
>> payload draft and "Decoders shall ignore the value of 
>> reserved_three_2bits." in the SVC spec, then I would say that having
>the
>> difference is correct, because herein the intention is to 
>specify the 
>> RTP receiver's operation not the decoder's operation, and "SHOULD"
>> should be used in stead of "SHALL".
>> 
>> BR, YK
>> 
>> >-----Original Message-----
>> >From: ext Even, Roni [mailto:roni.even@polycom.co.il]
>> >Sent: Thursday, January 03, 2008 3:15 PM
>> >To: Thomas Schierl; Colin Perkins
>> >Cc: avt@ietf.org; tom.taylor@rogers.com
>> >Subject: RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-04.txt
>> >
>> >Thomas,
>> >
>> >I am reading the svc draft and as long as you address non technical 
>> >parts I noticed that the definitions in section 5.1 are different 
>> >from the SVC (H.264 amendment 3) for the same terms. I suggest that 
>> >the definitions should be the same or use different names.
>> >
>> >
>> >The same comment for section 3.3 comparing to G.7.4.1.1 for 
>the U and 
>> >RR bits specifically.
>> >
>> >
>> >Roni
>> >
>> >> -----Original Message-----
>> >> From: Thomas Schierl [mailto:schierl@hhi.fhg.de]
>> >> Sent: Wednesday, January 02, 2008 7:36 PM
>> >> To: 'Colin Perkins'
>> >> Cc: avt@ietf.org; Even, Roni; 'Stephan Wenger';
>tom.taylor@rogers.com
>> >> Subject: RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-04.txt
>> >>
>> >> Hi Colin,
>> >>
>> >> Ok, I will try to fix the formatting before the conference call
>next
>> >week.
>> >>
>> >> Happy new year!
>> >> Thomas
>> >>
>> >> > -----Original Message-----
>> >> > From: Colin Perkins [mailto:csp@csperkins.org]
>> >> > Sent: Sunday, December 30, 2007 7:59 PM
>> >> > To: Thomas Schierl
>> >> > Cc: avt@ietf.org; 'Even, Roni'; 'Stephan Wenger';
>> >tom.taylor@rogers.com
>> >> > Subject: Re: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-04.txt
>> >> >
>> >> > Thomas,
>> >> >
>> >> > On 18 Dec 2007, at 18:15, Thomas Schierl wrote:
>> >> > > I just submitted the -04 version of the RTP payload
>> >draft for SVC.
>> >> > > Besides other changes, I corrected the formatting of the media
>> >type
>> >> > > section.
>> >> >
>> >> > There are so many formatting changes and problems with
>> >this version
>> >> > it's very difficult to find the technical changes. 
>Please can you 
>> >> > ensure that future versions of the draft have consistent
>> >formatting,
>> >> > such that diff tools can be used (the xml2rfc tool is extremely 
>> >> > useful here).
>> >> >
>> >> > Thanks,
>> >> > --
>> >> > Colin Perkins
>> >> > http://csperkins.org/
>> >>
>> >>
>> >>
>> >> ----
>> >> Visit us at
>> >>
>> >> FOE 2008 (8th Fiber Optics Expo) / Tokio Big Sight, Japan 
>/ 16 - 18 
>> >> January 2008 / Booth 2 - 50 http://www.foe.jp/english
>> >
>> >_______________________________________________
>> >Audio/Video Transport Working Group
>> >avt@ietf.org
>> >https://www1.ietf.org/mailman/listinfo/avt
>> >
>

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt