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
- [AVT] I-D Action:draft-ietf-avt-rtp-svc-04.txt Internet-Drafts
- [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-04.txt Thomas Schierl
- Re: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-0… Colin Perkins
- RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-0… Thomas Schierl
- RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-0… Even, Roni
- RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-0… Ye-Kui.Wang
- RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-0… Even, Roni
- RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-0… mike.nilsson
- RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-0… Ye-Kui.Wang
- RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-0… Thomas Schierl
- RE: [AVT] FW: I-D Action:draft-ietf-avt-rtp-svc-0… Ye-Kui.Wang