From harald@alvestrand.no Wed Mar 2 05:34:54 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54593A6800 for ; Wed, 2 Mar 2011 05:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tM1NHuzkXqLI for ; Wed, 2 Mar 2011 05:34:54 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id E15293A67FC for ; Wed, 2 Mar 2011 05:34:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6DC9739E1AA for ; Wed, 2 Mar 2011 14:35:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OqE6GPi7FDY for ; Wed, 2 Mar 2011 14:35:24 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A80C939E089 for ; Wed, 2 Mar 2011 14:35:24 +0100 (CET) Message-ID: <4D6E47BD.3000201@alvestrand.no> Date: Wed, 02 Mar 2011 14:35:57 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: payload@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 13:34:55 -0000 Hello, I'm not sure what the formal procedure should be, so I'm just sending email... I think that draft-westin-payload-vp8-01, describing an RTP encapsulation for VP8, is ready for IETF review and possible approval. What steps do we need to take in order to get it on the proper agendas? Harald Alvestrand From abegen@cisco.com Wed Mar 2 05:47:00 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB963A67F1 for ; Wed, 2 Mar 2011 05:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 f2H8U75UAnbG for ; Wed, 2 Mar 2011 05:47:00 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F382A3A67D8 for ; Wed, 2 Mar 2011 05:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1044; q=dns/txt; s=iport; t=1299073686; x=1300283286; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=sQGKSqTCeLm4vNrS9t8Qo92weqAP62IljTuz5w1AL54=; b=dxjeeUT0cixqQmVV3IOzhg7JjILHIni1TXZKTMrxqAmoVQDDdNKF17dk gUIHrlq6HuHURNEX0ISwP45S6MGsf5Nu0w9i91qpS0GkQVPCfLbiuzBhS mfFMV1d0uaikHNWY7vRb6qeasrGiBd5NmRE73USBuBxCRu/LoYOk7B7/c w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8AACLZbU2rR7Ht/2dsb2JhbACYAY5WdKFzm3eFYQSFF4pV X-IronPort-AV: E=Sophos;i="4.62,253,1297036800"; d="scan'208";a="337783020" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2011 13:48:04 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p22Dm4jG008757; Wed, 2 Mar 2011 13:48:04 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 05:48:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Mar 2011 05:47:35 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E760844@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4D6E47BD.3000201@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] Request for consideration: draft-westin-payload-vp8-01 Thread-Index: AcvY3siUXstVxoNnQniMaxZX7K67/QAAVFPw References: <4D6E47BD.3000201@alvestrand.no> From: "Ali C. Begen (abegen)" To: "Harald Alvestrand" , X-OriginalArrivalTime: 02 Mar 2011 13:48:04.0709 (UTC) FILETIME=[7462B150:01CBD8E0] Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 13:47:00 -0000 We can put you on the agenda. Since this is the first meeting after AVT = split, we will be sharing the same session with AVTcore. How much time do you need? And we will need your slides to post them = before the session. -acbegen > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Harald Alvestrand > Sent: Wednesday, March 02, 2011 8:36 AM > To: payload@ietf.org > Subject: [payload] Request for consideration: = draft-westin-payload-vp8-01 >=20 > Hello, >=20 > I'm not sure what the formal procedure should be, so I'm just sending > email... > I think that draft-westin-payload-vp8-01, describing an RTP > encapsulation for VP8, is ready for IETF review and possible approval. >=20 > What steps do we need to take in order to get it on the proper = agendas? >=20 > Harald Alvestrand >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From keith.drage@alcatel-lucent.com Wed Mar 2 09:19:42 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C3B3A682C for ; Wed, 2 Mar 2011 09:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.411 X-Spam-Level: X-Spam-Status: No, score=-105.411 tagged_above=-999 required=5 tests=[AWL=0.838, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 swdg4drrGn9c for ; Wed, 2 Mar 2011 09:19:40 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 7C93C3A67E1 for ; Wed, 2 Mar 2011 09:19:39 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p22HKelg005905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Mar 2011 18:20:40 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 2 Mar 2011 18:20:40 +0100 From: "DRAGE, Keith (Keith)" To: "Ali C. Begen (abegen)" , Harald Alvestrand , "payload@ietf.org" Date: Wed, 2 Mar 2011 18:20:38 +0100 Thread-Topic: [payload] Request for consideration: draft-westin-payload-vp8-01 Thread-Index: AcvY3siUXstVxoNnQniMaxZX7K67/QAAVFPwAAdhx5A= Message-ID: References: <4D6E47BD.3000201@alvestrand.no> <04CAD96D4C5A3D48B1919248A8FE0D540E760844@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E760844@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:19:42 -0000 I suspect this depends whether it needs discussion or not. My understanding was that payloads were substantially meant to be a matter = for review and approval providing they followed the rules. I would suggest you get a couple of experts to read it, see if it makes sen= se and that it is not duplicating something that already exists.=20 If that comes back positive, put a message to the list to adopt a milestone= to progress it. Follow that with a detailed expert review, then WGLC, then publication requ= est. Now some of those may throw up something that requires face to face time, b= ut I don't think you are at that stage yet. Regards Keith > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal= f > Of Ali C. Begen (abegen) > Sent: 02 March 2011 13:48 > To: Harald Alvestrand; payload@ietf.org > Subject: Re: [payload] Request for consideration: draft-westin-payload- > vp8-01 >=20 > We can put you on the agenda. Since this is the first meeting after AVT > split, we will be sharing the same session with AVTcore. >=20 > How much time do you need? And we will need your slides to post them > before the session. >=20 > -acbegen >=20 > > -----Original Message----- > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Harald Alvestrand > > Sent: Wednesday, March 02, 2011 8:36 AM > > To: payload@ietf.org > > Subject: [payload] Request for consideration: draft-westin-payload-vp8- > 01 > > > > Hello, > > > > I'm not sure what the formal procedure should be, so I'm just sending > > email... > > I think that draft-westin-payload-vp8-01, describing an RTP > > encapsulation for VP8, is ready for IETF review and possible approval. > > > > What steps do we need to take in order to get it on the proper agendas? > > > > Harald Alvestrand > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From harald@alvestrand.no Wed Mar 2 09:59:45 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70743A67C0 for ; Wed, 2 Mar 2011 09:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 KdNvyDa6UCfO for ; Wed, 2 Mar 2011 09:59:43 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id A00393A67FB for ; Wed, 2 Mar 2011 09:59:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CF94E39E089; Wed, 2 Mar 2011 19:00:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIrki9B2UQHf; Wed, 2 Mar 2011 19:00:15 +0100 (CET) Received: from [192.168.0.2] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2EF5A39E113; Wed, 2 Mar 2011 19:00:15 +0100 (CET) Message-ID: <4D6E85D0.3050707@alvestrand.no> Date: Wed, 02 Mar 2011 19:00:48 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4D6E47BD.3000201@alvestrand.no> <04CAD96D4C5A3D48B1919248A8FE0D540E760844@xmb-sjc-215.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "payload@ietf.org" Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 17:59:45 -0000 On 03/02/11 18:20, DRAGE, Keith (Keith) wrote: > I suspect this depends whether it needs discussion or not. > > My understanding was that payloads were substantially meant to be a matter for review and approval providing they followed the rules. > > I would suggest you get a couple of experts to read it, see if it makes sense and that it is not duplicating something that already exists. > > If that comes back positive, put a message to the list to adopt a milestone to progress it. > > Follow that with a detailed expert review, then WGLC, then publication request. > > Now some of those may throw up something that requires face to face time, but I don't think you are at that stage yet. Would be wonderful if it is that noncontroversial. Magnus Westerlund has reviewed it already; who would you suggest for a second (or third) expert? Harald > Regards > > Keith > >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf >> Of Ali C. Begen (abegen) >> Sent: 02 March 2011 13:48 >> To: Harald Alvestrand; payload@ietf.org >> Subject: Re: [payload] Request for consideration: draft-westin-payload- >> vp8-01 >> >> We can put you on the agenda. Since this is the first meeting after AVT >> split, we will be sharing the same session with AVTcore. >> >> How much time do you need? And we will need your slides to post them >> before the session. >> >> -acbegen >> >>> -----Original Message----- >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >> Behalf Of Harald Alvestrand >>> Sent: Wednesday, March 02, 2011 8:36 AM >>> To: payload@ietf.org >>> Subject: [payload] Request for consideration: draft-westin-payload-vp8- >> 01 >>> Hello, >>> >>> I'm not sure what the formal procedure should be, so I'm just sending >>> email... >>> I think that draft-westin-payload-vp8-01, describing an RTP >>> encapsulation for VP8, is ready for IETF review and possible approval. >>> >>> What steps do we need to take in order to get it on the proper agendas? >>> >>> Harald Alvestrand >>> >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload From stewe@stewe.org Wed Mar 2 10:14:16 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6973A67FD for ; Wed, 2 Mar 2011 10:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=1.233, BAYES_00=-2.599] 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 9I1dksXItl4b for ; Wed, 2 Mar 2011 10:14:15 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 29DBD3A67D3 for ; Wed, 2 Mar 2011 10:14:14 -0800 (PST) Received: from [192.168.1.108] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 6857-1743317 for multiple; Wed, 02 Mar 2011 19:15:20 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Wed, 02 Mar 2011 10:15:09 -0800 From: Stephan Wenger To: Harald Alvestrand , "DRAGE, Keith (Keith)" Message-ID: Thread-Topic: [payload] Request for consideration: draft-westin-payload-vp8-01 In-Reply-To: <4D6E85D0.3050707@alvestrand.no> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Cc: "payload@ietf.org" Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 18:14:16 -0000 I'll take a look by IETF80. Stephan P.s.: Keith, I don't want to lock horns with you again, but your statement below regarding "expert reviews" is not inline with my experience over the last decade or so when it comes to video codec payload standardization. And, I don't think it would be healthy. There is so much money in this ecosystem that people have played politics to prevent or facilitate (depending on viewpoint) fast adoption. That may be a bad thing, but its probably not easy to avoid. However, at the end, the scrutiny received has more often than not led to a better standard. As a result, I have yet to see a video codec payload format that made it to RFC in less than 10 iterations. I don't mind if the VP8 payload moves faster, but a would object to the approval of a suboptimal technology when better technologies are known, even if the draft describing it follows the rules. On 3.2.2011 10:00 , "Harald Alvestrand" wrote: >On 03/02/11 18:20, DRAGE, Keith (Keith) wrote: >> I suspect this depends whether it needs discussion or not. >> >> My understanding was that payloads were substantially meant to be a >>matter for review and approval providing they followed the rules. >> >> I would suggest you get a couple of experts to read it, see if it makes >>sense and that it is not duplicating something that already exists. >> >> If that comes back positive, put a message to the list to adopt a >>milestone to progress it. >> >> Follow that with a detailed expert review, then WGLC, then publication >>request. >> >> Now some of those may throw up something that requires face to face >>time, but I don't think you are at that stage yet. >Would be wonderful if it is that noncontroversial. >Magnus Westerlund has reviewed it already; who would you suggest for a >second (or third) expert? > > Harald >> Regards >> >> Keith >> >>> -----Original Message----- >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >>>Behalf >>> Of Ali C. Begen (abegen) >>> Sent: 02 March 2011 13:48 >>> To: Harald Alvestrand; payload@ietf.org >>> Subject: Re: [payload] Request for consideration: draft-westin-payload- >>> vp8-01 >>> >>> We can put you on the agenda. Since this is the first meeting after AVT >>> split, we will be sharing the same session with AVTcore. >>> >>> How much time do you need? And we will need your slides to post them >>> before the session. >>> >>> -acbegen >>> >>>> -----Original Message----- >>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >>> Behalf Of Harald Alvestrand >>>> Sent: Wednesday, March 02, 2011 8:36 AM >>>> To: payload@ietf.org >>>> Subject: [payload] Request for consideration: >>>>draft-westin-payload-vp8- >>> 01 >>>> Hello, >>>> >>>> I'm not sure what the formal procedure should be, so I'm just sending >>>> email... >>>> I think that draft-westin-payload-vp8-01, describing an RTP >>>> encapsulation for VP8, is ready for IETF review and possible approval. >>>> >>>> What steps do we need to take in order to get it on the proper >>>>agendas? >>>> >>>> Harald Alvestrand >>>> >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From fluffy@cisco.com Wed Mar 2 10:57:06 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4D53A6831 for ; Wed, 2 Mar 2011 10:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.545 X-Spam-Level: X-Spam-Status: No, score=-110.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 vpaD23bjUjZt for ; Wed, 2 Mar 2011 10:57:05 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DA3F93A684B for ; Wed, 2 Mar 2011 10:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=843; q=dns/txt; s=iport; t=1299092292; x=1300301892; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=azNFstDR3IKAfo+6fQcF53/+QC+Z4fB/AG6lzwldTcs=; b=iPDWoTQL8mlml8xBrkG+uUXd0I5OUdlZkW38uFZtg/FEdILnjb2X3b8+ aAYIwJGTjnZpuHAzX+6jMkI2BuIApxsDAM/Cg/p9PUC88r/L+TT2Dlsot 1gmkNnelfP/RxxWeofynrVRs0CXm60+S55xHgEHnCOBystol7ozBwBpHz M=; X-IronPort-AV: E=Sophos;i="4.62,254,1297036800"; d="scan'208";a="337998293" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2011 18:58:12 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p22IwB8o005224; Wed, 2 Mar 2011 18:58:11 GMT Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Wed, 2 Mar 2011 12:00:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <13A9881A-2931-49E4-A628-9A26762DE9A6@cisco.com> References: <4D6E47BD.3000201@alvestrand.no> <04CAD96D4C5A3D48B1919248A8FE0D540E760844@xmb-sjc-215.amer.cisco.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) Cc: "payload@ietf.org" Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 18:57:06 -0000 On Mar 2, 2011, at 10:20 AM, DRAGE, Keith (Keith) wrote: >=20 > I would suggest you get a couple of experts to read it, see if it = makes sense and that it is not duplicating something that already = exists.=20 >=20 > If that comes back positive, put a message to the list to adopt a = milestone to progress it. I've read it. It does not duplicate existing work. There is a strong = need for it - people are implementing SIP products that use VP8 and = there needs to be a way to negotiate use of VP8. This draft may need = some work before it is done but it is more than ready for adoption as a = WG item. I can not imagine any reason not to immediately add the = following milestone * Submit RTP Payload Format for VP8 Video for Proposed Standard and do a call for WG adoption of this draft as a WG item. Cullen From keith.drage@alcatel-lucent.com Thu Mar 3 04:05:13 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D04D28B797 for ; Thu, 3 Mar 2011 04:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.47 X-Spam-Level: X-Spam-Status: No, score=-105.47 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 1uOHKNaOo1e4 for ; Thu, 3 Mar 2011 04:05:12 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id B1F513A69C1 for ; Thu, 3 Mar 2011 04:05:08 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p23C66K4000907 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 13:06:09 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 3 Mar 2011 13:06:06 +0100 From: "DRAGE, Keith (Keith)" To: Stephan Wenger , Harald Alvestrand Date: Thu, 3 Mar 2011 13:06:05 +0100 Thread-Topic: [payload] Request for consideration: draft-westin-payload-vp8-01 Thread-Index: AcvZBdIKaTGNOLUQT7CI4J/UITsUUwAgx9rA Message-ID: References: <4D6E85D0.3050707@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "payload@ietf.org" Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 12:05:13 -0000 Firstly, how this proceeds is up to the WG chairs, which for this WG does n= ot involve me anymore. I would just make two points: 1) Adoption of a payload format does not mean IETF endorses the codec. It m= erely provides a transport if someone wants to use it. So in that respect, = I believe there are only a few things to answer before starting the work: a) is it a valid use of RTP b) does it duplicate existing work c) is the work so out of the window it is a waste of the working groups ti= me It does not involve the question of whether this is the best video codec on= the market. 2) None of the process I outlined removes the working group from the discus= sion. Adoption of the milestone still gets discussed on the list. The worki= ng group gets ample time to comment while expert reviews are being made. Th= e working group still gets to comment on WGLC. The IETF still gets to comme= nt at IETF last call. Regards Keith > -----Original Message----- > From: Stephan Wenger [mailto:stewe@stewe.org] > Sent: 02 March 2011 18:15 > To: Harald Alvestrand; DRAGE, Keith (Keith) > Cc: payload@ietf.org > Subject: Re: [payload] Request for consideration: draft-westin-payload- > vp8-01 >=20 > I'll take a look by IETF80. > Stephan >=20 > P.s.: Keith, I don't want to lock horns with you again, but your statemen= t > below regarding "expert reviews" is not inline with my experience over th= e > last decade or so when it comes to video codec payload standardization. > And, I don't think it would be healthy. There is so much money in this > ecosystem that people have played politics to prevent or facilitate > (depending on viewpoint) fast adoption. That may be a bad thing, but its > probably not easy to avoid. However, at the end, the scrutiny received > has more often than not led to a better standard. As a result, I have ye= t > to see a video codec payload format that made it to RFC in less than 10 > iterations. I don't mind if the VP8 payload moves faster, but a would > object to the approval of a suboptimal technology when better technologie= s > are known, even if the draft describing it follows the rules. >=20 >=20 >=20 > On 3.2.2011 10:00 , "Harald Alvestrand" wrote: >=20 > >On 03/02/11 18:20, DRAGE, Keith (Keith) wrote: > >> I suspect this depends whether it needs discussion or not. > >> > >> My understanding was that payloads were substantially meant to be a > >>matter for review and approval providing they followed the rules. > >> > >> I would suggest you get a couple of experts to read it, see if it make= s > >>sense and that it is not duplicating something that already exists. > >> > >> If that comes back positive, put a message to the list to adopt a > >>milestone to progress it. > >> > >> Follow that with a detailed expert review, then WGLC, then publication > >>request. > >> > >> Now some of those may throw up something that requires face to face > >>time, but I don't think you are at that stage yet. > >Would be wonderful if it is that noncontroversial. > >Magnus Westerlund has reviewed it already; who would you suggest for a > >second (or third) expert? > > > > Harald > >> Regards > >> > >> Keith > >> > >>> -----Original Message----- > >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >>>Behalf > >>> Of Ali C. Begen (abegen) > >>> Sent: 02 March 2011 13:48 > >>> To: Harald Alvestrand; payload@ietf.org > >>> Subject: Re: [payload] Request for consideration: draft-westin- > payload- > >>> vp8-01 > >>> > >>> We can put you on the agenda. Since this is the first meeting after > AVT > >>> split, we will be sharing the same session with AVTcore. > >>> > >>> How much time do you need? And we will need your slides to post them > >>> before the session. > >>> > >>> -acbegen > >>> > >>>> -----Original Message----- > >>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >>> Behalf Of Harald Alvestrand > >>>> Sent: Wednesday, March 02, 2011 8:36 AM > >>>> To: payload@ietf.org > >>>> Subject: [payload] Request for consideration: > >>>>draft-westin-payload-vp8- > >>> 01 > >>>> Hello, > >>>> > >>>> I'm not sure what the formal procedure should be, so I'm just sendin= g > >>>> email... > >>>> I think that draft-westin-payload-vp8-01, describing an RTP > >>>> encapsulation for VP8, is ready for IETF review and possible > approval. > >>>> > >>>> What steps do we need to take in order to get it on the proper > >>>>agendas? > >>>> > >>>> Harald Alvestrand > >>>> > >>>> _______________________________________________ > >>>> payload mailing list > >>>> payload@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/payload > >>> _______________________________________________ > >>> payload mailing list > >>> payload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/payload > > > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload >=20 From keith.drage@alcatel-lucent.com Thu Mar 3 05:02:44 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A883E3A69DE for ; Thu, 3 Mar 2011 05:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.568 X-Spam-Level: X-Spam-Status: No, score=-105.568 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 SxYanJ7a8eGM for ; Thu, 3 Mar 2011 05:02:43 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 8A24E3A69DD for ; Thu, 3 Mar 2011 05:02:42 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p23D3jVg008116 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 14:03:46 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 3 Mar 2011 14:03:45 +0100 From: "DRAGE, Keith (Keith)" To: Harald Alvestrand Date: Thu, 3 Mar 2011 14:03:43 +0100 Thread-Topic: [payload] Request for consideration: draft-westin-payload-vp8-01 Thread-Index: AcvZA8ojG7Kbs44MQ4WZFk7PyMC0VwAn136w Message-ID: References: <4D6E47BD.3000201@alvestrand.no> <04CAD96D4C5A3D48B1919248A8FE0D540E760844@xmb-sjc-215.amer.cisco.com> <4D6E85D0.3050707@alvestrand.no> In-Reply-To: <4D6E85D0.3050707@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "payload@ietf.org" Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:02:44 -0000 It is up to the PAYLOAD chairs. If Magnus and Cullen have read it - then that should answer the first quest= ion on whether there should be a payload format at all (duplication, not a = valid RTP usage etc), and whether the WG should be asked if they want the d= ocument. Keith > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no] > Sent: 02 March 2011 18:01 > To: DRAGE, Keith (Keith) > Cc: Ali C. Begen (abegen); payload@ietf.org > Subject: Re: [payload] Request for consideration: draft-westin-payload- > vp8-01 >=20 > On 03/02/11 18:20, DRAGE, Keith (Keith) wrote: > > I suspect this depends whether it needs discussion or not. > > > > My understanding was that payloads were substantially meant to be a > matter for review and approval providing they followed the rules. > > > > I would suggest you get a couple of experts to read it, see if it makes > sense and that it is not duplicating something that already exists. > > > > If that comes back positive, put a message to the list to adopt a > milestone to progress it. > > > > Follow that with a detailed expert review, then WGLC, then publication > request. > > > > Now some of those may throw up something that requires face to face > time, but I don't think you are at that stage yet. > Would be wonderful if it is that noncontroversial. > Magnus Westerlund has reviewed it already; who would you suggest for a > second (or third) expert? >=20 > Harald > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf > >> Of Ali C. Begen (abegen) > >> Sent: 02 March 2011 13:48 > >> To: Harald Alvestrand; payload@ietf.org > >> Subject: Re: [payload] Request for consideration: draft-westin-payload= - > >> vp8-01 > >> > >> We can put you on the agenda. Since this is the first meeting after AV= T > >> split, we will be sharing the same session with AVTcore. > >> > >> How much time do you need? And we will need your slides to post them > >> before the session. > >> > >> -acbegen > >> > >>> -----Original Message----- > >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >> Behalf Of Harald Alvestrand > >>> Sent: Wednesday, March 02, 2011 8:36 AM > >>> To: payload@ietf.org > >>> Subject: [payload] Request for consideration: draft-westin-payload- > vp8- > >> 01 > >>> Hello, > >>> > >>> I'm not sure what the formal procedure should be, so I'm just sending > >>> email... > >>> I think that draft-westin-payload-vp8-01, describing an RTP > >>> encapsulation for VP8, is ready for IETF review and possible approval= . > >>> > >>> What steps do we need to take in order to get it on the proper > agendas? > >>> > >>> Harald Alvestrand > >>> > >>> _______________________________________________ > >>> payload mailing list > >>> payload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/payload > >> _______________________________________________ > >> payload mailing list > >> payload@ietf.org > >> https://www.ietf.org/mailman/listinfo/payload From peter.musgrave@magorcorp.com Thu Mar 3 06:34:03 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 407303A67F1 for ; Thu, 3 Mar 2011 06:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 xbHd8cNWZMYs for ; Thu, 3 Mar 2011 06:34:02 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2704A3A67E7 for ; Thu, 3 Mar 2011 06:34:01 -0800 (PST) Received: by iwl42 with SMTP id 42so1157091iwl.31 for ; Thu, 03 Mar 2011 06:35:09 -0800 (PST) Received: by 10.42.135.72 with SMTP id o8mr963681ict.488.1299162909034; Thu, 03 Mar 2011 06:35:09 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id u9sm1018522ibe.20.2011.03.03.06.35.07 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2011 06:35:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: Date: Thu, 3 Mar 2011 09:35:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <01BF3DDD-FA8C-4AD8-9A79-F52FB7BF725A@magorcorp.com> References: <4D6E47BD.3000201@alvestrand.no> <04CAD96D4C5A3D48B1919248A8FE0D540E760844@xmb-sjc-215.amer.cisco.com> <4D6E85D0.3050707@alvestrand.no> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) Cc: "payload@ietf.org" Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 14:34:03 -0000 I have read the doc. I do not claim to be a video coding expert - so I = cannot speak to the way in which the data is arranged in the payload. I think it is generally quite clear and worth adopting.=20 I would suggest that there be a mention of the desired behaviour in the = SDP offer/answer when there is a mis-match on the optional version = attribute. Is it assumed that a endpoint which supports version 2 will also support = version 1? Would it be listed as two attribute lines (one for each = version) etc.? (Nit: There is no table of contents) Cheers,=20 Peter Musgrave On 2011-03-03, at 8:03 AM, DRAGE, Keith (Keith) wrote: > It is up to the PAYLOAD chairs. >=20 > If Magnus and Cullen have read it - then that should answer the first = question on whether there should be a payload format at all = (duplication, not a valid RTP usage etc), and whether the WG should be = asked if they want the document. >=20 > Keith >=20 >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: 02 March 2011 18:01 >> To: DRAGE, Keith (Keith) >> Cc: Ali C. Begen (abegen); payload@ietf.org >> Subject: Re: [payload] Request for consideration: = draft-westin-payload- >> vp8-01 >>=20 >> On 03/02/11 18:20, DRAGE, Keith (Keith) wrote: >>> I suspect this depends whether it needs discussion or not. >>>=20 >>> My understanding was that payloads were substantially meant to be a >> matter for review and approval providing they followed the rules. >>>=20 >>> I would suggest you get a couple of experts to read it, see if it = makes >> sense and that it is not duplicating something that already exists. >>>=20 >>> If that comes back positive, put a message to the list to adopt a >> milestone to progress it. >>>=20 >>> Follow that with a detailed expert review, then WGLC, then = publication >> request. >>>=20 >>> Now some of those may throw up something that requires face to face >> time, but I don't think you are at that stage yet. >> Would be wonderful if it is that noncontroversial. >> Magnus Westerlund has reviewed it already; who would you suggest for = a >> second (or third) expert? >>=20 >> Harald >>> Regards >>>=20 >>> Keith >>>=20 >>>> -----Original Message----- >>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >> Behalf >>>> Of Ali C. Begen (abegen) >>>> Sent: 02 March 2011 13:48 >>>> To: Harald Alvestrand; payload@ietf.org >>>> Subject: Re: [payload] Request for consideration: = draft-westin-payload- >>>> vp8-01 >>>>=20 >>>> We can put you on the agenda. Since this is the first meeting after = AVT >>>> split, we will be sharing the same session with AVTcore. >>>>=20 >>>> How much time do you need? And we will need your slides to post = them >>>> before the session. >>>>=20 >>>> -acbegen >>>>=20 >>>>> -----Original Message----- >>>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] = On >>>> Behalf Of Harald Alvestrand >>>>> Sent: Wednesday, March 02, 2011 8:36 AM >>>>> To: payload@ietf.org >>>>> Subject: [payload] Request for consideration: = draft-westin-payload- >> vp8- >>>> 01 >>>>> Hello, >>>>>=20 >>>>> I'm not sure what the formal procedure should be, so I'm just = sending >>>>> email... >>>>> I think that draft-westin-payload-vp8-01, describing an RTP >>>>> encapsulation for VP8, is ready for IETF review and possible = approval. >>>>>=20 >>>>> What steps do we need to take in order to get it on the proper >> agendas? >>>>>=20 >>>>> Harald Alvestrand >>>>>=20 >>>>> _______________________________________________ >>>>> payload mailing list >>>>> payload@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/payload >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From Even.roni@huawei.com Thu Mar 3 06:34:30 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE793A67F1 for ; Thu, 3 Mar 2011 06:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 5Lr6mkA797fA for ; Thu, 3 Mar 2011 06:34:26 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 85BAA3A67E7 for ; Thu, 3 Mar 2011 06:34:26 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHH0069LKIUDW@szxga04-in.huawei.com> for payload@ietf.org; Thu, 03 Mar 2011 22:35:18 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHH00IM0KIUJP@szxga04-in.huawei.com> for payload@ietf.org; Thu, 03 Mar 2011 22:35:18 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-2-17.red.bezeqint.net [79.183.2.17]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHH00NILKIJ1Y@szxml12-in.huawei.com>; Thu, 03 Mar 2011 22:35:18 +0800 (CST) Date: Thu, 03 Mar 2011 16:35:11 +0200 From: Roni Even In-reply-to: <4D6E47BD.3000201@alvestrand.no> To: 'Harald Alvestrand' , payload@ietf.org Message-id: <00f201cbd9b0$3ab0fc20$b012f460$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvY3sr7WAdEnG1zRhailh2Tx9slJAAzJ7mQ References: <4D6E47BD.3000201@alvestrand.no> Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 14:34:30 -0000 Hi Harald, In general there is no problem to accept a payload specification as a WG document as long as there is just one proposal. In this case I do not think there will be a second proposal since this is unusual for non standard codecs. So we can ask for a milestone. As for progressing the work I did a very quick look and have a couple of comments 1. The media subtype registration in section 6 is not following the registration template (see in rtp-howto or in one of the payload RFC e.g. RFC5391 section 5.1. You can also look at a video codec like the updated H.264 payload http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-12 which is in the RFC editor queue at the moment.) 2. The draft does not have a required congestion control section see http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06 for payload specification structure. 3. I noticed the division of the data to prediction mode parameters and motion vectors partition and DCT/WHT coefficients partitions. Which enables better resilience to loss according to the draft. In IP network the typical loss is packet loss and not part of a packet so maybe in the congestion control section you can provide some guideline about a recommendation of how to build packets that can be removed. 4. In the example in section 6.4 I think that you should nave avpf and not avp as the profile since you recommend using the feedback mechanism Going forward you can update the individual draft regardless of when it becomes a WG item Regards Roni Even > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Wednesday, March 02, 2011 3:36 PM > To: payload@ietf.org > Subject: [payload] Request for consideration: draft-westin-payload-vp8- > 01 > > Hello, > > I'm not sure what the formal procedure should be, so I'm just sending > email... > I think that draft-westin-payload-vp8-01, describing an RTP > encapsulation for VP8, is ready for IETF review and possible approval. > > What steps do we need to take in order to get it on the proper agendas? > > Harald Alvestrand > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From Internet-Drafts@ietf.org Thu Mar 3 10:15:03 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1763A6A22; Thu, 3 Mar 2011 10:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uxPyq-Gt0Z2x; Thu, 3 Mar 2011 10:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F75C3A682C; Thu, 3 Mar 2011 10:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110303181502.12726.34964.idtracker@localhost> Date: Thu, 03 Mar 2011 10:15:02 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-payload-rtp-howto-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 18:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : How to Write an RTP Payload Format Author(s) : M. Westerlund Filename : draft-ietf-payload-rtp-howto-00.txt Pages : 55 Date : 2011-03-03 This document contains information on how to best write an RTP payload format. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions that can be used when writing an RTP payload format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-howto-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-payload-rtp-howto-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-03100649.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Fri Mar 4 00:45:28 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE753A6968 for ; Fri, 4 Mar 2011 00:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.407 X-Spam-Level: X-Spam-Status: No, score=-106.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ZONkQRbZTAKu for ; Fri, 4 Mar 2011 00:45:27 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C72BB3A6942 for ; Fri, 4 Mar 2011 00:45:26 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-77-4d70a6ea836b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 69.35.21265.AE6A07D4; Fri, 4 Mar 2011 09:46:35 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Fri, 4 Mar 2011 09:46:34 +0100 Message-ID: <4D70A6EA.2010301@ericsson.com> Date: Fri, 4 Mar 2011 09:46:34 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "payload@ietf.org" References: <20110303181502.12726.34964.idtracker@localhost> In-Reply-To: <20110303181502.12726.34964.idtracker@localhost> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [payload] I-D Action:draft-ietf-payload-rtp-howto-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 08:45:28 -0000 Hi, This long time in production version contains from both Tom Taylor and Ali Begen. It unfortunately still don't resolve all the open issues I have listed in this document. I would love to get a contribution from anyone that was more closely involved in the SVC payload format on what to think about when it comes to scalability in payload formats. There is clearly some more work needed from my side to flesh out examples of designs and RFC-errata. Contributions are very much accepted. There is a question about procedures when the WG closes down. But if that is going to included here, then this document probably needs to be published as BCP. I think we likely can drop this question from the document. Cheers Magnus Internet-Drafts@ietf.org skrev 2011-03-03 19:15: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. > > > Title : How to Write an RTP Payload Format > Author(s) : M. Westerlund > Filename : draft-ietf-payload-rtp-howto-00.txt > Pages : 55 > Date : 2011-03-03 > > This document contains information on how to best write an RTP > payload format. It provides reading tips, design practices, and > practical tips on how to produce an RTP payload format specification > quickly and with good results. A template is also included with > instructions that can be used when writing an RTP payload format. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-howto-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From harald@alvestrand.no Mon Mar 7 01:56:12 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7777B3A68EC for ; Mon, 7 Mar 2011 01:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 yaaqGc8JseMu for ; Mon, 7 Mar 2011 01:56:11 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 3378F3A6934 for ; Mon, 7 Mar 2011 01:56:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 14C7139E17B; Mon, 7 Mar 2011 10:56:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0C6-cHP7QHG; Mon, 7 Mar 2011 10:56:48 +0100 (CET) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 757A739E084; Mon, 7 Mar 2011 10:56:48 +0100 (CET) Message-ID: <4D74AC02.4090208@alvestrand.no> Date: Mon, 07 Mar 2011 10:57:22 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Roni Even References: <4D6E47BD.3000201@alvestrand.no> <00f201cbd9b0$3ab0fc20$b012f460$%roni@huawei.com> In-Reply-To: <00f201cbd9b0$3ab0fc20$b012f460$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hlundin@google.com, pwestin@google.com, payload@ietf.org Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 09:56:12 -0000 On 03/03/11 15:35, Roni Even wrote: > Hi Harald, > In general there is no problem to accept a payload specification as a WG > document as long as there is just one proposal. In this case I do not think > there will be a second proposal since this is unusual for non standard > codecs. > > So we can ask for a milestone. > > As for progressing the work I did a very quick look and have a couple of > comments > > 1. The media subtype registration in section 6 is not following the > registration template (see in rtp-howto or in one of the payload RFC e.g. > RFC5391 section 5.1. You can also look at a video codec like the updated > H.264 payload http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-12 > which is in the RFC editor queue at the moment.) I'll get that updated. Most of the fields are boilerplate. > 2. The draft does not have a required congestion control section see > http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06 for payload > specification structure. Checking: Is this currently draft-ietf-payload-rtp-howto-00? Patrik did a pass at updating after being pointed at the document as part of Magnus' review, that's the diff between the -00 and the -01 version. > 3. I noticed the division of the data to prediction mode parameters and > motion vectors partition and DCT/WHT coefficients partitions. Which enables > better resilience to loss according to the draft. In IP network the typical > loss is packet loss and not part of a packet so maybe in the congestion > control section you can provide some guideline about a recommendation of how > to build packets that can be removed. Area of active research. I'll get it considered; the comment was part of a consideration of using variable-protection FEC mechanisms, which was subsequently removed (we'll get back to that at a later stage). > 4. In the example in section 6.4 I think that you should nave avpf and not > avp as the profile since you recommend using the feedback mechanism It's only an example, but I agree. > > Going forward you can update the individual draft regardless of when it > becomes a WG item Thanks! > Regards > Roni Even > > > >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >> Behalf Of Harald Alvestrand >> Sent: Wednesday, March 02, 2011 3:36 PM >> To: payload@ietf.org >> Subject: [payload] Request for consideration: draft-westin-payload-vp8- >> 01 >> >> Hello, >> >> I'm not sure what the formal procedure should be, so I'm just sending >> email... >> I think that draft-westin-payload-vp8-01, describing an RTP >> encapsulation for VP8, is ready for IETF review and possible approval. >> >> What steps do we need to take in order to get it on the proper agendas? >> >> Harald Alvestrand >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > From Even.roni@huawei.com Mon Mar 7 03:01:15 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917E13A695F for ; Mon, 7 Mar 2011 03:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.495 X-Spam-Level: X-Spam-Status: No, score=-104.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 JkTEoJq2aA1y for ; Mon, 7 Mar 2011 03:01:14 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 1AE3D28C0E8 for ; Mon, 7 Mar 2011 03:01:14 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHO00KM7P81U9@szxga03-in.huawei.com> for payload@ietf.org; Mon, 07 Mar 2011 19:00:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHO00MEWP81D9@szxga03-in.huawei.com> for payload@ietf.org; Mon, 07 Mar 2011 19:00:01 +0800 (CST) Received: from windows8d787f9 (bzq-79-181-28-173.red.bezeqint.net [79.181.28.173]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHO005RZP7TKL@szxml11-in.huawei.com>; Mon, 07 Mar 2011 19:00:01 +0800 (CST) Date: Mon, 07 Mar 2011 12:59:53 +0200 From: Roni Even In-reply-to: <4D74AC02.4090208@alvestrand.no> To: 'Harald Alvestrand' Message-id: <001e01cbdcb6$cee95d70$6cbc1850$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=US-ASCII Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvcrhcXFPBYoGoOR36/kL23dNfTugACE1dA References: <4D6E47BD.3000201@alvestrand.no> <00f201cbd9b0$3ab0fc20$b012f460$%roni@huawei.com> <4D74AC02.4090208@alvestrand.no> Cc: hlundin@google.com, payload@ietf.org, pwestin@google.com Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 11:01:15 -0000 Hi, The latest version of RTP howto came after my previous response http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-00 You can also see the new milestone in the charter. It will be good to have an updated individual draft which will include the correct media subtype registration template and the mandatory sections according to RTP Howto Thanks Roni Even Payload co-chair > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: Monday, March 07, 2011 11:57 AM > To: Roni Even > Cc: hlundin@google.com; pwestin@google.com; payload@ietf.org > Subject: Re: [payload] Request for consideration: draft-westin-payload- > vp8-01 > > On 03/03/11 15:35, Roni Even wrote: > > Hi Harald, > > In general there is no problem to accept a payload specification as a > WG > > document as long as there is just one proposal. In this case I do not > think > > there will be a second proposal since this is unusual for non > standard > > codecs. > > > > So we can ask for a milestone. > > > > As for progressing the work I did a very quick look and have a couple > of > > comments > > > > 1. The media subtype registration in section 6 is not following the > > registration template (see in rtp-howto or in one of the payload RFC > e.g. > > RFC5391 section 5.1. You can also look at a video codec like the > updated > > H.264 payload http://tools.ietf.org/html/draft-ietf-avt-rtp- > rfc3984bis-12 > > which is in the RFC editor queue at the moment.) > I'll get that updated. Most of the fields are boilerplate. > > 2. The draft does not have a required congestion control section see > > http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06 for payload > > specification structure. > Checking: Is this currently draft-ietf-payload-rtp-howto-00? > Patrik did a pass at updating after being pointed at the document as > part of Magnus' review, that's the diff between the -00 and the -01 > version. > > 3. I noticed the division of the data to prediction mode parameters > and > > motion vectors partition and DCT/WHT coefficients partitions. Which > enables > > better resilience to loss according to the draft. In IP network the > typical > > loss is packet loss and not part of a packet so maybe in the > congestion > > control section you can provide some guideline about a recommendation > of how > > to build packets that can be removed. > Area of active research. I'll get it considered; the comment was part > of > a consideration of using variable-protection FEC mechanisms, which was > subsequently removed (we'll get back to that at a later stage). > > 4. In the example in section 6.4 I think that you should nave avpf > and not > > avp as the profile since you recommend using the feedback mechanism > It's only an example, but I agree. > > > > Going forward you can update the individual draft regardless of when > it > > becomes a WG item > Thanks! > > Regards > > Roni Even > > > > > > > >> -----Original Message----- > >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >> Behalf Of Harald Alvestrand > >> Sent: Wednesday, March 02, 2011 3:36 PM > >> To: payload@ietf.org > >> Subject: [payload] Request for consideration: draft-westin-payload- > vp8- > >> 01 > >> > >> Hello, > >> > >> I'm not sure what the formal procedure should be, so I'm just > sending > >> email... > >> I think that draft-westin-payload-vp8-01, describing an RTP > >> encapsulation for VP8, is ready for IETF review and possible > approval. > >> > >> What steps do we need to take in order to get it on the proper > agendas? > >> > >> Harald Alvestrand > >> > >> _______________________________________________ > >> payload mailing list > >> payload@ietf.org > >> https://www.ietf.org/mailman/listinfo/payload > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From Internet-Drafts@ietf.org Mon Mar 7 11:30:05 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6613A6819; Mon, 7 Mar 2011 11:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 iQP3XdL1D15T; Mon, 7 Mar 2011 11:30:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C28CA3A6813; Mon, 7 Mar 2011 11:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110307193002.16042.92079.idtracker@localhost> Date: Mon, 07 Mar 2011 11:30:02 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-payload-rfc4695-bis-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 19:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-payload-rfc4695-bis-02.txt Pages : 181 Date : 2011-03-07 This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. This document obsoletes RFC 4695. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc4695-bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-payload-rfc4695-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07112903.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Mar 7 13:15:03 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F163A6834; Mon, 7 Mar 2011 13:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 nNpwLZ0ah22l; Mon, 7 Mar 2011 13:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13733A6836; Mon, 7 Mar 2011 13:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110307211501.985.58452.idtracker@localhost> Date: Mon, 07 Mar 2011 13:15:01 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-payload-rfc3189bis-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for DV (IEC 61834) Video Author(s) : K. Kobayashi, et al. Filename : draft-ietf-payload-rfc3189bis-00.txt Pages : 18 Date : 2011-03-07 This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc3189bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-payload-rfc3189bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07131232.I-D@ietf.org> --NextPart-- From csp@csperkins.org Tue Mar 8 14:34:18 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B5BC3A672F for ; Tue, 8 Mar 2011 14:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 lc0hJwM-hTHL for ; Tue, 8 Mar 2011 14:34:17 -0800 (PST) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id 107243A659B for ; Tue, 8 Mar 2011 14:34:17 -0800 (PST) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.5]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Px5V5-0004n3-lW; Tue, 08 Mar 2011 22:35:31 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Tue, 8 Mar 2011 22:35:29 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D6E47BD.3000201@alvestrand.no> <04CAD96D4C5A3D48B1919248A8FE0D540E760844@xmb-sjc-215.amer.cisco.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) Cc: "payload@ietf.org" Subject: Re: [payload] Request for consideration: draft-westin-payload-vp8-01 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 22:34:18 -0000 I've read the -02 version of this draft. The RTP payload format looks to = be technically reasonable, and doesn't seem to duplicate existing work. = I'd support it becoming a working group document.=20 Colin On 2 Mar 2011, at 17:20, DRAGE, Keith (Keith) wrote: > I suspect this depends whether it needs discussion or not. >=20 > My understanding was that payloads were substantially meant to be a = matter for review and approval providing they followed the rules. >=20 > I would suggest you get a couple of experts to read it, see if it = makes sense and that it is not duplicating something that already = exists.=20 >=20 > If that comes back positive, put a message to the list to adopt a = milestone to progress it. >=20 > Follow that with a detailed expert review, then WGLC, then publication = request. >=20 > Now some of those may throw up something that requires face to face = time, but I don't think you are at that stage yet. >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf >> Of Ali C. Begen (abegen) >> Sent: 02 March 2011 13:48 >> To: Harald Alvestrand; payload@ietf.org >> Subject: Re: [payload] Request for consideration: = draft-westin-payload- >> vp8-01 >>=20 >> We can put you on the agenda. Since this is the first meeting after = AVT split, we will be sharing the same session with AVTcore. >>=20 >> How much time do you need? And we will need your slides to post them >> before the session. >>=20 >> -acbegen >>=20 >>> -----Original Message----- >>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >> Behalf Of Harald Alvestrand >>> Sent: Wednesday, March 02, 2011 8:36 AM >>> To: payload@ietf.org >>> Subject: [payload] Request for consideration: = draft-westin-payload-vp8- >> 01 >>>=20 >>> Hello, >>>=20 >>> I'm not sure what the formal procedure should be, so I'm just = sending >>> email... >>> I think that draft-westin-payload-vp8-01, describing an RTP >>> encapsulation for VP8, is ready for IETF review and possible = approval. >>>=20 >>> What steps do we need to take in order to get it on the proper = agendas? >>>=20 >>> Harald Alvestrand >>>=20 >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload --=20 Colin Perkins http://csperkins.org/ From Even.roni@huawei.com Sat Mar 12 23:50:09 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698B13A6AFA; Sat, 12 Mar 2011 23:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.863 X-Spam-Level: X-Spam-Status: No, score=-100.863 tagged_above=-999 required=5 tests=[AWL=-1.632, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 fQT2cbo7zL-M; Sat, 12 Mar 2011 23:50:08 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 25E493A6AEE; Sat, 12 Mar 2011 23:50:08 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHZ0068KKHJ4E@szxga05-in.huawei.com>; Sun, 13 Mar 2011 15:51:19 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHZ00E60KHJMZ@szxga05-in.huawei.com>; Sun, 13 Mar 2011 15:51:19 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-49-40.red.bezeqint.net [79.178.49.40]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHZ00APCKHAE5@szxml11-in.huawei.com>; Sun, 13 Mar 2011 15:51:18 +0800 (CST) Date: Sun, 13 Mar 2011 09:51:02 +0200 From: Roni Even To: avtcore@ietf.org Message-id: <000e01cbe153$6c0408d0$440c1a70$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_CoDPWe4tbQHbY87+fLB3Mg)" Content-language: en-us Thread-index: AcvhU2X2a9XvNQJDRGG8iYQiZZbjaQ== Cc: payload@ietf.org, xrblock@ietf.org Subject: [payload] Initial WGs agenda for IETF80 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 07:50:09 -0000 This is a multi-part message in MIME format. --Boundary_(ID_CoDPWe4tbQHbY87+fLB3Mg) Content-type: multipart/alternative; boundary="Boundary_(ID_fKKZa3ZucvlqTKId/bKyHA)" --Boundary_(ID_fKKZa3ZucvlqTKId/bKyHA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Attached is the initial avtcore WG agenda for IETF80. We will also spend some time on payload and xrblock status. Please let me know if the agenda look OK and if I missed any topics. Regards Roni Even --Boundary_(ID_fKKZa3ZucvlqTKId/bKyHA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Attached is the initial avtcore WG agenda for IETF80. We will also spend some time on payload and xrblock status.

Please let me know if the agenda look OK and if I missed any topics.

 

Regards

Roni Even

--Boundary_(ID_fKKZa3ZucvlqTKId/bKyHA)-- --Boundary_(ID_CoDPWe4tbQHbY87+fLB3Mg) Content-type: text/plain; name=a1103.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1103.txt Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Monday, 28 March 2011 at 13:00-15:00 (Congress Hall I) ------------------------------------------------------ 13:00 AVTCore Introduction and Status Update (Chairs, 15) 13:15 Payload Introduction and Status Update (Payload Chairs, 15) 13:30 XRBlock Introduction and Status Update (XRblock Chairs, 15) 13:45 Explicit Congestion Notification for RTP over UDP (Perkins, 10) draft-ietf-avt-ecn-for-rtp-03 13:55 RTCP Extension for Feedback Suppression Indication (Qin Wu, 10) draft-ietf-avtcore-feedback-supression-rtp-00 14:05 RTCP for inter-destination media synchronization(Ray van Brandenburg , 15) draft-brandenburg-avtcore-rtcp-for-idms-00 14:20 Monitoring Architectures for RTP (Qin Wu, 15) draft-hunt-avtcore-monarch-00 14:35 Multipath RTP (Varun Singh, 10) draft-singh-avtcore-mprtp-00 14:45 End --Boundary_(ID_CoDPWe4tbQHbY87+fLB3Mg) Content-type: text/html; name=a1103.html Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1103.html Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni Even

Monday, 28 March 2011 at 13:00-15:00 (Congress Hall I)

13:00 AVTCore Introduction and Status UpdateChairs
13:15 Payload Introduction and Status UpdatePayload Chairs
13:30 XRBlock Introduction and Status UpdateXRblock Chairs
13:45 Explicit Congestion Notification for RTP over UDPPerkins
draft-ietf-avt-ecn-for-rtp-03
13:55 RTCP Extension for Feedback Suppression IndicationQin Wu
draft-ietf-avtcore-feedback-supression-rtp-00
14:05 RTCP for inter-destination media synchronizationRay van Brandenburg
draft-brandenburg-avtcore-rtcp-for-idms-00
14:20 Monitoring Architectures for RTPQin Wu
draft-hunt-avtcore-monarch-00
14:35 Multipath RTP Varun Singh
draft-singh-avtcore-mprtp-00
14:45 End
--Boundary_(ID_CoDPWe4tbQHbY87+fLB3Mg)-- From Internet-Drafts@ietf.org Mon Mar 14 09:30:07 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBDA63A6D63; Mon, 14 Mar 2011 09:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 1R6bzLQqq5os; Mon, 14 Mar 2011 09:30:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA613A696C; Mon, 14 Mar 2011 09:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314163002.26365.266.idtracker@localhost> Date: Mon, 14 Mar 2011 09:30:02 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-payload-rtp-mvc-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:30:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for MVC Video Author(s) : Y. Wang, T. Schierl Filename : draft-ietf-payload-rtp-mvc-00.txt Pages : 25 Date : 2011-03-14 This memo describes an RTP payload format for the multiview extension of the ITU-T Recommendation H.264 video codec that is technically identical to ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units, produced by the video encoder, in each RTP payload. The payload format can be applied in RTP based 3D video transmissions such as such as 3D video streaming, free- viewpoint video, and 3DTV. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-mvc-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-payload-rtp-mvc-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14091530.I-D@ietf.org> --NextPart-- From Even.roni@huawei.com Tue Mar 15 00:56:23 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75873A68C9; Tue, 15 Mar 2011 00:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.231 X-Spam-Level: X-Spam-Status: No, score=-103.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 eEtb7k48xpkH; Tue, 15 Mar 2011 00:56:22 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 317473A6860; Tue, 15 Mar 2011 00:56:22 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI300180A3Z4L@szxga03-in.huawei.com>; Tue, 15 Mar 2011 15:57:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI300J6HA3ZWT@szxga03-in.huawei.com>; Tue, 15 Mar 2011 15:57:35 +0800 (CST) Received: from windows8d787f9 ([109.65.13.217]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LI300C8QA3TLJ@szxml11-in.huawei.com>; Tue, 15 Mar 2011 15:57:35 +0800 (CST) Date: Tue, 15 Mar 2011 09:57:18 +0200 From: Roni Even To: avtcore@ietf.org Message-id: <007901cbe2e6$9f7261a0$de5724e0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_X4q4IokVLGFbVi+elTXB1w)" Content-language: en-us Thread-index: Acvi5pqok4YqNQSpTqiXo0fFXVm76Q== Cc: payload@ietf.org, xrblock@ietf.org Subject: [payload] updated agenda for IETF80 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 07:56:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_X4q4IokVLGFbVi+elTXB1w) Content-type: multipart/alternative; boundary="Boundary_(ID_6YYjMML6YAeQoYRHlofl9A)" --Boundary_(ID_6YYjMML6YAeQoYRHlofl9A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I updated the agenda with the new drafts revisions as submitted before the submission cut-off Roni Even --Boundary_(ID_6YYjMML6YAeQoYRHlofl9A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

I updated the agenda with the new drafts revisions as submitted before the submission cut-off

Roni Even

--Boundary_(ID_6YYjMML6YAeQoYRHlofl9A)-- --Boundary_(ID_X4q4IokVLGFbVi+elTXB1w) Content-type: text/html; name=a1103.html Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1103.html Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni Even

Monday, 28 March 2011 at 13:00-15:00 (Congress Hall I)

13:00 AVTCore Introduction and Status UpdateChairs
13:15 Payload Introduction and Status UpdatePayload Chairs
13:30 XRBlock Introduction and Status UpdateXRblock Chairs
13:45 Explicit Congestion Notification for RTP over UDPPerkins
draft-ietf-avtcore-ecn-for-rtp-01
13:55 RTCP Extension for Feedback Suppression IndicationQin Wu
draft-ietf-avtcore-feedback-supression-rtp-00
14:05 RTCP for inter-destination media synchronizationRay van Brandenburg
draft-brandenburg-avtcore-rtcp-for-idms-00
14:20 Monitoring Architectures for RTPQin Wu
draft-hunt-avtcore-monarch-01
14:35 Multipath RTP Varun Singh
draft-singh-avtcore-mprtp-01
14:45 End
--Boundary_(ID_X4q4IokVLGFbVi+elTXB1w) Content-type: text/plain; name=a1103.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1103.txt Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Monday, 28 March 2011 at 13:00-15:00 (Congress Hall I) ------------------------------------------------------ 13:00 AVTCore Introduction and Status Update (Chairs, 15) 13:15 Payload Introduction and Status Update (Payload Chairs, 15) 13:30 XRBlock Introduction and Status Update (XRblock Chairs, 15) 13:45 Explicit Congestion Notification for RTP over UDP (Perkins, 10) draft-ietf-avtcore-ecn-for-rtp-01 13:55 RTCP Extension for Feedback Suppression Indication (Qin Wu, 10) draft-ietf-avtcore-feedback-supression-rtp-00 14:05 RTCP for inter-destination media synchronization(Ray van Brandenburg , 15) draft-brandenburg-avtcore-rtcp-for-idms-00 14:20 Monitoring Architectures for RTP (Qin Wu, 15) draft-hunt-avtcore-monarch-01 14:35 Multipath RTP (Varun Singh, 10) draft-singh-avtcore-mprtp-01 14:45 End --Boundary_(ID_X4q4IokVLGFbVi+elTXB1w)-- From iesg-secretary@ietf.org Thu Mar 17 15:01:55 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82C23A6B36; Thu, 17 Mar 2011 15:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 BVNUsoHEb7QT; Thu, 17 Mar 2011 15:01:55 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2C33A6B37; Thu, 17 Mar 2011 15:01:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110317220152.17329.33656.idtracker@localhost> Date: Thu, 17 Mar 2011 15:01:52 -0700 Cc: payload chair , Internet Architecture Board , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP Payload Format for MIDI' to Proposed Standard (draft-ietf-payload-rfc4695-bis-02.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 22:01:55 -0000 The IESG has approved the following document: - 'RTP Payload Format for MIDI' (draft-ietf-payload-rfc4695-bis-02.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-payload-rfc4695-bis/ Technical Summary This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. Working Group Summary The first version of the document came out in 2007 and the document was kept alive in order to capture any errata that will be discovered. The authors now feel that the implementations are stable and that it is time to publish the update. Document Quality There are existing implementations and this update for RFC 4695 is based on issues that were found by implementers. From yekui.wang@huawei.com Sun Mar 20 01:22:56 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782DD3A69ED; Sun, 20 Mar 2011 01:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NvwMqiMg6-kq; Sun, 20 Mar 2011 01:22:55 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id EF46B3A69D5; Sun, 20 Mar 2011 01:22:54 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIC00CR8KOP46@usaga02-in.huawei.com>; Sun, 20 Mar 2011 01:24:26 -0700 (PDT) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIC00FJ7KOPWR@usaga02-in.huawei.com>; Sun, 20 Mar 2011 01:24:25 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 20 Mar 2011 01:24:25 -0700 Received: from DFWEML504-MBX.china.huawei.com ([169.254.4.84]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Sun, 20 Mar 2011 01:24:24 -0700 Date: Sun, 20 Mar 2011 08:24:24 +0000 From: Ye-Kui Wang X-Originating-IP: [10.47.82.122] To: "payload@ietf.org" , "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-index: Acvm161AAF2A6AC0R/ODLEMZyh1IcgAAG9Hg X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: Re: [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 08:22:56 -0000 Rm9sa3MsDQoNClRoZSB0aHJlZSBILjI2NC9BVkMgcmVsYXRlZCBwYXlsb2FkIGZvcm1hdHMsIG5h bWVseSwgZHJhZnQtaWV0Zi1hdnQtcnRwLXJmYzM5ODRiaXMtMTIsIGRyYWZ0LWlldGYtYXZ0LXJ0 cC1zdmMtMjcsIGFuZCBkcmFmdC1pZXRmLWF2dC1ydHAtaDI2NC1yY2RvLTA4LCBhcmUgYWxsIGF0 IHRoZSBBVVRINDggc3RhZ2UuDQoNClRoZSBSRkMtRWRpdG9yIGhhcyBmb3VuZCB0aGUgZm9sbG93 aW5nIHByb2JsZW06IEluIGRyYWZ0LWlldGYtYXZ0LXJ0cC1yZmMzOTg0YmlzLTEyLCB0aGUgZGVm aW5pdGlvbiBvZiB0aGUgbWF4LWRwYiBtZWRpYSBwYXJhbWV0ZXIgcmVmZXJzIHRvIHRoZSBNYXhE UEIgdGhhdCB3YXMgZGVmaW5lZCB0aGUgZmlyc3QgdmVyc2lvbiBvZiB0aGUgSC4yNjQvQVZDIHNw ZWMsIGJ1dCBub3QgYW55IG1vcmUgaW4gdGhlIGxhdGVzdCB2ZXJzaW9uICh0aGUgMjAxMCB2ZXJz aW9uKS4gVGhlIHBhcmFtZXRlciBpbiB0aGUgbGF0ZXN0IEguMjY0L0FWQyB2ZXJzaW9uIGNvcnJl c3BvbmRpbmcgdG8gTWF4RFBCIGlzIE1heERwYk1icywgYW5kIHRoZSB1bml0IG9mIHRoZSBuZXcg cGFyYW1ldGVyIChpLmUuLCBtYWNyb2Jsb2NrcykgaXMgZGlmZmVyZW50IGZyb20gdGhlIG9yaWdp bmFsIG9uZSAoaS5lLiAxMDI0IGJ5dGVzKS4NCg0KVGhlIHByb2JsZW0gYXBwbGllcyBhbHNvIHRv IHRoZSBTVkMgcGF5bG9hZCBmb3JtYXQsIHRoZSBSQ0RPIHBheWxvYWQgZm9ybWF0LCBhbmQgSC4y NDEuDQoNCkEgc29sdXRpb24gaGFzIGJlZW4gZm91bmQgYW5kIGFncmVlZCwgaW52b2x2aW5nIHJm YzM5ODRiaXMgYXV0aG9ycyBhbmQgc29tZSBrZXkgcGVvcGxlIHJlbGF0ZWQgdG8gSC4yNjQvQVZD IChlLmcuLCBHYXJ5IFN1bGxpdmFuIGFuZCBIZWlrbyBTY2h3YXJ6KSBhbmQgSC4yNDEgKGUuZy4s IFN0ZXBoZW4gQm90emtvIGFuZCBQYXRyaWNrIEx1dGhpKS4gRnVydGhlcm1vcmUsIHdlIGhhdmUg Zm91bmQgdGhhdCB0aGVyZSBhcmUgYWxzbyBhIGNvdXBsZSBvZiBwbGFjZXMgdGhhdCBuZWVkIGZp eGVzIGR1ZSB0byBzaW1pbGFyIGNoYW5nZXMgZnJvbSB0aGUgaW5pdGlhbCB2ZXJzaW9uIG9mIEgu MjY0L0FWQyB0byB0aGUgbGF0ZXN0IHZlcnNpb24uDQoNClBlciBSb25p4oCZcyBzdWdnZXN0aW9u LCBJIGFtIHNlbmRpbmcgaW4gYmVsb3cgdGhlIGNoYW5nZXMgdG8gZHJhZnQtaWV0Zi1hdnQtcnRw LXJmYzM5ODRiaXMtMTIgZm9yIHJldmlldyBieSB0aGUgUGF5bG9hZCBhbmQgQVZUY29yZSBXR3Mu IEl0IHNlZW1zIHRoYXQgZXhhY3RseSB0aGUgc2FtZSBjaGFuZ2VzIGFyZSBuZWVkZWQgdG8gZHJh ZnQtaWV0Zi1hdnQtcnRwLWgyNjQtcmNkby0wOCAoY28tYXV0aG9ycyBvZiB0aGlzIGRyYWZ0IG1h eSBjb25maXJtKSwgYW5kIHNpbWlsYXIgYnV0IHNsaWdodGx5IGRpZmZlcmVudCBjaGFuZ2VzIGFy ZSBuZWVkZWQgdG8gZHJhZnQtaWV0Zi1hdnQtcnRwLXN2Yy0yNy4NCg0KU2luY2UgdGhlIGRyYWZ0 cyBhcmUgYXQgdGhlIEFVVEg0OCBzdGFnZSwgcGxlYXNlIHByb3ZpZGUgY29tbWVudHMgYnkgTW9u ZGF5LCBNYXJjaCAyMSwgaWYgYW55LiBNYW55IHRoYW5rcyENCg0KQlIsIFlLDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tU3RhcnQgb2Ygc3VnZ2VzdGVkIGNoYW5nZXMg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2VjdGlvbiA4LjE6DQpP TEQ6DQrCoMKgwqDCoMKgIHByb2ZpbGUtbGV2ZWwtaWQ6DQrCoMKgwqDCoMKgwqDCoMKgIEEgYmFz ZTE2IFs3XSAoaGV4YWRlY2ltYWwpIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBmb2xsb3dpbmcNCsKg wqDCoMKgwqDCoMKgwqAgdGhyZWUgYnl0ZXMgaW4gdGhlIHNlcXVlbmNlIHBhcmFtZXRlciBzZXQg TkFMIHVuaXQgaXMgc3BlY2lmaWVkDQrCoMKgwqDCoMKgwqDCoMKgIGluIFsxXTogMSkgcHJvZmls ZV9pZGMsIDIpIGEgYnl0ZSBoZXJlaW4gcmVmZXJyZWQgdG8gYXMNCsKgwqDCoMKgwqDCoCDCoMKg cHJvZmlsZS1pb3AsIGNvbXBvc2VkIG9mIHRoZSB2YWx1ZXMgb2YgY29uc3RyYWludF9zZXQwX2Zs YWcsDQrCoMKgwqDCoMKgwqDCoMKgIGNvbnN0cmFpbnRfc2V0MV9mbGFnLGNvbnN0cmFpbnRfc2V0 Ml9mbGFnLA0KwqDCoMKgwqDCoMKgwqDCoCBjb25zdHJhaW50X3NldDNfZmxhZywgYW5kIHJlc2Vy dmVkX3plcm9fNGJpdHMgaW4gYml0LQ0KwqDCoMKgwqDCoMKgwqDCoCBzaWduaWZpY2FuY2Ugb3Jk ZXIsIHN0YXJ0aW5nIGZyb20gdGhlIG1vc3Qtc2lnbmlmaWNhbnQgYml0LCBhbmQNCsKgwqDCoMKg IMKgwqDCoMKgMykgbGV2ZWxfaWRjLsKgIE5vdGUgdGhhdCByZXNlcnZlZF96ZXJvXzRiaXRzIGlz IHJlcXVpcmVkIHRvIGJlDQrCoMKgwqDCoMKgwqDCoMKgIGVxdWFsIHRvIDAgaW4gWzFdLCBidXQg b3RoZXIgdmFsdWVzIGZvciBpdCBtYXkgYmUgc3BlY2lmaWVkIGluDQrCoMKgwqDCoMKgwqDCoMKg IHRoZSBmdXR1cmUgYnkgSVRVLVQgb3IgSVNPL0lFQy4NCsKgTkVXOg0KwqDCoMKgwqDCoCBwcm9m aWxlLWxldmVsLWlkOg0KwqDCoMKgwqDCoMKgwqDCoCBBIGJhc2UxNiBbN10gKGhleGFkZWNpbWFs KSByZXByZXNlbnRhdGlvbiBvZiB0aGUgZm9sbG93aW5nDQrCoMKgwqDCoMKgwqDCoMKgIHRocmVl IGJ5dGVzIGluIHRoZSBzZXF1ZW5jZSBwYXJhbWV0ZXIgc2V0IE5BTCB1bml0IGlzIHNwZWNpZmll ZA0KwqDCoMKgwqDCoMKgwqDCoCBpbiBbMV06IDEpIHByb2ZpbGVfaWRjLCAyKSBhIGJ5dGUgaGVy ZWluIHJlZmVycmVkIHRvIGFzDQrCoMKgwqDCoMKgwqDCoMKgIHByb2ZpbGUtaW9wLCBjb21wb3Nl ZCBvZiB0aGUgdmFsdWVzIG9mIGNvbnN0cmFpbnRfc2V0MF9mbGFnLA0KwqDCoMKgwqDCoMKgwqDC oCBjb25zdHJhaW50X3NldDFfZmxhZyxjb25zdHJhaW50X3NldDJfZmxhZywNCsKgwqDCoMKgwqDC oMKgwqAgY29uc3RyYWludF9zZXQzX2ZsYWcsIGNvbnN0cmFpbnRfc2V0NF9mbGFnLCBjb25zdHJh aW50X3NldDVfZmxhZywNCuOAgOOAgOOAgOOAgMKgYW5kIHJlc2VydmVkX3plcm9fMmJpdHMgaW4g Yml0LXNpZ25pZmljYW5jZSBvcmRlciwgc3RhcnRpbmcgZnJvbSB0aGUgbW9zdC1zaWduaWZpY2Fu dCBiaXQsIGFuZA0KwqDCoMKgwqDCoMKgwqDCoCAzKSBsZXZlbF9pZGMuwqAgTm90ZSB0aGF0IHJl c2VydmVkX3plcm9fMmJpdHMgaXMgcmVxdWlyZWQgdG8gYmUNCsKgwqDCoMKgwqDCoMKgwqAgZXF1 YWwgdG8gMCBpbiBbMV0sIGJ1dCBvdGhlciB2YWx1ZXMgZm9yIGl0IG1heSBiZSBzcGVjaWZpZWQg aW4NCsKgwqDCoMKgwqDCoMKgwqAgdGhlIGZ1dHVyZSBieSBJVFUtVCBvciBJU08vSUVDLg0KDQpP TEQ6DQrCoMKgwqDCoMKgwqDCoMKgIEZvciBleGFtcGxlLCBpbiB0aGUgdGFibGUgYWJvdmUsIHBy b2ZpbGVfaWRjIGVxdWFsIHRvIDU4DQrCoMKgwqDCoMKgwqDCoMKgIChFeHRlbmRlZCkgd2l0aCBw cm9maWxlLWlvcCBlcXVhbCB0byAxMXh4MDAwMCBpbmRpY2F0ZXMgdGhlDQrCoMKgwqDCoMKgwqDC oMKgIHNhbWUgc3ViLXByb2ZpbGUgY29ycmVzcG9uZGluZyB0byBwcm9maWxlX2lkYyBlcXVhbCB0 byA0Mg0KwqDCoMKgwqDCoMKgwqDCoCAoQmFzZWxpbmUpIHdpdGggcHJvZmlsZS1pb3AgZXF1YWwg dG8geDF4eDAwMDAuwqAgTm90ZSB0aGF0IG90aGVyDQrCoMKgwqDCoMKgwqDCoMKgIGNvbWJpbmF0 aW9ucyBvZiBwcm9maWxlX2lkYyBhbmQgcHJvZmlsZS1pb3AgKG5vdCBsaXN0ZWQgaW4NCsKgwqDC oMKgwqDCoMKgwqAgVGFibGUgNSkgbWF5IHJlcHJlc2VudCBhIHN1Yi1wcm9maWxlIGVxdWl2YWxl bnQgdG8gdGhlIGNvbW1vbg0KwqDCoMKgwqDCoMKgwqDCoCBzdWJzZXQgb2YgY29kaW5nIHRvb2xz IGZvciBtb3JlIHRoYW4gb25lIHByb2ZpbGUuwqAgTm90ZSBhbHNvDQrCoMKgwqDCoMKgwqDCoMKg IHRoYXQgYSBkZWNvZGVyIGNvbmZvcm1pbmcgdG8gYSBjZXJ0YWluIHByb2ZpbGUgbWF5IGJlIGFi bGUgdG8NCsKgwqDCoMKgwqDCoMKgwqAgZGVjb2RlIGJpdHN0cmVhbXMgY29uZm9ybWluZyB0byBv dGhlciBwcm9maWxlcy7CoCBGb3IgZXhhbXBsZSwgYQ0KwqDCoMKgwqDCoCDCoMKgwqBkZWNvZGVy IGNvbmZvcm1pbmcgdG8gdGhlIEhpZ2ggNDo0OjQgcHJvZmlsZSwgYXQgYSBjZXJ0YWluDQrCoMKg wqDCoMKgwqDCoMKgIGxldmVsLCBtdXN0IGJlIGFibGUgdG8gZGVjb2RlIGJpdHN0cmVhbXMgY29u Zm9ybWluZyB0byB0aGUNCsKgwqDCoMKgwqDCoMKgwqAgQ29uc3RyYWluZWQgQmFzZWxpbmUsIE1h aW4sIEhpZ2gsIEhpZ2ggMTAsIG9yIEhpZ2ggNDoyOjINCsKgwqDCoMKgwqDCoMKgwqAgcHJvZmls ZSBhdCB0aGUgc2FtZSBvciBhIGxvd2VyIGxldmVsLg0KwqBORVc6DQrCoMKgwqDCoMKgwqAgwqDC oEZvciBleGFtcGxlLCBpbiB0aGUgdGFibGUgYWJvdmUsIHByb2ZpbGVfaWRjIGVxdWFsIHRvIDU4 DQrCoMKgwqDCoMKgwqDCoMKgIChFeHRlbmRlZCkgd2l0aCBwcm9maWxlLWlvcCBlcXVhbCB0byAx MXh4MDAwMCBpbmRpY2F0ZXMgdGhlDQrCoMKgwqDCoMKgwqDCoMKgIHNhbWUgc3ViLXByb2ZpbGUg Y29ycmVzcG9uZGluZyB0byBwcm9maWxlX2lkYyBlcXVhbCB0byA0Mg0KwqDCoMKgwqDCoMKgwqDC oCAoQmFzZWxpbmUpIHdpdGggcHJvZmlsZS1pb3AgZXF1YWwgdG8geDF4eDAwMDAuwqAgTm90ZSB0 aGF0IG90aGVyDQrCoMKgwqDCoMKgwqDCoMKgIGNvbWJpbmF0aW9ucyBvZiBwcm9maWxlX2lkYyBh bmQgcHJvZmlsZS1pb3AgKG5vdCBsaXN0ZWQgaW4NCsKgwqDCoMKgwqDCoMKgwqAgVGFibGUgNSkg bWF5IHJlcHJlc2VudCBhIHN1Yi1wcm9maWxlIGVxdWl2YWxlbnQgdG8gdGhlIGNvbW1vbg0KwqDC oMKgwqDCoMKgwqDCoCBzdWJzZXQgb2YgY29kaW5nIHRvb2xzIGZvciBtb3JlIHRoYW4gb25lIHBy b2ZpbGUuwqAgTm90ZSBhbHNvDQrCoMKgwqDCoMKgwqDCoMKgIHRoYXQgYSBkZWNvZGVyIGNvbmZv cm1pbmcgdG8gYSBjZXJ0YWluIHByb2ZpbGUgbWF5IGJlIGFibGUgdG8NCsKgwqDCoMKgwqDCoMKg wqAgZGVjb2RlIGJpdHN0cmVhbXMgY29uZm9ybWluZyB0byBvdGhlciBwcm9maWxlcy4NCg0KT0xE Og0KwqDCoMKgwqDCoMKgwqDCoCBJZiB0aGUgcHJvZmlsZS1sZXZlbC1pZCBwYXJhbWV0ZXIgaXMg dXNlZCBmb3IgY2FwYWJpbGl0eQ0KwqDCoMKgwqDCoMKgwqDCoCBleGNoYW5nZSBvciBzZXNzaW9u IHNldHVwIHByb2NlZHVyZSwgaXQgaW5kaWNhdGVzIHRoZSBzdWJzZXQgb2YNCsKgwqDCoMKgwqDC oMKgwqAgY29kaW5nIHRvb2xzLCB3aGljaCBpcyBlcXVhbCB0byB0aGUgZGVmYXVsdCBzdWItcHJv ZmlsZSwgdGhhdA0KwqDCoMKgwqDCoMKgwqDCoCB0aGUgY29kZWMgc3VwcG9ydHMgZm9yIGJvdGgg cmVjZWl2aW5nIGFuZCBzZW5kaW5nLg0KwqBORVc6DQrCoMKgwqDCoMKgwqDCoMKgIElmIHRoZSBw cm9maWxlLWxldmVsLWlkIHBhcmFtZXRlciBpcyB1c2VkIGZvciBjYXBhYmlsaXR5DQrCoMKgwqDC oMKgwqDCoMKgIGV4Y2hhbmdlIG9yIHNlc3Npb24gc2V0dXAsIGl0IGluZGljYXRlcyB0aGUgc3Vi c2V0IG9mDQrCoMKgwqAgwqDCoMKgwqDCoGNvZGluZyB0b29scywgd2hpY2ggaXMgZXF1YWwgdG8g dGhlIGRlZmF1bHQgc3ViLXByb2ZpbGUsIHRoYXQNCsKgwqDCoMKgwqDCoMKgwqAgdGhlIGNvZGVj IHN1cHBvcnRzIGZvciBib3RoIHJlY2VpdmluZyBhbmQgc2VuZGluZy4NCg0KT0xEOg0KwqDCoMKg wqDCoCBtYXgtY3BiOiBUaGUgdmFsdWUgb2YgbWF4LWNwYiBpcyBhbiBpbnRlZ2VyIGluZGljYXRp bmcgdGhlIG1heGltdW0NCsKgwqDCoMKgwqDCoMKgwqAgY29kZWQgcGljdHVyZSBidWZmZXIgc2l6 ZSBpbiB1bml0cyBvZiAxMDAwIGJpdHMgZm9yIHRoZSBWQ0wgSFJEDQrCoMKgwqDCoMKgwqDCoMKg IHBhcmFtZXRlcnMgKHNlZSBBLjMuMSwgaXRlbSBpIG9mIFsxXSkgYW5kIGluIHVuaXRzIG9mIDEy MDAgYml0cw0KwqDCoMKgwqDCoMKgwqDCoCBmb3IgdGhlIE5BTCBIUkQgcGFyYW1ldGVycyAoc2Vl IEEuMy4xLCBpdGVtIGogb2YgWzFdKS4NCk5FVzoNCsKgwqDCoMKgwqAgbWF4LWNwYjogVGhlIHZh bHVlIG9mIG1heC1jcGIgaXMgYW4gaW50ZWdlciBpbmRpY2F0aW5nIHRoZSBtYXhpbXVtDQrCoMKg wqDCoMKgwqDCoMKgIGNvZGVkIHBpY3R1cmUgYnVmZmVyIHNpemUuIEZvciBDb25zdHJhaW5lZCBC YXNlbGluZSwgQmFzZWxpbmUsIE1haW4gDQogICAgICAgICBhbmQgRXh0ZW5kZWQgcHJvZmlsZXMs IHRoZSB1bml0IGlzIDEwMDAgYml0cyBmb3IgdGhlIFZDTCBIUkQNCsKgwqDCoMKgwqDCoMKgwqAg cGFyYW1ldGVycyBhbmQgMTIwMCBiaXRzIGZvciB0aGUgTkFMIEhSRCBwYXJhbWV0ZXJzLiBGb3Ig SGlnaCwgSGlnaCAxMCwNCiAgICAgICAgIEhpZ2ggNDoyOjIsIEhpZ2ggNDo0OjQgUHJlZGljdGl2 ZSwgSGlnaCAxMCBJbnRyYSwgSGlnaCA0OjI6MiBJbnRyYSwgDQogICAgICAgICBIaWdoIDQ6NDo0 IEludHJhIGFuZCBDQVZMQyA0OjQ6NCBJbnRyYSBwcm9maWxlcywgdGhlIHVuaXQgaXMgY3BiQnJW Y2xGYWN0b3INCiAgICAgICAgIGJpdHMgZm9yIHRoZSBWQ0wgSFJEIGFuZCBjcGJCck5hbEZhY3Rv ciBiaXRzIGZvciB0aGUgTkFMIEhSRCBwYXJhbWV0ZXJzLg0KDQpPTEQ6DQrCoMKgwqDCoMKgIG1h eC1kcGI6IFRoZSB2YWx1ZSBvZiBtYXgtZHBiIGlzIGFuIGludGVnZXIgaW5kaWNhdGluZyB0aGUg bWF4aW11bQ0KwqDCoMKgwqDCoMKgwqDCoCBkZWNvZGVkIHBpY3R1cmUgYnVmZmVyIHNpemUgaW4g dW5pdHMgb2YgMTAyNCBieXRlcy7CoCBUaGUgbWF4LQ0KwqDCoMKgwqDCoMKgwqDCoCBkcGIgcGFy YW1ldGVyIHNpZ25hbHMgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIG1vcmUgbWVtb3J5IHRoYW4NCsKg wqDCoMKgwqDCoMKgwqAgdGhlIG1pbmltdW0gYW1vdW50IG9mIGRlY29kZWQgcGljdHVyZSBidWZm ZXIgbWVtb3J5IHJlcXVpcmVkIGJ5DQrCoMKgwqDCoMKgwqDCoMKgIHRoZSBzaWduYWxlZCBoaWdo ZXN0IGxldmVsIGNvbnZleWVkIGluIHRoZSB2YWx1ZSBvZiB0aGUNCsKgwqDCoMKgwqDCoMKgwqAg cHJvZmlsZS1sZXZlbC1pZCBwYXJhbWV0ZXIgb3IgdGhlIG1heC1yZWN2LWxldmVsIHBhcmFtZXRl ci4NCsKgwqDCoMKgwqDCoMKgwqAgV2hlbiBtYXgtZHBiIGlzIHNpZ25hbGVkLCB0aGUgcmVjZWl2 ZXIgTVVTVCBiZSBhYmxlIHRvIGRlY29kZQ0KwqDCoMKgwqDCoMKgwqDCoCBOQUwgdW5pdCBzdHJl YW1zIHRoYXQgY29uZm9ybSB0byB0aGUgc2lnbmFsZWQgaGlnaGVzdCBsZXZlbCwNCsKgwqDCoMKg wqDCoMKgwqAgd2l0aCB0aGUgZXhjZXB0aW9uIHRoYXQgdGhlIE1heERQQiB2YWx1ZSBpbiBUYWJs ZSBBLTEgb2YgWzFdDQrCoMKgwqDCoMKgwqDCoMKgIGZvciB0aGUgc2lnbmFsZWQgaGlnaGVzdCBs ZXZlbCBpcyByZXBsYWNlZCB3aXRoIHRoZSB2YWx1ZSBvZg0KwqDCoMKgwqDCoMKgwqDCoCBtYXgt ZHBiLsKgIENvbnNlcXVlbnRseSwgYSByZWNlaXZlciB0aGF0IHNpZ25hbHMgbWF4LWRwYiBNVVNU IGJlDQrCoMKgwqDCoMKgwqDCoMKgIGNhcGFibGUgb2Ygc3RvcmluZyB0aGUgZm9sbG93aW5nIG51 bWJlciBvZiBkZWNvZGVkIGZyYW1lcywNCsKgwqDCoMKgwqDCoMKgIMKgY29tcGxlbWVudGFyeSBm aWVsZCBwYWlycywgYW5kIG5vbi1wYWlyZWQgZmllbGRzIGluIGl0cyBkZWNvZGVkDQrCoMKgwqDC oMKgwqDCoMKgIHBpY3R1cmUgYnVmZmVyOg0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIE1pbigx MDI0ICogbWF4LWRwYiAvICggUGljV2lkdGhJbk1icyAqIEZyYW1lSGVpZ2h0SW5NYnMgKg0KwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAyNTYgKiBDaHJvbWFGb3JtYXRGYWN0b3IgKSwgMTYpDQoNCsKg wqDCoMKgwqDCoMKgwqAgUGljV2lkdGhJbk1icywgRnJhbWVIZWlnaHRJbk1icywgYW5kIENocm9t YUZvcm1hdEZhY3RvciBhcmUNCsKgwqDCoMKgwqDCoMKgwqAgZGVmaW5lZCBpbiBbMV0uDQoNCsKg wqDCoMKgwqDCoMKgwqAgVGhlIHZhbHVlIG9mIG1heC1kcGIgTVVTVCBiZSBncmVhdGVyIHRoYW4g b3IgZXF1YWwgdG8gdGhlIHZhbHVlDQrCoMKgwqDCoMKgwqDCoMKgIG9mIE1heERQQiBnaXZlbiBp biBUYWJsZSBBLTEgb2YgWzFdIGZvciB0aGUgaGlnaGVzdCBsZXZlbC4NCsKgwqDCoMKgwqDCoMKg wqAgU2VuZGVycyBNQVkgdXNlIHRoaXMga25vd2xlZGdlIHRvIGNvbnN0cnVjdCBjb2RlZCB2aWRl byBzdHJlYW1zDQrCoMKgwqDCoMKgwqDCoMKgIHdpdGggaW1wcm92ZWQgY29tcHJlc3Npb24uDQpO RVc6DQrCoMKgwqDCoMKgIG1heC1kcGI6IFRoZSB2YWx1ZSBvZiBtYXgtZHBiIGlzIGFuIGludGVn ZXIgaW5kaWNhdGluZyB0aGUgbWF4aW11bQ0KwqDCoMKgwqDCoMKgwqDCoCBkZWNvZGVkIHBpY3R1 cmUgYnVmZmVyIHNpemUgaW4gdW5pdHMgb2YgOC8zIG1hY3JvYmxvY2tzLsKgIFRoZSBtYXgtDQrC oMKgwqDCoMKgwqDCoMKgIGRwYiBwYXJhbWV0ZXIgc2lnbmFscyB0aGF0IHRoZSByZWNlaXZlciBo YXMgbW9yZSBtZW1vcnkgdGhhbg0KwqDCoMKgwqDCoMKgwqDCoCB0aGUgbWluaW11bSBhbW91bnQg b2YgZGVjb2RlZCBwaWN0dXJlIGJ1ZmZlciBtZW1vcnkgcmVxdWlyZWQgYnkNCsKgwqDCoMKgwqDC oMKgwqAgdGhlIHNpZ25hbGVkIGhpZ2hlc3QgbGV2ZWwgY29udmV5ZWQgaW4gdGhlIHZhbHVlIG9m IHRoZQ0KwqDCoMKgwqDCoMKgwqDCoCBwcm9maWxlLWxldmVsLWlkIHBhcmFtZXRlciBvciB0aGUg bWF4LXJlY3YtbGV2ZWwgcGFyYW1ldGVyLg0KwqDCoMKgwqDCoMKgwqDCoCBXaGVuIG1heC1kcGIg aXMgc2lnbmFsZWQsIHRoZSByZWNlaXZlciBNVVNUIGJlIGFibGUgdG8gZGVjb2RlDQrCoMKgwqDC oMKgwqDCoMKgIE5BTCB1bml0IHN0cmVhbXMgdGhhdCBjb25mb3JtIHRvIHRoZSBzaWduYWxlZCBo aWdoZXN0IGxldmVsLA0KwqDCoMKgwqDCoMKgwqDCoCB3aXRoIHRoZSBleGNlcHRpb24gdGhhdCB0 aGUgTWF4RHBiTWJzIHZhbHVlIGluIFRhYmxlIEEtMSBvZiBbMV0NCsKgwqDCoMKgwqDCoMKgwqAg Zm9yIHRoZSBzaWduYWxlZCBoaWdoZXN0IGxldmVsIGlzIHJlcGxhY2VkIHdpdGggdGhlIHZhbHVl IG9mDQrCoMKgwqDCoMKgwqDCoMKgIG1heC1kcGIgKiAzIC8gOC7CoCBDb25zZXF1ZW50bHksIGEg cmVjZWl2ZXIgdGhhdCBzaWduYWxzIG1heC1kcGIgTVVTVCBiZQ0KwqDCoMKgwqDCoMKgwqDCoCBj YXBhYmxlIG9mIHN0b3JpbmcgdGhlIGZvbGxvd2luZyBudW1iZXIgb2YgZGVjb2RlZCBmcmFtZXMs DQrCoMKgwqDCoMKgwqDCoMKgIGNvbXBsZW1lbnRhcnkgZmllbGQgcGFpcnMsIGFuZCBub24tcGFp cmVkIGZpZWxkcyBpbiBpdHMgZGVjb2RlZA0KwqDCoMKgwqDCoMKgwqDCoCBwaWN0dXJlIGJ1ZmZl cjoNCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBNaW4obWF4LWRwYiAqIDMgLyA4IC8gKCBQaWNX aWR0aEluTWJzICogRnJhbWVIZWlnaHRJbk1icyksIDE2KQ0KDQrCoMKgwqDCoMKgwqDCoMKgIFdo ZXJlaW4gUGljV2lkdGhJbk1icyBhbmQgRnJhbWVIZWlnaHRJbk1icyBhcmUgZGVmaW5lZCBpbiBb MV0uDQoNCsKgwqDCoMKgwqDCoMKgwqAgVGhlIHZhbHVlIG9mIG1heC1kcGIgTVVTVCBiZSBncmVh dGVyIHRoYW4gb3IgZXF1YWwgdG8gdGhlIHZhbHVlDQrCoMKgwqDCoMKgwqDCoMKgIG9mIE1heERw Yk1icyAqIDMgLyA4LCB3aGVyZWluIHRoZSB2YWx1ZSBvZiBNYXhEcGJNYnMgaXMgZ2l2ZW4gaW4g DQogICAgICAgICBUYWJsZSBBLTEgb2YgWzFdIGZvciB0aGUgaGlnaGVzdCBsZXZlbC4NCsKgwqDC oMKgwqDCoMKgwqAgU2VuZGVycyBNQVkgdXNlIHRoaXMga25vd2xlZGdlIHRvIGNvbnN0cnVjdCBj b2RlZCB2aWRlbyBzdHJlYW1zDQrCoMKgwqDCoMKgwqDCoMKgIHdpdGggaW1wcm92ZWQgY29tcHJl c3Npb24uDQoNCk9MRDoNCsKgwqDCoMKgwqAgbWF4LWJyOiBUaGUgdmFsdWUgb2YgbWF4LWJyIGlz IGFuIGludGVnZXIgaW5kaWNhdGluZyB0aGUgbWF4aW11bQ0KwqDCoMKgwqDCoMKgwqDCoCB2aWRl byBiaXRyYXRlIGluIHVuaXRzIG9mIDEwMDAgYml0cyBwZXIgc2Vjb25kIGZvciB0aGUgVkNMIEhS RA0KwqDCoMKgwqDCoMKgwqDCoCBwYXJhbWV0ZXJzIChzZWUgQS4zLjEsIGl0ZW0gaSBvZiBbMV0p IGFuZCBpbiB1bml0cyBvZiAxMjAwIGJpdHMNCsKgwqDCoMKgwqDCoMKgwqAgcGVyIHNlY29uZCBm b3IgdGhlIE5BTCBIUkQgcGFyYW1ldGVycyAoc2VlIEEuMy4xLCBpdGVtIGogb2YNCsKgwqDCoMKg wqDCoMKgwqAgWzFdKS4NCsKgwqDCoMKgwqDCoMKgwqAg4oCmDQrCoMKgwqDCoMKgwqDCoMKgIEZv ciBleGFtcGxlLCBpZiBhIHJlY2VpdmVyIHNpZ25hbHMgY2FwYWJpbGl0eSBmb3IgTGV2ZWwgMS4y DQrCoMKgwqDCoMKgwqDCoMKgIHdpdGggbWF4LWJyIGVxdWFsIHRvIDE1NTAsIHRoaXMgaW5kaWNh dGVzIGEgbWF4aW11bSB2aWRlbw0KwqDCoMKgwqDCoMKgwqDCoCBiaXRyYXRlIG9mIDE1NTAga2Jp dHMvc2VjIGZvciBWQ0wgSFJEIHBhcmFtZXRlcnMsIGEgbWF4aW11bQ0KwqDCoMKgwqDCoMKgwqDC oCB2aWRlbyBiaXRyYXRlIG9mIDE4NjAga2JpdHMvc2VjIGZvciBOQUwgSFJEIHBhcmFtZXRlcnMs IGFuZCBhDQrCoMKgwqDCoMKgwqDCoMKgIENQQiBzaXplIG9mIDQwMzY0NTggYml0cyAoMTU1MDAw MCAvIDM4NDAwMCAqIDEwMDAgKiAxMDAwKS4NCk5FVzogDQrCoMKgwqDCoMKgIG1heC1icjogVGhl IHZhbHVlIG9mIG1heC1iciBpcyBhbiBpbnRlZ2VyIGluZGljYXRpbmcgdGhlIG1heGltdW0NCsKg wqDCoMKgwqDCoMKgwqAgdmlkZW8gYml0cmF0ZS7CoCBGb3IgQ29uc3RyYWluZWQgQmFzZWxpbmUs IEJhc2VsaW5lLCBNYWluIA0KICAgICAgICAgYW5kIEV4dGVuZGVkIHByb2ZpbGVzLCB0aGUgdW5p dCBpcyAxMDAwIGJpdHMgcGVyIHNlY29uZCBmb3IgdGhlIFZDTCBIUkQNCsKgwqDCoMKgwqDCoMKg wqAgcGFyYW1ldGVycyBhbmQgMTIwMCBiaXRzIHBlciBzZWNvbmQgZm9yIHRoZSBOQUwgSFJEIHBh cmFtZXRlcnMuIEZvciBIaWdoLCBIaWdoIDEwLA0KICAgICAgICAgSGlnaCA0OjI6MiwgSGlnaCA0 OjQ6NCBQcmVkaWN0aXZlLCBIaWdoIDEwIEludHJhLCBIaWdoIDQ6MjoyIEludHJhLCANCiAgICAg ICAgIEhpZ2ggNDo0OjQgSW50cmEgYW5kIENBVkxDIDQ6NDo0IEludHJhIHByb2ZpbGVzLCB0aGUg dW5pdCBpcyBjcGJCclZjbEZhY3Rvcg0KICAgICAgICAgYml0cyBwZXIgc2Vjb25kIGZvciB0aGUg VkNMIEhSRCBhbmQgY3BiQnJOYWxGYWN0b3IgYml0cyBwZXIgc2Vjb25kIGZvciB0aGUgTkFMIEhS RCBwYXJhbWV0ZXJzLg0KwqDCoMKgwqDCoMKgwqDCoCDigKYNCsKgwqDCoMKgwqDCoMKgwqAgRm9y IGV4YW1wbGUsIGlmIGEgcmVjZWl2ZXIgc2lnbmFscyBjYXBhYmlsaXR5IGZvciBNYWluIHByb2Zp bGUgTGV2ZWwgMS4yDQrCoMKgwqDCoMKgwqDCoMKgIHdpdGggbWF4LWJyIGVxdWFsIHRvIDE1NTAs IHRoaXMgaW5kaWNhdGVzIGEgbWF4aW11bSB2aWRlbw0KwqDCoMKgwqDCoMKgwqDCoCBiaXRyYXRl IG9mIDE1NTAga2JpdHMvc2VjIGZvciBWQ0wgSFJEIHBhcmFtZXRlcnMsIGEgbWF4aW11bQ0KwqDC oMKgwqDCoMKgwqDCoCB2aWRlbyBiaXRyYXRlIG9mIDE4NjAga2JpdHMvc2VjIGZvciBOQUwgSFJE IHBhcmFtZXRlcnMsIGFuZCBhDQrCoMKgwqDCoMKgwqDCoMKgIENQQiBzaXplIG9mIDQwMzY0NTgg Yml0cyAoMTU1MDAwMCAvIDM4NDAwMCAqIDEwMDAgKiAxMDAwKS4NCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tRW5kIG9mIHN1Z2dlc3RlZCBjaGFuZ2VzIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From gwz@net-zen.net Sun Mar 20 02:15:19 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748EE3A6B9C for ; Sun, 20 Mar 2011 02:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 x+HBZj9Re9w1 for ; Sun, 20 Mar 2011 02:15:18 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id 91C8A3A6B98 for ; Sun, 20 Mar 2011 02:15:18 -0700 (PDT) Received: (qmail 8186 invoked from network); 20 Mar 2011 09:16:49 -0000 Received: from unknown (124.120.73.139) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 20 Mar 2011 09:16:48 -0000 Message-ID: <4D85C5FA.4010407@net-zen.net> Date: Sun, 20 Mar 2011 16:16:42 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: Ye-Kui Wang References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 20 Mar 2011 03:55:13 -0700 Cc: "avt@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 09:15:19 -0000 On 3/20/2011 3:20 PM, Ye-Kui Wang wrote: > Folks, > > > > The three H.264/AVC related payload formats, namely, > draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and > draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. > > > > The RFC-Editor has found the following problem: In > draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media > parameter refers to the MaxDPB that was defined the first version of the > H.264/AVC spec, but not any more in the latest version (the 2010 > version). The parameter in the latest H.264/AVC version corresponding to > MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., > macroblocks) is different from the original one (i.e. 1024 bytes). ... > Since the drafts are at the AUTH48 stage, please provide comments by > Monday, March 21, if any. Many thanks! Just my opinion but these seem like technical changes that can't really be dealt with in AUTH48. ... From yekui.wang@huawei.com Sun Mar 20 01:19:59 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6453A69ED; Sun, 20 Mar 2011 01:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5JmsHkOA3y1n; Sun, 20 Mar 2011 01:19:47 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 7E68D3A69D5; Sun, 20 Mar 2011 01:19:47 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIC00G0XKJIUU@usaga04-in.huawei.com>; Sun, 20 Mar 2011 03:21:18 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIC00M1ZKJHQP@usaga04-in.huawei.com>; Sun, 20 Mar 2011 03:21:17 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 20 Mar 2011 01:21:17 -0700 Received: from DFWEML504-MBX.china.huawei.com ([169.254.4.84]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Sun, 20 Mar 2011 01:20:46 -0700 Date: Sun, 20 Mar 2011 08:20:45 +0000 From: Ye-Kui Wang X-Originating-IP: [10.47.82.122] To: "payload@ietf.org" , "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1FJOVytJLbUE7c12TfBduA)" Content-language: en-US Accept-Language: en-US Thread-topic: Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-index: Acvm161AAF2A6AC0R/ODLEMZyh1Icg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Mailman-Approved-At: Sun, 20 Mar 2011 03:55:38 -0700 Subject: [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 08:19:59 -0000 --Boundary_(ID_1FJOVytJLbUE7c12TfBduA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Folks, The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is different from the original one (i.e. 1024 bytes). The problem applies also to the SVC payload format, the RCDO payload format, and H.241. A solution has been found and agreed, involving rfc3984bis authors and some key people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). Furthermore, we have found that there are also a couple of places that need fixes due to similar changes from the initial version of H.264/AVC to the latest version. Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different changes are needed to draft-ietf-avt-rtp-svc-27. Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many thanks! BR, YK ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_4bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. NEW: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. OLD: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. For example, a decoder conforming to the High 4:4:4 profile, at a certain level, must be able to decode bitstreams conforming to the Constrained Baseline, Main, High, High 10, or High 4:2:2 profile at the same or a lower level. NEW: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. OLD: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. NEW: If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size. For Constrained Baseline, Baseline, Main and Extended profiles, the unit is 1000 bits for the VCL HRD parameters and 1200 bits for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits for the VCL HRD and cpbBrNalFactor bits for the NAL HRD parameters. OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. NEW: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). ... For example, if a receiver signals capability for Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). NEW: max-br: The value of max-br is an integer indicating the maximum video bitrate. For Constrained Baseline, Baseline, Main and Extended profiles, the unit is 1000 bits per second for the VCL HRD parameters and 1200 bits per second for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits per second for the VCL HRD and cpbBrNalFactor bits per second for the NAL HRD parameters. ... For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). ------------------------------------End of suggested changes -------------------------------------- --Boundary_(ID_1FJOVytJLbUE7c12TfBduA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Folks,

 

The three H.264/AVC related pay= load formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-= svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage.

 

The RFC-Editor has found the fo= llowing problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the= max-dpb media parameter refers to the MaxDPB that was defined the first ve= rsion of the H.264/AVC spec, but not any more in the latest version (the 2010 version). The parameter in the la= test H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit o= f the new parameter (i.e., macroblocks) is different from the original one = (i.e. 1024 bytes).

 

The problem applies also to the= SVC payload format, the RCDO payload format, and H.241.<= /p>

 

A solution has been found and a= greed, involving rfc3984bis authors and some key people related to H.264/AV= C (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko a= nd Patrick Luthi). Furthermore, we have found that there are also a couple of places that need fixes due to simila= r changes from the initial version of H.264/AVC to the latest version.=

 

Per Roni’s suggestion, I = am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for rev= iew by the Payload and AVTcore WGs. It seems that exactly the same changes = are needed to draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different= changes are needed to draft-ietf-avt-rtp-svc-27.

 

Since the drafts are at the AUT= H48 stage, please provide comments by Monday, March 21, if any. Many thanks= !

 

BR, YK

 

 

----------------------------= --------Start of suggested changes --------------------------------------

 

Section= 8.1:

OLD:

      profile-level-id:<=
o:p>
         =
A base16 [7] (hexadecimal) representation of the following
         =
three bytes in the sequence parameter set NAL unit is specified<=
/span>
         =
in [1]: 1) profile_idc, 2) a byte herein referred to as

         =
profile-iop, composed of the values of constraint_set0_flag,


         =
constraint_set1_flag,constraint_set2_flag,


         =
constraint_set3_flag, and reserved_zero_4bits in bit-

         =
significance order, starting from the most-significant bit, and<=
/span>


         =
3) level_idc.  Note that reserved_zero_4bits is required to be


         =
equal to 0 in [1], but other values for it may be specified in


         =
the future by ITU-T or ISO/IEC.


 N=
EW:


   =
   profile-level-id:


   =
      A base16 [7] (hexadecimal) representation of=
 the following


   =
      three bytes in the sequence parameter set NA=
L unit is specified


   =
      in [1]: 1) profile_idc, 2) a byte herein ref=
erred to as


   =
      profile-iop, composed of the values of const=
raint_set0_flag,


   =
      constraint_set1_flag,constraint_set2_flag,


   =
      constraint_set3_flag, constraint_set4_flag, =
constraint_set5_flag,


=
 and reserved_zero_2bits in bit-significance order, starting from the =
most-significant bit, and


   =
      3) level_idc.  Note that reserved_zero_=
2bits is required to be


   =
      equal to 0 in [1], but other values for it m=
ay be specified in


   =
      the future by ITU-T or ISO/IEC.


&n=
bsp;


OLD:


         =
For example, in the table above, profile_idc equal to 58<=
/pre>

         =
(Extended) with profile-iop equal to 11xx0000 indicates the


         =
same sub-profile corresponding to profile_idc equal to 42=



         =
(Baseline) with profile-iop equal to x1xx0000.  Note that other


         =
combinations of profile_idc and profile-iop (not listed in


         =
Table 5) may represent a sub-profile equivalent to the common


         =
subset of coding tools for more than one profile.  Note also


         =
that a decoder conforming to a certain profile may be able to


         =
decode bitstreams conforming to other profiles.  For example, a


         =
decoder conforming to the High 4:4:4 profile, at a certain


         =
level, must be able to decode bitstreams conforming to the


         =
Constrained Baseline, Main, High, High 10, or High 4:2:2<=
/pre>

         =
profile at the same or a lower level.


 N=
EW:


   =
      For example, in the table above, profile_idc=
 equal to 58


   =
      (Extended) with profile-iop equal to 11xx000=
0 indicates the


   =
      same sub-profile corresponding to profile_id=
c equal to 42


   =
      (Baseline) with profile-iop equal to x1xx000=
0.  Note that other


   =
      combinations of profile_idc and profile-iop =
(not listed in


   =
      Table 5) may represent a sub-profile equival=
ent to the common


   =
      subset of coding tools for more than one pro=
file.  Note also


   =
      that a decoder conforming to a certain profi=
le may be able to


   =
      decode bitstreams conforming to other profil=
es.


 <=
/span>


OLD:


         =
If the profile-level-id parameter is used for capability<=
/pre>

         =
exchange or session setup procedure, it indicates the subset of<=
/span>


         =
coding tools, which is equal to the default sub-profile, that


         =
the codec supports for both receiving and sending.


 N=
EW:


   =
      If the profile-level-id parameter is used fo=
r capability


   =
      exchange or session setup, it indicates the =
subset of


   =
      coding tools, which is equal to the default =
sub-profile, that


   =
      the codec supports for both receiving and se=
nding.


&n=
bsp;


OLD:


   =
   max-cpb: The value of max-cpb is an integer indicating the max=
imum


   =
      coded picture buffer size in units of 1000 b=
its for the VCL HRD


   =
      parameters (see A.3.1, item i of [1]) and in=
 units of 1200 bits


   =
      for the NAL HRD parameters (see A.3.1, item =
j of [1]).


NEW:


   =
   max-cpb: The value of max-cpb is an integer indicating the max=
imum


   =
      coded picture buffer size. For Constrained B=
aseline, Baseline, Main



=
and Extended profiles, the unit is 1000 bits for the VCL HRD


   =
      parameters and 1200 bits for the NAL HRD par=
ameters. For High, High 10,


=
High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,



=
High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor=



=
bits for the VCL HRD and cpbBrNalFactor bits for the NAL HRD parameters.


 <=
/span>


OLD:


   =
   max-dpb: The value of max-dpb is an integer indicating the max=
imum


   =
      decoded picture buffer size in units of 1024=
 bytes.  The max-


   =
      dpb parameter signals that the receiver has =
more memory than


   =
      the minimum amount of decoded picture buffer=
 memory required by


   =
      the signaled highest level conveyed in the v=
alue of the


   =
      profile-level-id parameter or the max-recv-l=
evel parameter.


   =
      When max-dpb is signaled, the receiver MUST =
be able to decode


   =
      NAL unit streams that conform to the signale=
d highest level,


   =
      with the exception that the MaxDPB value in =
Table A-1 of [1]


   =
      for the signaled highest level is replaced w=
ith the value of


   =
      max-dpb.  Consequently, a receiver that=
 signals max-dpb MUST be


   =
      capable of storing the following number of d=
ecoded frames,


   =
      complementary field pairs, and non-paired fi=
elds in its decoded


   =
      picture buffer:


 <=
/span>


   =
         Min(1024 * max-dpb / ( Pic=
WidthInMbs * FrameHeightInMbs *


   =
         256 * ChromaFormatFactor )=
, 16)


 <=
/span>


   =
      PicWidthInMbs, FrameHeightInMbs, and ChromaF=
ormatFactor are


   =
      defined in [1].


 <=
/span>


   =
      The value of max-dpb MUST be greater than or=
 equal to the value


   =
      of MaxDPB given in Table A-1 of [1] for the =
highest level.


   =
      Senders MAY use this knowledge to construct =
coded video streams


   =
      with improved compression.=



NEW:


   =
   max-dpb: The value of max-dpb is an integer indicating the max=
imum


   =
      decoded picture buffer size in units of 8/3 =
macroblocks.  The max-


   =
      dpb parameter signals that the receiver has =
more memory than


   =
      the minimum amount of decoded picture buffer=
 memory required by


   =
      the signaled highest level conveyed in the v=
alue of the


   =
      profile-level-id parameter or the max-recv-l=
evel parameter.


   =
      When max-dpb is signaled, the receiver MUST =
be able to decode


   =
      NAL unit streams that conform to the signale=
d highest level,


   =
      with the exception that the MaxDpbMbs value =
in Table A-1 of [1]


   =
      for the signaled highest level is replaced w=
ith the value of


   =
      max-dpb * 3 / 8.  Consequently, a recei=
ver that signals max-dpb MUST be


   =
      capable of storing the following number of d=
ecoded frames,


   =
      complementary field pairs, and non-paired fi=
elds in its decoded


   =
      picture buffer:


 <=
/span>


   =
         Min(max-dpb * 3 / 8 / ( Pi=
cWidthInMbs * FrameHeightInMbs), 16)


 <=
/span>


   =
      Wherein PicWidthInMbs and FrameHeightInMbs a=
re defined in [1].


 <=
/span>


   =
      The value of max-dpb MUST be greater than or=
 equal to the value


   =
      of MaxDpbMbs * 3 / 8, wherein the value of M=
axDpbMbs is given in



=
Table A-1 of [1] for the highest level.


   =
      Senders MAY use this knowledge to construct =
coded video streams


   =
      with improved compression.=



 <=
/span>


OLD:


      max-br: The value =
of max-br is an integer indicating the maximum


         =
video bitrate in units of 1000 bits per second for the VCL HRD


         =
parameters (see A.3.1, item i of [1]) and in units of 1200 bits<=
/span>


         =
per second for the NAL HRD parameters (see A.3.1, item j of


         =
[1]).


         =
…


   =
      For example, if a receiver signals capabilit=
y for Level 1.2


   =
      with max-br equal to 1550, this indicates a =
maximum video


   =
      bitrate of 1550 kbits/sec for VCL HRD parame=
ters, a maximum


   =
      video bitrate of 1860 kbits/sec for NAL HRD =
parameters, and a


   =
      CPB size of 4036458 bits (1550000 / 384000 *=
 1000 * 1000).


NEW: 


      max-br: The value =
of max-br is an integer indicating the maximum


   =
      video bitrate.  For Constrained Baselin=
e, Baseline, Main



=
and Extended profiles, the unit is 1000 bits per second for the VCL HRD


   =
      parameters and 1200 bits per second for the =
NAL HRD parameters. For High, High 10,


=
High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,



=
High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor=



=
bits per second for the VCL HRD and cpbBrNalFactor bits per second for the =
NAL HRD parameters.


         =
…


   =
      For example, if a receiver signals capabilit=
y for Main profile Level 1.2


   =
      with max-br equal to 1550, this indicates a =
maximum video


   =
      bitrate of 1550 kbits/sec for VCL HRD parame=
ters, a maximum


   =
      video bitrate of 1860 kbits/sec for NAL HRD =
parameters, and a


   =
      CPB size of 4036458 bits (1550000 / 384000 *=
 1000 * 1000).


 


----------------------------=
--------End of suggested changes --------------------------------------


 
--Boundary_(ID_1FJOVytJLbUE7c12TfBduA)-- From Even.roni@huawei.com Sun Mar 20 05:24:49 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 826CF3A6BB8; Sun, 20 Mar 2011 05:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 8M2p+gy1NtdM; Sun, 20 Mar 2011 05:24:48 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 9371E3A6BB7; Sun, 20 Mar 2011 05:24:48 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIC00KM3VVLMQ@szxga05-in.huawei.com>; Sun, 20 Mar 2011 20:26:10 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIC00439VVKE5@szxga05-in.huawei.com>; Sun, 20 Mar 2011 20:26:09 +0800 (CST) Received: from windows8d787f9 (cust.static.109-164-246-172.swisscomdata.ch [109.164.246.172]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIC00AD4VUJT7@szxml12-in.huawei.com>; Sun, 20 Mar 2011 20:26:08 +0800 (CST) Date: Sun, 20 Mar 2011 14:25:10 +0200 From: Roni Even In-reply-to: <4D85C5FA.4010407@net-zen.net> To: 'Glen Zorn' , 'Ye-Kui Wang' , 'Robert Sparks' Message-id: <000701cbe6f9$f44b1e80$dce15b80$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acvm35YRpzpCX3JQSOWXj1OvEp108gADr0Sg References: <4D85C5FA.4010407@net-zen.net> Cc: avt@ietf.org, payload@ietf.org Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 12:24:49 -0000 Hi Glen, The technical change is more in H.264/AVC specification. In the payload specifications (3984bis/ RCDO and SVC) the change is to specify the conversion between the old and new parameter and to explain the change in H.264. It can be looked as a technical and I will leave it to the AD to help here. As for the quality of the change it was done by YK with the help of Steve Botzko (H.241 editor) and Gary Sullivan the Rapportuer of Q6 SG16 that does the video codec in a f2f meeting. It was also reviewed by me and by some other experts on video coding and I feel good about the solution, This change involves also an update to H.241 that has the same issue and the objective is to approve the H.241 change this week at the ongoing ITU Study Group 16 meeting. The solution for the IETF draft and ITU draft should be the same to address interoperability. Thanks Roni Even As individual. > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Glen Zorn > Sent: Sunday, March 20, 2011 11:17 AM > To: Ye-Kui Wang > Cc: avt@ietf.org; payload@ietf.org > Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO > payload drafts > > On 3/20/2011 3:20 PM, Ye-Kui Wang wrote: > > Folks, > > > > > > > > The three H.264/AVC related payload formats, namely, > > draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and > > draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. > > > > > > > > The RFC-Editor has found the following problem: In > > draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media > > parameter refers to the MaxDPB that was defined the first version of > the > > H.264/AVC spec, but not any more in the latest version (the 2010 > > version). The parameter in the latest H.264/AVC version corresponding > to > > MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., > > macroblocks) is different from the original one (i.e. 1024 bytes). > > ... > > > Since the drafts are at the AUTH48 stage, please provide comments by > > Monday, March 21, if any. Many thanks! > > Just my opinion but these seem like technical changes that can't really > be dealt with in AUTH48. > > ... > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From stewe@stewe.org Sun Mar 20 07:19:28 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04A73A6BC5; Sun, 20 Mar 2011 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 2XmZ-fG+1sZU; Sun, 20 Mar 2011 07:19:27 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id AB8863A6A03; Sun, 20 Mar 2011 07:19:26 -0700 (PDT) Received: from [156.106.237.64] (unverified [156.106.237.64]) by stewe.org (SurgeMail 3.9e) with ESMTP id 14264-1743317 for multiple; Sun, 20 Mar 2011 15:20:52 +0100 References: <4D85C5FA.4010407@net-zen.net> <000701cbe6f9$f44b1e80$dce15b80$%roni@huawei.com> In-Reply-To: <000701cbe6f9$f44b1e80$dce15b80$%roni@huawei.com> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <594FCF5C-180C-423E-A96B-E0BEB399A529@stewe.org> X-Mailer: iPhone Mail (8C148) From: Stephan Wenger Date: Sun, 20 Mar 2011 15:20:41 +0100 To: Roni Even X-Originating-IP: 156.106.237.64 X-Authenticated-User: stewe@stewe.org Cc: "payload@ietf.org" , Glen Zorn , "avt@ietf.org" Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 14:19:28 -0000 +1 Stephan (also in Geneve) Sent from my iPhone On Mar 20, 2011, at 13:25, Roni Even wrote: > Hi Glen, > The technical change is more in H.264/AVC specification. In the payload > specifications (3984bis/ RCDO and SVC) the change is to specify the > conversion between the old and new parameter and to explain the change in > H.264. > It can be looked as a technical and I will leave it to the AD to help here= . >=20 > As for the quality of the change it was done by YK with the help of Steve > Botzko (H.241 editor) and Gary Sullivan the Rapportuer of Q6 SG16 that doe= s > the video codec in a f2f meeting. It was also reviewed by me and by some > other experts on video coding and I feel good about the solution, >=20 > This change involves also an update to H.241 that has the same issue and t= he > objective is to approve the H.241 change this week at the ongoing ITU Stud= y > Group 16 meeting. The solution for the IETF draft and ITU draft should be > the same to address interoperability. >=20 > Thanks > Roni Even > As individual. >=20 >=20 >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Glen Zorn >> Sent: Sunday, March 20, 2011 11:17 AM >> To: Ye-Kui Wang >> Cc: avt@ietf.org; payload@ietf.org >> Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO >> payload drafts >>=20 >> On 3/20/2011 3:20 PM, Ye-Kui Wang wrote: >>> Folks, >>>=20 >>>=20 >>>=20 >>> The three H.264/AVC related payload formats, namely, >>> draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and >>> draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. >>>=20 >>>=20 >>>=20 >>> The RFC-Editor has found the following problem: In >>> draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media >>> parameter refers to the MaxDPB that was defined the first version of >> the >>> H.264/AVC spec, but not any more in the latest version (the 2010 >>> version). The parameter in the latest H.264/AVC version corresponding >> to >>> MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., >>> macroblocks) is different from the original one (i.e. 1024 bytes). >>=20 >> ... >>=20 >>> Since the drafts are at the AUTH48 stage, please provide comments by >>> Monday, March 21, if any. Many thanks! >>=20 >> Just my opinion but these seem like technical changes that can't really >> be dealt with in AUTH48. >>=20 >> ... >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From keith.drage@alcatel-lucent.com Mon Mar 21 03:28:52 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27D013A681C; Mon, 21 Mar 2011 03:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.777 X-Spam-Level: X-Spam-Status: No, score=-105.777 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2l12GTmsjSzk; Mon, 21 Mar 2011 03:28:51 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id C894B3A6818; Mon, 21 Mar 2011 03:28:50 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2LATHDE031448 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 21 Mar 2011 11:30:16 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 21 Mar 2011 11:29:55 +0100 From: "DRAGE, Keith (Keith)" To: Glen Zorn , Roni Even Date: Mon, 21 Mar 2011 11:29:54 +0100 Thread-Topic: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-Index: Acvnjt6mHYE390w2T4akPFUwjAYpLQAI8Gtw Message-ID: References: <4D85C5FA.4010407@net-zen.net> <000701cbe6f9$f44b1e80$dce15b80$%roni@huawei.com> <4D86EC09.2020304@net-zen.net> In-Reply-To: <4D86EC09.2020304@net-zen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "avt@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 10:28:52 -0000 Technical changes can be made, but they require the approval of the area di= rector, who has the right to either ask for consensus of the mailing list f= irst or indeed send it back to the working group. I would suggest we allow significantly longer than over the weekend for WG = comment before accepting the change, e.g. until Monday 28th March. Regards Keith > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Gle= n > Zorn > Sent: 21 March 2011 06:11 > To: Roni Even > Cc: payload@ietf.org; avt@ietf.org > Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload > drafts >=20 > On 3/20/2011 7:25 PM, Roni Even wrote: >=20 > > Hi Glen, > > The technical change is more in H.264/AVC specification. In the payload > > specifications (3984bis/ RCDO and SVC) the change is to specify the > > conversion between the old and new parameter and to explain the change > in > > H.264. > > It can be looked as a technical and I will leave it to the AD to help > here. > > > > As for the quality of the change it was done by YK with the help of > Steve > > Botzko (H.241 editor) and Gary Sullivan the Rapportuer of Q6 SG16 that > does > > the video codec in a f2f meeting. It was also reviewed by me and by som= e > > other experts on video coding and I feel good about the solution, >=20 > I'm admittedly not an expert on H.264, so I can't quibble about the > quality of the proposed solution. My comment is a procedural one: I > don't believe that technical changes are allowed after the completion of > IETF review, nor should they be. My understanding is that the AUTH48 > review is provided only as a last-minute opportunity to catch typos or > make small editorial changes, not to modify the technical content of a > document. BTW, I'm in the same boat myself right now: one of my > co-authors has fairly significant technical changes (and has proposed > even bigger ones) to a draft now in AUTH48 & I'm saying the same thing > about that one. I'm _not_ looking forward to restarting the whole > process, but OTOH my co-author (& for that matter, I) should have had > our act together before requesting publication. >=20 > > > > This change involves also an update to H.241 that has the same issue an= d > the > > objective is to approve the H.241 change this week at the ongoing ITU > Study > > Group 16 meeting. The solution for the IETF draft and ITU draft should > be > > the same to address interoperability. > > > > Thanks > > Roni Even > > As individual. > > > > > >> -----Original Message----- > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > >> Glen Zorn > >> Sent: Sunday, March 20, 2011 11:17 AM > >> To: Ye-Kui Wang > >> Cc: avt@ietf.org; payload@ietf.org > >> Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO > >> payload drafts > >> > >> On 3/20/2011 3:20 PM, Ye-Kui Wang wrote: > >>> Folks, > >>> > >>> > >>> > >>> The three H.264/AVC related payload formats, namely, > >>> draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and > >>> draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. > >>> > >>> > >>> > >>> The RFC-Editor has found the following problem: In > >>> draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media > >>> parameter refers to the MaxDPB that was defined the first version of > >> the > >>> H.264/AVC spec, but not any more in the latest version (the 2010 > >>> version). The parameter in the latest H.264/AVC version corresponding > >> to > >>> MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., > >>> macroblocks) is different from the original one (i.e. 1024 bytes). > >> > >> ... > >> > >>> Since the drafts are at the AUTH48 stage, please provide comments by > >>> Monday, March 21, if any. Many thanks! > >> > >> Just my opinion but these seem like technical changes that can't reall= y > >> be dealt with in AUTH48. > >> > >> ... > >> _______________________________________________ > >> Audio/Video Transport Core Maintenance > >> avt@ietf.org > >> https://www.ietf.org/mailman/listinfo/avt > > > > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From stephen.botzko@gmail.com Mon Mar 21 03:44:35 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4C3428C10A; Mon, 21 Mar 2011 03:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 NWzrweSy9IWi; Mon, 21 Mar 2011 03:44:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D9CE328C119; Mon, 21 Mar 2011 03:44:33 -0700 (PDT) Received: by vws12 with SMTP id 12so5938168vws.31 for ; Mon, 21 Mar 2011 03:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G15x4nuSZoqr2QLIQJV14kapCFKu3EET3t6EXVfhoDw=; b=DGPRJb2G8J9Bk9rUpT0kWJxDMW3Azz9YW6kFyVD0tmNojLu30y6S4QfAXmJc6p09Qz orjM6yAZkMj8i911IVqwamRb2qftS+rjXHYDM4eMtBgiSkxo/FEV2Ideg3sxzt+SW1O1 9Zzp3PYcToCh5DHYK1+cm5uGSkx4AtduBRjuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q7Cq/cUB1nqHDWJ1AZ/LfOYUQO5glcpU2jM7IgczVcQ/HJFCZK207qam5r5iz7pOUG 1qV8aPqrQS5IfcP+/V5/C8Mr4zZ1JQe5b57Ecf5O/Py0OTQ6ci/CaBbiPjARG3J7xo6E 7in4JiQEbWdaqDUoZU/tRL6ZhusSR7MOU77YU= MIME-Version: 1.0 Received: by 10.220.199.141 with SMTP id es13mr1112044vcb.73.1300704365849; Mon, 21 Mar 2011 03:46:05 -0700 (PDT) Received: by 10.220.170.196 with HTTP; Mon, 21 Mar 2011 03:46:05 -0700 (PDT) In-Reply-To: References: <4D85C5FA.4010407@net-zen.net> <000701cbe6f9$f44b1e80$dce15b80$%roni@huawei.com> <4D86EC09.2020304@net-zen.net> Date: Mon, 21 Mar 2011 11:46:05 +0100 Message-ID: From: Stephen Botzko To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=90e6ba53a014af2eb1049efbd5e5 Cc: "payload@ietf.org" , Glen Zorn , Roni Even , "avt@ietf.org" Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 10:44:35 -0000 --90e6ba53a014af2eb1049efbd5e5 Content-Type: text/plain; charset=ISO-8859-1 Delaying until 28 March makes sense for several reasons. The related change to H.241 should be submitted for consent on 25 March. Since the max-dbp parameter is intended to provide an equivalent codepoint to the one in H.241, it is sensible to wait for the H.241 outcome before locking this down. On the text itself, I am fine with it (presuming H.241 progresses as expected). It makes little sense for these new RFCs to refer to a superseded version of H.264, so there needs to be some change to the current text. In the end, the proposed change simply adjusts the units to be consistent with the current H.264. Since the units are scaled so the actual value on the wire is unchanged, it provides backwards compatibility. I don't personally see the need to send it back to the Working Group, but allowing time for WG comment is prudent. Stephen Botzko On Mon, Mar 21, 2011 at 11:29 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > Technical changes can be made, but they require the approval of the area > director, who has the right to either ask for consensus of the mailing list > first or indeed send it back to the working group. > > I would suggest we allow significantly longer than over the weekend for WG > comment before accepting the change, e.g. until Monday 28th March. > > Regards > > Keith > > > -----Original Message----- > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Glen > > Zorn > > Sent: 21 March 2011 06:11 > > To: Roni Even > > Cc: payload@ietf.org; avt@ietf.org > > Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload > > drafts > > > > On 3/20/2011 7:25 PM, Roni Even wrote: > > > > > Hi Glen, > > > The technical change is more in H.264/AVC specification. In the payload > > > specifications (3984bis/ RCDO and SVC) the change is to specify the > > > conversion between the old and new parameter and to explain the change > > in > > > H.264. > > > It can be looked as a technical and I will leave it to the AD to help > > here. > > > > > > As for the quality of the change it was done by YK with the help of > > Steve > > > Botzko (H.241 editor) and Gary Sullivan the Rapportuer of Q6 SG16 that > > does > > > the video codec in a f2f meeting. It was also reviewed by me and by > some > > > other experts on video coding and I feel good about the solution, > > > > I'm admittedly not an expert on H.264, so I can't quibble about the > > quality of the proposed solution. My comment is a procedural one: I > > don't believe that technical changes are allowed after the completion of > > IETF review, nor should they be. My understanding is that the AUTH48 > > review is provided only as a last-minute opportunity to catch typos or > > make small editorial changes, not to modify the technical content of a > > document. BTW, I'm in the same boat myself right now: one of my > > co-authors has fairly significant technical changes (and has proposed > > even bigger ones) to a draft now in AUTH48 & I'm saying the same thing > > about that one. I'm _not_ looking forward to restarting the whole > > process, but OTOH my co-author (& for that matter, I) should have had > > our act together before requesting publication. > > > > > > > > This change involves also an update to H.241 that has the same issue > and > > the > > > objective is to approve the H.241 change this week at the ongoing ITU > > Study > > > Group 16 meeting. The solution for the IETF draft and ITU draft should > > be > > > the same to address interoperability. > > > > > > Thanks > > > Roni Even > > > As individual. > > > > > > > > >> -----Original Message----- > > >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > > >> Glen Zorn > > >> Sent: Sunday, March 20, 2011 11:17 AM > > >> To: Ye-Kui Wang > > >> Cc: avt@ietf.org; payload@ietf.org > > >> Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO > > >> payload drafts > > >> > > >> On 3/20/2011 3:20 PM, Ye-Kui Wang wrote: > > >>> Folks, > > >>> > > >>> > > >>> > > >>> The three H.264/AVC related payload formats, namely, > > >>> draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and > > >>> draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. > > >>> > > >>> > > >>> > > >>> The RFC-Editor has found the following problem: In > > >>> draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media > > >>> parameter refers to the MaxDPB that was defined the first version of > > >> the > > >>> H.264/AVC spec, but not any more in the latest version (the 2010 > > >>> version). The parameter in the latest H.264/AVC version corresponding > > >> to > > >>> MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., > > >>> macroblocks) is different from the original one (i.e. 1024 bytes). > > >> > > >> ... > > >> > > >>> Since the drafts are at the AUTH48 stage, please provide comments by > > >>> Monday, March 21, if any. Many thanks! > > >> > > >> Just my opinion but these seem like technical changes that can't > really > > >> be dealt with in AUTH48. > > >> > > >> ... > > >> _______________________________________________ > > >> Audio/Video Transport Core Maintenance > > >> avt@ietf.org > > >> https://www.ietf.org/mailman/listinfo/avt > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --90e6ba53a014af2eb1049efbd5e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Delaying until 28 March makes sense for several reasons.

The related= change to H.241 should be submitted for consent on 25 March.=A0 Since the = max-dbp parameter is intended to provide an equivalent codepoint to the one= in H.241, it is sensible to wait for the H.241 outcome before locking this= down.

On the text itself, I am fine with it (presuming H.241 progresses as ex= pected).=A0 It makes little sense for these new RFCs to refer to a supersed= ed version of H.264, so there needs to be some change to the current text.= =A0 In the end, the proposed change simply adjusts the units to be consiste= nt with the current H.264.=A0 Since the units are scaled so the actual valu= e on the wire is unchanged, it provides backwards compatibility.=A0

I don't personally see the need to send it back to the Working Grou= p, but allowing time for WG comment is prudent.

Stephen Botzko
On Mon, Mar 21, 2011 at 11:29 AM, DRAGE, Keith= (Keith) <keith.drage@alcatel-lucent.com> wrote:
Technical changes= can be made, but they require the approval of the area director, who has t= he right to either ask for consensus of the mailing list first or indeed se= nd it back to the working group.

I would suggest we allow significantly longer than over the weekend for WG = comment before accepting the change, e.g. until Monday 28th March.

Regards

Keith

> -----Original Message-----
> From: avt-bounces@ietf.org= [mailto:avt-bounces@ietf.org] = On Behalf Of Glen
> Zorn
> Sent: 21 March 2011 06:11
> To: Roni Even
> Cc: payload@ietf.org; avt@ietf.org
> Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO paylo= ad
> drafts
>
> On 3/20/2011 7:25 PM, Roni Even wrote:
>
> > Hi Glen,
> > The technical change is more in H.264/AVC specification. In the p= ayload
> > specifications (3984bis/ RCDO and SVC) the change is to specify t= he
> > conversion between the old and new parameter and to explain the c= hange
> in
> > H.264.
> > It can be looked as a technical and I will leave it to the AD to = help
> here.
> >
> > As for the quality of the change it was done by YK with the help = of
> Steve
> > Botzko (H.241 editor) and Gary Sullivan the Rapportuer of Q6 SG16= that
> does
> > the video codec in a f2f meeting. It was also reviewed by me and = by some
> > other experts on video coding and I feel good about the solution,=
>
> I'm admittedly not an expert on H.264, so I can't quibble abou= t the
> quality of the proposed solution. =A0My comment is a procedural one: I=
> don't believe that technical changes are allowed after the complet= ion of
> IETF review, nor should they be. =A0My understanding is that the AUTH4= 8
> review is provided only as a last-minute opportunity to catch typos or=
> make small editorial changes, not to modify the technical content of a=
> document. =A0BTW, I'm in the same boat myself right now: one of my=
> co-authors has fairly significant technical changes (and has proposed<= br> > even bigger ones) to a draft now in AUTH48 & I'm saying the sa= me thing
> about that one. =A0I'm _not_ looking forward to restarting the who= le
> process, but OTOH my co-author (& for that matter, I) should have = had
> our act together before requesting publication.
>
> >
> > This change involves also an update to H.241 that has the same is= sue and
> the
> > objective is to approve the H.241 change this week at the ongoing= ITU
> Study
> > Group 16 meeting. The solution for the IETF draft and ITU draft s= hould
> be
> > the same to address interoperability.
> >
> > Thanks
> > Roni Even
> > As individual.
> >
> >
> >> -----Original Message-----
> >> From: avt-bounces@iet= f.org [mailto:avt-bounces@ietf.= org] On Behalf Of
> >> Glen Zorn
> >> Sent: Sunday, March 20, 2011 11:17 AM
> >> To: Ye-Kui Wang
> >> Cc: avt@ietf.org; payload@ietf.org
> >> Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and R= CDO
> >> payload drafts
> >>
> >> On 3/20/2011 3:20 PM, Ye-Kui Wang wrote:
> >>> Folks,
> >>>
> >>>
> >>>
> >>> The three H.264/AVC related payload formats, namely,
> >>> draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-= 27, and
> >>> draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 st= age.
> >>>
> >>>
> >>>
> >>> The RFC-Editor has found the following problem: In
> >>> draft-ietf-avt-rtp-rfc3984bis-12, the definition of the m= ax-dpb media
> >>> parameter refers to the MaxDPB that was defined the first= version of
> >> the
> >>> H.264/AVC spec, but not any more in the latest version (t= he 2010
> >>> version). The parameter in the latest H.264/AVC version c= orresponding
> >> to
> >>> MaxDPB is MaxDpbMbs, and the unit of the new parameter (i= .e.,
> >>> macroblocks) is different from the original one (i.e. 102= 4 bytes).
> >>
> >> ...
> >>
> >>> Since the drafts are at the AUTH48 stage, please provide = comments by
> >>> Monday, March 21, if any. Many thanks!
> >>
> >> Just my opinion but these seem like technical changes that ca= n't really
> >> be dealt with in AUTH48.
> >>
> >> ...
> >> _______________________________________________
> >> Audio/Video Transport Core Maintenance
> >> avt@ietf.org
> >> https://www.ietf.org/mailman/listinfo/avt
> >
> >
> >
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload

--90e6ba53a014af2eb1049efbd5e5-- From gwz@net-zen.net Sun Mar 20 23:10:01 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DB83A67B5 for ; Sun, 20 Mar 2011 23:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 aQRIoah7XpNF for ; Sun, 20 Mar 2011 23:09:56 -0700 (PDT) Received: from smtpauth20.prod.mesa1.secureserver.net (smtpauth20.prod.mesa1.secureserver.net [64.202.165.36]) by core3.amsl.com (Postfix) with SMTP id 2971E3A67B3 for ; Sun, 20 Mar 2011 23:09:56 -0700 (PDT) Received: (qmail 12301 invoked from network); 21 Mar 2011 06:11:28 -0000 Received: from unknown (124.122.150.171) by smtpauth20.prod.mesa1.secureserver.net (64.202.165.36) with ESMTP; 21 Mar 2011 06:11:27 -0000 Message-ID: <4D86EC09.2020304@net-zen.net> Date: Mon, 21 Mar 2011 13:11:21 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: Roni Even References: <4D85C5FA.4010407@net-zen.net> <000701cbe6f9$f44b1e80$dce15b80$%roni@huawei.com> In-Reply-To: <000701cbe6f9$f44b1e80$dce15b80$%roni@huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 21 Mar 2011 05:20:45 -0700 Cc: payload@ietf.org, avt@ietf.org Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 06:10:01 -0000 On 3/20/2011 7:25 PM, Roni Even wrote: > Hi Glen, > The technical change is more in H.264/AVC specification. In the payload > specifications (3984bis/ RCDO and SVC) the change is to specify the > conversion between the old and new parameter and to explain the change in > H.264. > It can be looked as a technical and I will leave it to the AD to help here. > > As for the quality of the change it was done by YK with the help of Steve > Botzko (H.241 editor) and Gary Sullivan the Rapportuer of Q6 SG16 that does > the video codec in a f2f meeting. It was also reviewed by me and by some > other experts on video coding and I feel good about the solution, I'm admittedly not an expert on H.264, so I can't quibble about the quality of the proposed solution. My comment is a procedural one: I don't believe that technical changes are allowed after the completion of IETF review, nor should they be. My understanding is that the AUTH48 review is provided only as a last-minute opportunity to catch typos or make small editorial changes, not to modify the technical content of a document. BTW, I'm in the same boat myself right now: one of my co-authors has fairly significant technical changes (and has proposed even bigger ones) to a draft now in AUTH48 & I'm saying the same thing about that one. I'm _not_ looking forward to restarting the whole process, but OTOH my co-author (& for that matter, I) should have had our act together before requesting publication. > > This change involves also an update to H.241 that has the same issue and the > objective is to approve the H.241 change this week at the ongoing ITU Study > Group 16 meeting. The solution for the IETF draft and ITU draft should be > the same to address interoperability. > > Thanks > Roni Even > As individual. > > >> -----Original Message----- >> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of >> Glen Zorn >> Sent: Sunday, March 20, 2011 11:17 AM >> To: Ye-Kui Wang >> Cc: avt@ietf.org; payload@ietf.org >> Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO >> payload drafts >> >> On 3/20/2011 3:20 PM, Ye-Kui Wang wrote: >>> Folks, >>> >>> >>> >>> The three H.264/AVC related payload formats, namely, >>> draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and >>> draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. >>> >>> >>> >>> The RFC-Editor has found the following problem: In >>> draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media >>> parameter refers to the MaxDPB that was defined the first version of >> the >>> H.264/AVC spec, but not any more in the latest version (the 2010 >>> version). The parameter in the latest H.264/AVC version corresponding >> to >>> MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., >>> macroblocks) is different from the original one (i.e. 1024 bytes). >> >> ... >> >>> Since the drafts are at the AUTH48 stage, please provide comments by >>> Monday, March 21, if any. Many thanks! >> >> Just my opinion but these seem like technical changes that can't really >> be dealt with in AUTH48. >> >> ... >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt > > > From yekui.wang@huawei.com Mon Mar 21 01:10:10 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C3273A67F0; Mon, 21 Mar 2011 01:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PCCx2gwtM0Bw; Mon, 21 Mar 2011 01:09:57 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 3BE3E28C111; Mon, 21 Mar 2011 01:09:57 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIE00B81ER271@usaga04-in.huawei.com>; Mon, 21 Mar 2011 03:11:27 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIE00FIJER143@usaga04-in.huawei.com>; Mon, 21 Mar 2011 03:11:26 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 21 Mar 2011 01:11:25 -0700 Received: from DFWEML504-MBX.china.huawei.com ([169.254.4.84]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Mon, 21 Mar 2011 01:11:24 -0700 Date: Mon, 21 Mar 2011 08:11:23 +0000 From: Ye-Kui Wang In-reply-to: X-Originating-IP: [10.47.86.236] To: "payload@ietf.org" , "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hcR2NkBpOkdtxtm59hGaDw)" Content-language: en-US Accept-Language: en-US Thread-topic: Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-index: Acvm161AAF2A6AC0R/ODLEMZyh1IcgAwzyEA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: X-Mailman-Approved-At: Mon, 21 Mar 2011 05:20:46 -0700 Subject: Re: [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 08:10:10 -0000 --Boundary_(ID_hcR2NkBpOkdtxtm59hGaDw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD. BR, YK ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_4bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. NEW: (note that the change here is purely editorial) profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. OLD: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. For example, a decoder conforming to the High 4:4:4 profile, at a certain level, must be able to decode bitstreams conforming to the Constrained Baseline, Main, High, High 10, or High 4:2:2 profile at the same or a lower level. NEW: (note that the change here is purely editorial) For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. OLD: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. NEW: (note that the change here is purely editorial) If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: (note that the change here is purely editorial) max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters and in units of 1200 bits for the NAL HRD parameters. OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. NEW: (When this change can be considered as editorial can be discussed, but the nature of this change as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). ... For example, if a receiver signals capability for Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). NEW: (note that the change here is purely editorial) max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters and in units of 1200 bits per second for the NAL HRD parameters. ... For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). ------------------------------------End of suggested changes -------------------------------------- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Sunday, March 20, 2011 4:21 AM To: payload@ietf.org; avt@ietf.org Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts Folks, The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is different from the original one (i.e. 1024 bytes). The problem applies also to the SVC payload format, the RCDO payload format, and H.241. A solution has been found and agreed, involving rfc3984bis authors and some key people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). Furthermore, we have found that there are also a couple of places that need fixes due to similar changes from the initial version of H.264/AVC to the latest version. Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different changes are needed to draft-ietf-avt-rtp-svc-27. Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many thanks! BR, YK --Boundary_(ID_hcR2NkBpOkdtxtm59hGaDw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Furt= her discussions with the same group of persons led to a decision to stay wi= th the unscaled units for max-br and max-cpb, thus fewer changes are needed= to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the o= riginally suggested changes are dropped from this email). This time I have = highlighted the changes, and I have also described the nature the changes b= elow. Hope these may help understand better what have been changed, and can lead to a quicker decision by the g= roup, including WG chairs, and our AD.

 

BR, = YK

 

----------------------------= --------Start of suggested changes --------------------------------------

 

Section= 8.1:

OLD:

      profile-level-id:<=
o:p>
         =
A base16 [7] (hexadecimal) representation of the following
         =
three bytes in the sequence parameter set NAL unit is specified<=
/span>
         =
in [1]: 1) profile_idc, 2) a byte herein referred to as

         =
profile-iop, composed of the values of constraint_set0_flag,


         =
constraint_set1_flag,constraint_set2_flag,


         =
constraint_set3_flag, and reserved_zero_4bits in bit-

         =
significance order, starting from the most-significant bit, and<=
/span>


         =
3) level_idc.  Note that reserved_zero_4bits is required to be


         =
equal to 0 in [1], but other values for it may be specified in


         =
the future by ITU-T or ISO/IEC.


 N=
EW: 
(note that the change here is purely editorial)

   =
   profile-level-id:


   =
      A base16 [7] (hexadecimal) representation of=
 the following


   =
      three bytes in the sequence parameter set NA=
L unit is specified


   =
      in [1]: 1) profile_idc, 2) a byte herein ref=
erred to as


   =
      profile-iop, composed of the values of const=
raint_set0_flag,


   =
      constraint_set1_flag,constraint_set2_flag,


   =
      constraint_set3_flag,
constraint_set4_flag=
, constraint_set5_flag,


 and reserved_zero_2bits
 in bit-significance order, starting from the most-significant bit, and


   =
      3) level_idc.  Note that reserved_zero_=
2bits is required to be


   =
      equal to 0 in [1], but other values for it m=
ay be specified in


   =
      the future by ITU-T or ISO/IEC.


&n=
bsp;


OLD:


         =
For example, in the table above, profile_idc equal to 58<=
/pre>

         =
(Extended) with profile-iop equal to 11xx0000 indicates the


         =
same sub-profile corresponding to profile_idc equal to 42=



         =
(Baseline) with profile-iop equal to x1xx0000.  Note that other


         =
combinations of profile_idc and profile-iop (not listed in


         =
Table 5) may represent a sub-profile equivalent to the common


         =
subset of coding tools for more than one profile.  Note also


         =
that a decoder conforming to a certain profile may be able to


         =
decode bitstreams conforming to other profiles.  For example, a


 =
        decoder conforming to the High 4=
:4:4 profile, at a certain


 =
        level, must be able to decode bi=
tstreams conforming to the


 =
        Constrained Baseline, Main, High=
, High 10, or High 4:2:2


 =
        profile at the same or a lower l=
evel.


 N=
EW: 
(note that the change here is purely editorial)

   =
      For example, in the table above, profile_idc=
 equal to 58


   =
      (Extended) with profile-iop equal to 11xx000=
0 indicates the


   =
      same sub-profile corresponding to profile_id=
c equal to 42


   =
      (Baseline) with profile-iop equal to x1xx000=
0.  Note that other


   =
      combinations of profile_idc and profile-iop =
(not listed in


   =
      Table 5) may represent a sub-profile equival=
ent to the common


   =
      subset of coding tools for more than one pro=
file.  Note also


   =
      that a decoder conforming to a certain profi=
le may be able to


   =
      decode bitstreams conforming to other profil=
es.


 <=
/span>


OLD:


         =
If the profile-level-id parameter is used for capability<=
/pre>

         =
exchange or session setup =
procedure, it indicates the subset of


         =
coding tools, which is equal to the default sub-profile, that


         =
the codec supports for both receiving and sending.


 N=
EW: 
(note that the change here is purely editorial)

   =
      If the profile-level-id parameter is used fo=
r capability


   =
      exchange or session setup, it indicates the =
subset of


   =
      coding tools, which is equal to the default =
sub-profile, that


   =
      the codec supports for both receiving and se=
nding.


&n=
bsp;


OLD: 


   =
   max-cpb: The value of max-cpb is an integer indicating the max=
imum


   =
      coded picture buffer size in units of 1000 b=
its for the VCL HRD


   =
      parameters
(see A.3.1, item i of [1])=
 and in units of 1200 bits


   =
      for the NAL HRD parameters
(see A.3.1, item j of [1])=
.


NEW: 
(note that the change here is purely editorial)

   =
   max-cpb: The value of max-cpb is an integer indicating the max=
imum


   =
      coded picture buffer size in units of 1000 b=
its for the VCL HRD


   =
      parameters and in units of 1200 bits


   =
      for the NAL HRD parameters.


 <=
/span>


OLD:


   =
   max-dpb: The value of max-dpb is an integer indicating the max=
imum


   =
      decoded picture buffer size in units of 1024=
 bytes.  The max-


   =
      dpb parameter signals that the receiver has =
more memory than


   =
      the minimum amount of decoded picture buffer=
 memory required by


   =
      the signaled highest level conveyed in the v=
alue of the


   =
      profile-level-id parameter or the max-recv-l=
evel parameter.


   =
      When max-dpb is signaled, the receiver MUST =
be able to decode


   =
      NAL unit streams that conform to the signale=
d highest level,


   =
      with the exception that the MaxDPB value in =
Table A-1 of [1]


   =
      for the signaled highest level is replaced w=
ith the value of


   =
      max-dpb.  Consequently, a receiver that=
 signals max-dpb MUST be


   =
      capable of storing the following number of d=
ecoded frames,


   =
      complementary field pairs, and non-paired fi=
elds in its decoded


   =
      picture buffer:


 <=
/span>


   =
         Min(1024 * max-dpb / ( Pic=
WidthInMbs * FrameHeightInMbs *


   =
         256 * ChromaFormatFactor )=
, 16)


 <=
/span>


   =
      PicWidthInMbs, FrameHeightInMbs, and ChromaF=
ormatFactor are


    =
;     defined in [1].


 <=
/span>


   =
      The value of max-dpb MUST be greater than or=
 equal to the value


   =
      of MaxDPB given in Table A-1 of [1] for the =
highest level.


   =
      Senders MAY use this knowledge to construct =
coded video streams


   =
      with improved compression.=



NEW: 
(When this change can be considered as editorial can be discussed, but the =
nature of this change as follows. On the other hand, if not changed, then t=
he semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and =
ChromaFormatFactor are not found
 in the latest H.264 spec any more. Note that compared to RFC 3984, the bit=
s on the wire do not change.)


   =
   max-dpb: The value of max-dpb is an integer indicating the max=
imum


   =
      decoded picture buffer size in units of 8/3 =
macroblocks.  The max-


   =
      dpb parameter signals that the receiver has =
more memory than


   =
      the minimum amount of decoded picture buffer=
 memory required by


   =
      the signaled highest level conveyed in the v=
alue of the


   =
      profile-level-id parameter or the max-recv-l=
evel parameter.


   =
      When max-dpb is signaled, the receiver MUST =
be able to decode


   =
      NAL unit streams that conform to the signale=
d highest level,


   =
      with the exception that
the MaxDpbMbs value =
in Table A-1 of [1]


         for the signaled h=
ighest level is replaced with the value of


         max-dpb * 3 / 8.&nb=
sp;
 Consequently, a receiver that signals max-dpb MUST be

   =
      capable of storing the following number of d=
ecoded frames,


   =
      complementary field pairs, and non-paired fi=
elds in its decoded


   =
      picture buffer:


 <=
/span>


   =
        
Min(max-dpb * 3 / 8 =
/ ( PicWidthInMbs * FrameHeightInMbs), 16)


 


         Wherein PicWidthIn=
Mbs and FrameHeightInMbs are defined in [1].


 <=
/span>


   =
      The value of max-dpb MUST be greater than or=
 equal to the value


   =
      of
MaxDpbMbs * 3 / 8, w=
herein the value of MaxDpbMbs is given in



Table A-1 of [1] for the highest level.


   =
      Senders MAY use this knowledge to construct =
coded video streams


   =
      with improved compression.=



 <=
/span>


OLD:


      max-br: The value =
of max-br is an integer indicating the maximum


         =
video bitrate in units of 1000 bits per second for the VCL HRD


         =
parameters (see A.3.1, ite=
m i of [1]) and in units of 1200 bits


         =
per second for the NAL HRD parameters (see A.3.1, item j of


         =
[1]).


         =
…


   =
      For example, if a receiver signals capabilit=
y for Level 1.2


   =
      with max-br equal to 1550, this indicates a =
maximum video


   =
      bitrate of 1550 kbits/sec for VCL HRD parame=
ters, a maximum


   =
      video bitrate of 1860 kbits/sec for NAL HRD =
parameters, and a


    =
;     CPB size of 4036458 bits (1550000 / 384000 *=
 1000 * 1000).


NEW: 
(note that the change here is purely editorial) 

      max-br: The value =
of max-br is an integer indicating the maximum


         =
video bitrate in units of 1000 bits per second for the VCL HRD


         =
parameters and in units of 1200 bits


         =
per second for the NAL HRD parameters.


         =
…


   =
      For example, if a receiver signals capabilit=
y for
Main profile Level 1.2


   =
      with max-br equal to 1550, this indicates a =
maximum video


   =
      bitrate of 1550 kbits/sec for VCL HRD parame=
ters, a maximum


   =
      video bitrate of 1860 kbits/sec for NAL HRD =
parameters, and a


    =
;     CPB size of 4036458 bits (1550000 / 384000 *=
 1000 * 1000).


&n=
bsp;


----------------------------=
--------End of suggested changes --------------------------------------


&n=
bsp;






From: avt-bounces@=
ietf.org [mailto:avt-bounces@ietf.org]
On Behalf Of Ye-Kui Wang

Sent: Sunday, March 20, 2011 4:21 AM

To: payload@ietf.org; avt@ietf.org

Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload=
 drafts






 


Folks,


 


The three H.264/AVC related pay=
load formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-=
svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage.


 


The RFC-Editor has found the fo=
llowing problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the=
 max-dpb media parameter refers to the MaxDPB that was defined the first ve=
rsion of the H.264/AVC spec, but not
 any more in the latest version (the 2010 version). The parameter in the la=
test H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit o=
f the new parameter (i.e., macroblocks) is different from the original one =
(i.e. 1024 bytes).


 


The problem applies also to the=
 SVC payload format, the RCDO payload format, and H.241.<=
/p>

 


A solution has been found and a=
greed, involving rfc3984bis authors and some key people related to H.264/AV=
C (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko a=
nd Patrick Luthi). Furthermore, we have
 found that there are also a couple of places that need fixes due to simila=
r changes from the initial version of H.264/AVC to the latest version.=



 


Per Roni’s suggestion, I =
am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for rev=
iew by the Payload and AVTcore WGs. It seems that exactly the same changes =
are needed to draft-ietf-avt-rtp-h264-rcdo-08
 (co-authors of this draft may confirm), and similar but slightly different=
 changes are needed to draft-ietf-avt-rtp-svc-27.


 


Since the drafts are at the AUT=
H48 stage, please provide comments by Monday, March 21, if any. Many thanks=
!


 


BR, YK


 
--Boundary_(ID_hcR2NkBpOkdtxtm59hGaDw)-- From eckelcu@cisco.com Mon Mar 21 10:50:34 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E843A687B; Mon, 21 Mar 2011 10:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.276 X-Spam-Level: X-Spam-Status: No, score=-10.276 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] 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 ZeL6dLuPw2YQ; Mon, 21 Mar 2011 10:50:32 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D13FB28C0D8; Mon, 21 Mar 2011 10:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=13224; q=dns/txt; s=iport; t=1300729925; x=1301939525; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=5BtxtgH0NJfmCEECpQdYBkGQdLaPo8SVXzU/c+VVpMQ=; b=hszzpLgTDCVeQOp8JcOm8DkuNtDkdHPn/VMnZ0RoO8dRG7K4Y9Cd/WKA 01DFFtGhtrL8p/Ls8CE2dcuH5gfVku7qmu0y9MUCniJlit64uTYXMtMpW a3X2k+HHrMOT55LSfXiye0Rw15uIGQlLpQSfmAKG4T4fqoCUgo/UHaE5P I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4BAJcth02rRDoI/2dsb2JhbACXfY1Cd6YOnBaFYwSFM4sL X-IronPort-AV: E=Sophos;i="4.63,220,1299456000"; d="scan'208";a="349937835" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2011 17:51:45 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2LHpj0D016491; Mon, 21 Mar 2011 17:51:45 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Mar 2011 10:51:45 -0700 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 Date: Mon, 21 Mar 2011 10:51:43 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-Index: Acvm161AAF2A6AC0R/ODLEMZyh1IcgAwzyEAABVfHoA= References: From: "Charles Eckel (eckelcu)" To: "Ye-Kui Wang" , , X-OriginalArrivalTime: 21 Mar 2011 17:51:45.0267 (UTC) FILETIME=[A4C40C30:01CBE7F0] Subject: Re: [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 17:50:34 -0000 Hi YK, Thank you for providing this clear description of the proposed changes. The changes look good to me. Cheers, Charles > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Monday, March 21, 2011 1:11 AM > To: payload@ietf.org; avt@ietf.org > Subject: Re: [payload] Some changes to rfc3984bis, SVC,and RCDO payload drafts >=20 > Further discussions with the same group of persons led to a decision to stay with the unscaled units > for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title > and H.241. With this, the changes needed are listed below (the originally suggested changes are > dropped from this email). This time I have highlighted the changes, and I have also described the > nature the changes below. Hope these may help understand better what have been changed, and can lead > to a quicker decision by the group, including WG chairs, and our AD. >=20 >=20 >=20 > BR, YK >=20 >=20 >=20 > ------------------------------------Start of suggested changes -------------------------------------- >=20 >=20 >=20 > Section 8.1: >=20 > OLD: >=20 > profile-level-id: > A base16 [7] (hexadecimal) representation of the following > three bytes in the sequence parameter set NAL unit is specified > in [1]: 1) profile_idc, 2) a byte herein referred to as > profile-iop, composed of the values of constraint_set0_flag, > constraint_set1_flag,constraint_set2_flag, > constraint_set3_flag, and reserved_zero_4bits in bit- > significance order, starting from the most-significant bit, and > 3) level_idc. Note that reserved_zero_4bits is required to be > equal to 0 in [1], but other values for it may be specified in > the future by ITU-T or ISO/IEC. >=20 > NEW: (note that the change here is purely editorial) >=20 > profile-level-id: >=20 > A base16 [7] (hexadecimal) representation of the following >=20 > three bytes in the sequence parameter set NAL unit is specified >=20 > in [1]: 1) profile_idc, 2) a byte herein referred to as >=20 > profile-iop, composed of the values of constraint_set0_flag, >=20 > constraint_set1_flag,constraint_set2_flag, >=20 > constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, >=20 > and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and >=20 > 3) level_idc. Note that reserved_zero_2bits is required to be >=20 > equal to 0 in [1], but other values for it may be specified in >=20 > the future by ITU-T or ISO/IEC. >=20 >=20 >=20 > OLD: >=20 > For example, in the table above, profile_idc equal to 58 > (Extended) with profile-iop equal to 11xx0000 indicates the > same sub-profile corresponding to profile_idc equal to 42 > (Baseline) with profile-iop equal to x1xx0000. Note that other > combinations of profile_idc and profile-iop (not listed in > Table 5) may represent a sub-profile equivalent to the common > subset of coding tools for more than one profile. Note also > that a decoder conforming to a certain profile may be able to > decode bitstreams conforming to other profiles. For example, a > decoder conforming to the High 4:4:4 profile, at a certain > level, must be able to decode bitstreams conforming to the > Constrained Baseline, Main, High, High 10, or High 4:2:2 > profile at the same or a lower level. >=20 > NEW: (note that the change here is purely editorial) >=20 > For example, in the table above, profile_idc equal to 58 >=20 > (Extended) with profile-iop equal to 11xx0000 indicates the >=20 > same sub-profile corresponding to profile_idc equal to 42 >=20 > (Baseline) with profile-iop equal to x1xx0000. Note that other >=20 > combinations of profile_idc and profile-iop (not listed in >=20 > Table 5) may represent a sub-profile equivalent to the common >=20 > subset of coding tools for more than one profile. Note also >=20 > that a decoder conforming to a certain profile may be able to >=20 > decode bitstreams conforming to other profiles. >=20 >=20 >=20 > OLD: >=20 > If the profile-level-id parameter is used for capability > exchange or session setup procedure, it indicates the subset of > coding tools, which is equal to the default sub-profile, that > the codec supports for both receiving and sending. >=20 > NEW: (note that the change here is purely editorial) >=20 > If the profile-level-id parameter is used for capability >=20 > exchange or session setup, it indicates the subset of >=20 > coding tools, which is equal to the default sub-profile, that >=20 > the codec supports for both receiving and sending. >=20 >=20 >=20 > OLD: >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters (see A.3.1, item i of [1]) and in units of 1200 bits >=20 > for the NAL HRD parameters (see A.3.1, item j of [1]). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters and in units of 1200 bits >=20 > for the NAL HRD parameters. >=20 >=20 >=20 > OLD: >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 1024 bytes. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDPB value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * >=20 > 256 * ChromaFormatFactor ), 16) >=20 >=20 >=20 > PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are >=20 > defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDPB given in Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 > NEW: (When this change can be considered as editorial can be discussed, but the nature of this change > as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to > unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note > that compared to RFC 3984, the bits on the wire do not change.) >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 8/3 macroblocks. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDpbMbs value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) >=20 >=20 >=20 > Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in >=20 > Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 >=20 >=20 > OLD: >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters (see A.3.1, item i of [1]) and in units of 1200 bits > per second for the NAL HRD parameters (see A.3.1, item j of > [1]). > ... >=20 > For example, if a receiver signals capability for Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters and in units of 1200 bits > per second for the NAL HRD parameters. > ... >=20 > For example, if a receiver signals capability for Main profile Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 >=20 >=20 > ------------------------------------End of suggested changes -------------------------------------- >=20 >=20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Sunday, March 20, 2011 4:21 AM > To: payload@ietf.org; avt@ietf.org > Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts >=20 >=20 >=20 > Folks, >=20 >=20 >=20 > The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt- > rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. >=20 >=20 >=20 > The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of > the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC > spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC > version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is > different from the original one (i.e. 1024 bytes). >=20 >=20 >=20 > The problem applies also to the SVC payload format, the RCDO payload format, and H.241. >=20 >=20 >=20 > A solution has been found and agreed, involving rfc3984bis authors and some key people related to > H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). > Furthermore, we have found that there are also a couple of places that need fixes due to similar > changes from the initial version of H.264/AVC to the latest version. >=20 >=20 >=20 > Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for > review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft- > ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different > changes are needed to draft-ietf-avt-rtp-svc-27. >=20 >=20 >=20 > Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many > thanks! >=20 >=20 >=20 > BR, YK >=20 >=20 From Even.roni@huawei.com Mon Mar 21 14:58:05 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC9728C1A3; Mon, 21 Mar 2011 14:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.863 X-Spam-Level: X-Spam-Status: No, score=-99.863 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 dV+1R3C2FoFn; Mon, 21 Mar 2011 14:57:58 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 7CDE33A68E4; Mon, 21 Mar 2011 14:57:58 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIF00FV4H2WSK@szxga05-in.huawei.com>; Tue, 22 Mar 2011 05:59:21 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIF00MEQH2WNG@szxga05-in.huawei.com>; Tue, 22 Mar 2011 05:59:20 +0800 (CST) Received: from windows8d787f9 (cust.static.109-164-246-172.swisscomdata.ch [109.164.246.172]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIF00EQ7H2RF7@szxml11-in.huawei.com>; Tue, 22 Mar 2011 05:59:20 +0800 (CST) Date: Mon, 21 Mar 2011 23:58:58 +0200 From: Roni Even To: avt@ietf.org Message-id: <000001cbe813$31ed2980$95c77c80$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_GiuN6RPIJ8UjGZWShI216A)" Content-language: en-us Thread-index: Acvn3nQPbW3aKf6aSP68ZQys8bVHXw== Cc: payload@ietf.org, xrblock@ietf.org Subject: [payload] Latest agenda for AVTcore at IETF80 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 21:58:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_GiuN6RPIJ8UjGZWShI216A) Content-type: multipart/alternative; boundary="Boundary_(ID_l+c8aYCd9eVq+QUJDX0f2w)" --Boundary_(ID_l+c8aYCd9eVq+QUJDX0f2w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Attached is the agenda for the AVTcore session. Hopefully the final one See you in Prague Roni Even --Boundary_(ID_l+c8aYCd9eVq+QUJDX0f2w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

Attached is the agenda for the AVTcore session. Hopefully the final one

See you in Prague

Roni Even

--Boundary_(ID_l+c8aYCd9eVq+QUJDX0f2w)-- --Boundary_(ID_GiuN6RPIJ8UjGZWShI216A) Content-type: text/html; name=a1103.html Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1103.html Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Audio/Video Transport Core Maintenance (AVTCore) Working Group Agenda

Chairs: Magnus Westerlund , Roni Even

Monday, 28 March 2011 at 13:00-15:00 (Congress Hall I)

13:00 AVTCore Introduction and Status UpdateChairs
13:15 Payload Introduction and Status UpdatePayload Chairs
13:30 XRBlock Introduction and Status UpdateXRblock Chairs
13:45 Explicit Congestion Notification for RTP over UDPPerkins
draft-ietf-avtcore-ecn-for-rtp-01
13:55 RTCP Extension for Feedback Suppression IndicationQin Wu
draft-ietf-avtcore-feedback-supression-rtp-00
14:05 RTCP Feedbak Suppression and RetransmissionTom VanCaenegem
draft-vancaenegem-avtcore-fb-supp-and-retransm-00
14:10 RTCP for inter-destination media synchronizationRay van Brandenburg
draft-brandenburg-avtcore-rtcp-for-idms-00
14:25 Monitoring Architectures for RTPQin Wu
draft-hunt-avtcore-monarch-01
14:40 Multipath RTP Varun Singh
draft-singh-avtcore-mprtp-01
14:50 End
--Boundary_(ID_GiuN6RPIJ8UjGZWShI216A) Content-type: text/plain; name=a1103.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=a1103.txt Audio/Video Transport Core Maintenance (AVTCore) Working Group =============================================================== CHAIRS: Magnus Westerlund Roni Even AGENDA Monday, 28 March 2011 at 13:00-15:00 (Congress Hall I) ------------------------------------------------------ 13:00 AVTCore Introduction and Status Update (Chairs, 15) 13:15 Payload Introduction and Status Update (Payload Chairs, 15) 13:30 XRBlock Introduction and Status Update (XRblock Chairs, 15) 13:45 Explicit Congestion Notification for RTP over UDP (Perkins, 10) draft-ietf-avtcore-ecn-for-rtp-01 13:55 RTCP Extension for Feedback Suppression Indication (Qin Wu, 10) draft-ietf-avtcore-feedback-supression-rtp-00 14:05 RTCP Feedbak Suppression and Retransmission (Tom VanCaenegem, 5) draft-vancaenegem-avtcore-fb-supp-and-retransm-00 14:10 RTCP for inter-destination media synchronization(Ray van Brandenburg , 15) draft-brandenburg-avtcore-rtcp-for-idms-00 14:25 Monitoring Architectures for RTP (Qin Wu, 15) draft-hunt-avtcore-monarch-01 14:40 Multipath RTP (Varun Singh, 10) draft-singh-avtcore-mprtp-01 14:50 End --Boundary_(ID_GiuN6RPIJ8UjGZWShI216A)-- From aallison@nab.org Mon Mar 21 13:45:57 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13EAF3A688F; Mon, 21 Mar 2011 13:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 mqBIz01PwD0A; Mon, 21 Mar 2011 13:45:49 -0700 (PDT) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by core3.amsl.com (Postfix) with ESMTP id 7BE643A6889; Mon, 21 Mar 2011 13:45:48 -0700 (PDT) Received: from unknown [208.97.234.91] (EHLO NABSREX027324.NAB.ORG) by p01c12o149.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 859b78d4.0.063.00-370.98.p01c12o149.mxlogic.net (envelope-from ); Mon, 21 Mar 2011 14:47:21 -0600 (MDT) X-MXL-Hash: 4d87b9592aac0919-20935f5bfeb238f839e64c397ccd13bcd67fd7de X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Mar 2011 16:47:20 -0400 Message-ID: <71C9EC0544D1F64D8B7D91EDCC62202006890479@NABSREX027324.NAB.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-Index: Acvm161AAF2A6AC0R/ODLEMZyh1IcgAwzyEAABVfHoAABchBIA== References: From: "Allison, Art" To: , X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [208.97.234.91] X-AnalysisOut: [v=1.0 c=1 a=DzHdTxL-66EA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-] X-AnalysisOut: [IA:10 a=tFGTPFZixTZ3yCXJchW01Q==:17 a=g0FpLpFZAAAA:8 a=48v] X-AnalysisOut: [gC7mUAAAA:8 a=3DFX1qKQIBNiGt9bwzEA:9 a=crRPvF3YIfjp4rOSsNA] X-AnalysisOut: [A:7 a=J0UfUdaXDh-KRANSfXOz36xHNnwA:4 a=wPNLvfGTeEIA:10 a=8] X-AnalysisOut: [SgyfJxrfqYA:10 a=-9UqKSle32gA:10 a=Qd0007q6B0YA:10 a=lZB81] X-AnalysisOut: [5dzVvQA:10 a=bnotN7MkczWK5nCo:21 a=ubWaTVfSfK86nHZf:21] X-Mailman-Approved-At: Mon, 21 Mar 2011 15:02:53 -0700 Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 20:45:57 -0000 It has been by experience that discovery of a significant technical = issue that is 'patched' in a draft standard in a hurry to get it = published is always risky and often results in an internal = inconsistency. Seems to me that is a few weeks delay for the formulating body to review = is prudent - even if such change can be done.=20 Just reading for consistency, as I am no expert in the codec; I see the = 1000 and 1200 values expressed as pure multipliers and bits per second? = Is that a coincidence, error or a magic number effect? And the High = Profile factor of 1.25 (to these values) that is in the AVC standard = seems to be relevant, but is not being discussed. Is that covered = elsewhere in a clear fashion and independent? I think this should be sent back for correction...and thanks go to the = sharp eye who caught the discrepancy. Art Art Allison Senior Director Advanced Engineering, Science and Technology National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone=A0 202 429 5418=20 Fax=A0 202 775 4981 www.nab.org Advocacy =A0Education=A0 Innovation -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Charles Eckel (eckelcu) Sent: Monday, March 21, 2011 1:52 PM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC,and = RCDO payload drafts Hi YK, Thank you for providing this clear description of the proposed changes. The changes look good to me. Cheers, Charles > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Monday, March 21, 2011 1:11 AM > To: payload@ietf.org; avt@ietf.org > Subject: Re: [payload] Some changes to rfc3984bis, SVC,and RCDO payload drafts >=20 > Further discussions with the same group of persons led to a decision to stay with the unscaled units > for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title > and H.241. With this, the changes needed are listed below (the originally suggested changes are > dropped from this email). This time I have highlighted the changes, and I have also described the > nature the changes below. Hope these may help understand better what have been changed, and can lead > to a quicker decision by the group, including WG chairs, and our AD. >=20 >=20 >=20 > BR, YK >=20 >=20 >=20 > ------------------------------------Start of suggested changes -------------------------------------- >=20 >=20 >=20 > Section 8.1: >=20 > OLD: >=20 > profile-level-id: > A base16 [7] (hexadecimal) representation of the following > three bytes in the sequence parameter set NAL unit is specified > in [1]: 1) profile_idc, 2) a byte herein referred to as > profile-iop, composed of the values of constraint_set0_flag, > constraint_set1_flag,constraint_set2_flag, > constraint_set3_flag, and reserved_zero_4bits in bit- > significance order, starting from the most-significant bit, and > 3) level_idc. Note that reserved_zero_4bits is required to be > equal to 0 in [1], but other values for it may be specified in > the future by ITU-T or ISO/IEC. >=20 > NEW: (note that the change here is purely editorial) >=20 > profile-level-id: >=20 > A base16 [7] (hexadecimal) representation of the following >=20 > three bytes in the sequence parameter set NAL unit is specified >=20 > in [1]: 1) profile_idc, 2) a byte herein referred to as >=20 > profile-iop, composed of the values of constraint_set0_flag, >=20 > constraint_set1_flag,constraint_set2_flag, >=20 > constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, >=20 > and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and >=20 > 3) level_idc. Note that reserved_zero_2bits is required to be >=20 > equal to 0 in [1], but other values for it may be specified in >=20 > the future by ITU-T or ISO/IEC. >=20 >=20 >=20 > OLD: >=20 > For example, in the table above, profile_idc equal to 58 > (Extended) with profile-iop equal to 11xx0000 indicates the > same sub-profile corresponding to profile_idc equal to 42 > (Baseline) with profile-iop equal to x1xx0000. Note that other > combinations of profile_idc and profile-iop (not listed in > Table 5) may represent a sub-profile equivalent to the common > subset of coding tools for more than one profile. Note also > that a decoder conforming to a certain profile may be able to > decode bitstreams conforming to other profiles. For example, a > decoder conforming to the High 4:4:4 profile, at a certain > level, must be able to decode bitstreams conforming to the > Constrained Baseline, Main, High, High 10, or High 4:2:2 > profile at the same or a lower level. >=20 > NEW: (note that the change here is purely editorial) >=20 > For example, in the table above, profile_idc equal to 58 >=20 > (Extended) with profile-iop equal to 11xx0000 indicates the >=20 > same sub-profile corresponding to profile_idc equal to 42 >=20 > (Baseline) with profile-iop equal to x1xx0000. Note that other >=20 > combinations of profile_idc and profile-iop (not listed in >=20 > Table 5) may represent a sub-profile equivalent to the common >=20 > subset of coding tools for more than one profile. Note also >=20 > that a decoder conforming to a certain profile may be able to >=20 > decode bitstreams conforming to other profiles. >=20 >=20 >=20 > OLD: >=20 > If the profile-level-id parameter is used for capability > exchange or session setup procedure, it indicates the subset of > coding tools, which is equal to the default sub-profile, that > the codec supports for both receiving and sending. >=20 > NEW: (note that the change here is purely editorial) >=20 > If the profile-level-id parameter is used for capability >=20 > exchange or session setup, it indicates the subset of >=20 > coding tools, which is equal to the default sub-profile, that >=20 > the codec supports for both receiving and sending. >=20 >=20 >=20 > OLD: >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters (see A.3.1, item i of [1]) and in units of 1200 bits >=20 > for the NAL HRD parameters (see A.3.1, item j of [1]). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters and in units of 1200 bits >=20 > for the NAL HRD parameters. >=20 >=20 >=20 > OLD: >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 1024 bytes. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDPB value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * >=20 > 256 * ChromaFormatFactor ), 16) >=20 >=20 >=20 > PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are >=20 > defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDPB given in Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 > NEW: (When this change can be considered as editorial can be discussed, but the nature of this change > as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to > unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note > that compared to RFC 3984, the bits on the wire do not change.) >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 8/3 macroblocks. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDpbMbs value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) >=20 >=20 >=20 > Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in >=20 > Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 >=20 >=20 > OLD: >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters (see A.3.1, item i of [1]) and in units of 1200 bits > per second for the NAL HRD parameters (see A.3.1, item j of > [1]). > ... >=20 > For example, if a receiver signals capability for Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters and in units of 1200 bits > per second for the NAL HRD parameters. > ... >=20 > For example, if a receiver signals capability for Main profile Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 >=20 >=20 > ------------------------------------End of suggested changes -------------------------------------- >=20 >=20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Sunday, March 20, 2011 4:21 AM > To: payload@ietf.org; avt@ietf.org > Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts >=20 >=20 >=20 > Folks, >=20 >=20 >=20 > The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt- > rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. >=20 >=20 >=20 > The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of > the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC > spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC > version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is > different from the original one (i.e. 1024 bytes). >=20 >=20 >=20 > The problem applies also to the SVC payload format, the RCDO payload format, and H.241. >=20 >=20 >=20 > A solution has been found and agreed, involving rfc3984bis authors and some key people related to > H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). > Furthermore, we have found that there are also a couple of places that need fixes due to similar > changes from the initial version of H.264/AVC to the latest version. >=20 >=20 >=20 > Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for > review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft- > ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different > changes are needed to draft-ietf-avt-rtp-svc-27. >=20 >=20 >=20 > Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many > thanks! >=20 >=20 >=20 > BR, YK >=20 >=20 _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From yekui.wang@huawei.com Wed Mar 23 01:52:48 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7CD53A67A8; Wed, 23 Mar 2011 01:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 rE032Xa5PXto; Wed, 23 Mar 2011 01:52:46 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id A1E223A679C; Wed, 23 Mar 2011 01:52:46 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LII0095W62J0Q@usaga02-in.huawei.com>; Wed, 23 Mar 2011 01:54:20 -0700 (PDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LII00DGE62JQL@usaga02-in.huawei.com>; Wed, 23 Mar 2011 01:54:19 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Mar 2011 01:54:18 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.47]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 23 Mar 2011 01:54:18 -0700 Date: Wed, 23 Mar 2011 08:54:17 +0000 From: Ye-Kui Wang In-reply-to: <71C9EC0544D1F64D8B7D91EDCC62202006890479@NABSREX027324.NAB.ORG> X-Originating-IP: [10.47.86.192] To: "Allison, Art" , "payload@ietf.org" , "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-index: AQHL6TfkNG8bu5QUBkWtpBAtPXzvbg== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <71C9EC0544D1F64D8B7D91EDCC62202006890479@NABSREX027324.NAB.ORG> Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 08:52:48 -0000 The units of the values of 1000 and 1200 are clearly specified. Where is no= t clear, could you clarify?=20 What is "that" in "Is that a coincidence, error or a magic number effect?"? If you read carefully the previous two emails on this subject I sent out, y= ou would have noticed that the factor you mentioned, which is not only for = High profile, but for many other profiles, and the factor can be different = for different profiles, has been addressed. Please let us know if you found= any place that is not well addressed. Finally, what is "this" in "I think this should be sent back for correction= ..."? I guess you meant for the entire draft. But if you don't point out th= e place that needs to be corrected, what we can do? BR, YK -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Allis= on, Art Sent: Monday, March 21, 2011 4:47 PM To: payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO = payload drafts It has been by experience that discovery of a significant technical issue t= hat is 'patched' in a draft standard in a hurry to get it published is alwa= ys risky and often results in an internal inconsistency. Seems to me that is a few weeks delay for the formulating body to review is= prudent - even if such change can be done.=20 Just reading for consistency, as I am no expert in the codec; I see the 100= 0 and 1200 values expressed as pure multipliers and bits per second? Is tha= t a coincidence, error or a magic number effect? And the High Profile facto= r of 1.25 (to these values) that is in the AVC standard seems to be relevan= t, but is not being discussed. Is that covered elsewhere in a clear fashion= and independent? I think this should be sent back for correction...and thanks go to the shar= p eye who caught the discrepancy. Art Art Allison Senior Director Advanced Engineering, Science and Technology National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone=A0 202 429 5418=20 Fax=A0 202 775 4981 www.nab.org Advocacy =A0Education=A0 Innovation -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Charl= es Eckel (eckelcu) Sent: Monday, March 21, 2011 1:52 PM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC,and RCDO p= ayload drafts Hi YK, Thank you for providing this clear description of the proposed changes. The changes look good to me. Cheers, Charles > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Monday, March 21, 2011 1:11 AM > To: payload@ietf.org; avt@ietf.org > Subject: Re: [payload] Some changes to rfc3984bis, SVC,and RCDO payload drafts >=20 > Further discussions with the same group of persons led to a decision to stay with the unscaled units > for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title > and H.241. With this, the changes needed are listed below (the originally suggested changes are > dropped from this email). This time I have highlighted the changes, and I have also described the > nature the changes below. Hope these may help understand better what have been changed, and can lead > to a quicker decision by the group, including WG chairs, and our AD. >=20 >=20 >=20 > BR, YK >=20 >=20 >=20 > ------------------------------------Start of suggested changes -------------------------------------- >=20 >=20 >=20 > Section 8.1: >=20 > OLD: >=20 > profile-level-id: > A base16 [7] (hexadecimal) representation of the following > three bytes in the sequence parameter set NAL unit is specified > in [1]: 1) profile_idc, 2) a byte herein referred to as > profile-iop, composed of the values of constraint_set0_flag, > constraint_set1_flag,constraint_set2_flag, > constraint_set3_flag, and reserved_zero_4bits in bit- > significance order, starting from the most-significant bit, and > 3) level_idc. Note that reserved_zero_4bits is required to be > equal to 0 in [1], but other values for it may be specified in > the future by ITU-T or ISO/IEC. >=20 > NEW: (note that the change here is purely editorial) >=20 > profile-level-id: >=20 > A base16 [7] (hexadecimal) representation of the following >=20 > three bytes in the sequence parameter set NAL unit is specified >=20 > in [1]: 1) profile_idc, 2) a byte herein referred to as >=20 > profile-iop, composed of the values of constraint_set0_flag, >=20 > constraint_set1_flag,constraint_set2_flag, >=20 > constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, >=20 > and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and >=20 > 3) level_idc. Note that reserved_zero_2bits is required to be >=20 > equal to 0 in [1], but other values for it may be specified in >=20 > the future by ITU-T or ISO/IEC. >=20 >=20 >=20 > OLD: >=20 > For example, in the table above, profile_idc equal to 58 > (Extended) with profile-iop equal to 11xx0000 indicates the > same sub-profile corresponding to profile_idc equal to 42 > (Baseline) with profile-iop equal to x1xx0000. Note that other > combinations of profile_idc and profile-iop (not listed in > Table 5) may represent a sub-profile equivalent to the common > subset of coding tools for more than one profile. Note also > that a decoder conforming to a certain profile may be able to > decode bitstreams conforming to other profiles. For example, a > decoder conforming to the High 4:4:4 profile, at a certain > level, must be able to decode bitstreams conforming to the > Constrained Baseline, Main, High, High 10, or High 4:2:2 > profile at the same or a lower level. >=20 > NEW: (note that the change here is purely editorial) >=20 > For example, in the table above, profile_idc equal to 58 >=20 > (Extended) with profile-iop equal to 11xx0000 indicates the >=20 > same sub-profile corresponding to profile_idc equal to 42 >=20 > (Baseline) with profile-iop equal to x1xx0000. Note that other >=20 > combinations of profile_idc and profile-iop (not listed in >=20 > Table 5) may represent a sub-profile equivalent to the common >=20 > subset of coding tools for more than one profile. Note also >=20 > that a decoder conforming to a certain profile may be able to >=20 > decode bitstreams conforming to other profiles. >=20 >=20 >=20 > OLD: >=20 > If the profile-level-id parameter is used for capability > exchange or session setup procedure, it indicates the subset of > coding tools, which is equal to the default sub-profile, that > the codec supports for both receiving and sending. >=20 > NEW: (note that the change here is purely editorial) >=20 > If the profile-level-id parameter is used for capability >=20 > exchange or session setup, it indicates the subset of >=20 > coding tools, which is equal to the default sub-profile, that >=20 > the codec supports for both receiving and sending. >=20 >=20 >=20 > OLD: >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters (see A.3.1, item i of [1]) and in units of 1200 bits >=20 > for the NAL HRD parameters (see A.3.1, item j of [1]). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters and in units of 1200 bits >=20 > for the NAL HRD parameters. >=20 >=20 >=20 > OLD: >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 1024 bytes. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDPB value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * >=20 > 256 * ChromaFormatFactor ), 16) >=20 >=20 >=20 > PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are >=20 > defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDPB given in Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 > NEW: (When this change can be considered as editorial can be discussed, but the nature of this change > as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to > unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note > that compared to RFC 3984, the bits on the wire do not change.) >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 8/3 macroblocks. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDpbMbs value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) >=20 >=20 >=20 > Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in >=20 > Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 >=20 >=20 > OLD: >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters (see A.3.1, item i of [1]) and in units of 1200 bits > per second for the NAL HRD parameters (see A.3.1, item j of > [1]). > ... >=20 > For example, if a receiver signals capability for Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters and in units of 1200 bits > per second for the NAL HRD parameters. > ... >=20 > For example, if a receiver signals capability for Main profile Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 >=20 >=20 > ------------------------------------End of suggested changes -------------------------------------- >=20 >=20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Sunday, March 20, 2011 4:21 AM > To: payload@ietf.org; avt@ietf.org > Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts >=20 >=20 >=20 > Folks, >=20 >=20 >=20 > The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt- > rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. >=20 >=20 >=20 > The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of > the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC > spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC > version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is > different from the original one (i.e. 1024 bytes). >=20 >=20 >=20 > The problem applies also to the SVC payload format, the RCDO payload format, and H.241. >=20 >=20 >=20 > A solution has been found and agreed, involving rfc3984bis authors and some key people related to > H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). > Furthermore, we have found that there are also a couple of places that need fixes due to similar > changes from the initial version of H.264/AVC to the latest version. >=20 >=20 >=20 > Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for > review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft- > ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different > changes are needed to draft-ietf-avt-rtp-svc-27. >=20 >=20 >=20 > Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many > thanks! >=20 >=20 >=20 > BR, YK >=20 >=20 _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From harald@alvestrand.no Wed Mar 23 02:39:25 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB28E3A67E5 for ; Wed, 23 Mar 2011 02:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 vNl0pN0ib8n4 for ; Wed, 23 Mar 2011 02:39:25 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id B32BE3A67D8 for ; Wed, 23 Mar 2011 02:39:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DB0B239E0FA; Wed, 23 Mar 2011 10:40:19 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj0onnPWPjrx; Wed, 23 Mar 2011 10:40:19 +0100 (CET) Received: from [172.16.41.41] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id E9F7B39E074; Wed, 23 Mar 2011 10:40:18 +0100 (CET) Message-ID: <4D89C026.7090104@alvestrand.no> Date: Wed, 23 Mar 2011 10:40:54 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Roni Even References: <000001cbe813$31ed2980$95c77c80$%roni@huawei.com> In-Reply-To: <000001cbe813$31ed2980$95c77c80$%roni@huawei.com> Content-Type: multipart/alternative; boundary="------------020406010108020507050405" Cc: payload@ietf.org Subject: Re: [payload] Latest agenda for AVTcore at IETF80 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 09:39:26 -0000 This is a multi-part message in MIME format. --------------020406010108020507050405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/21/11 22:58, Roni Even wrote: > > Hi, > > Attached is the agenda for the AVTcore session. Hopefully the final one > > See you in Prague > Note - Roni has stated that the status of draft-westin-payload-vp8-02 will be addressed in the payload status update agenda item. I've ensured that we have people present to answer any technical questions that people want to raise, but given the relative calm on the topic on the list, I am not surprised if there are none. If there are none, I assume that we can start the last calls after Prague. Harald --------------020406010108020507050405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/21/11 22:58, Roni Even wrote:

Hi,

Attached is the agenda for the AVTcore session. Hopefully the final one

See you in Prague

Note - Roni has stated that the status of draft-westin-payload-vp8-02 will be addressed in the payload status update agenda item.

I've ensured that we have people present to answer any technical questions that people want to raise, but given the relative calm on the topic on the list, I am not surprised if there are none.

If there are none, I assume that we can start the last calls after Prague.

                  Harald

--------------020406010108020507050405-- From stewe@stewe.org Wed Mar 23 02:52:57 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3903A67D8 for ; Wed, 23 Mar 2011 02:52:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 NH2lCYobYUzw for ; Wed, 23 Mar 2011 02:52:56 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 44A5C3A67D4 for ; Wed, 23 Mar 2011 02:52:56 -0700 (PDT) Received: from [156.106.233.102] (unverified [156.106.233.102]) by stewe.org (SurgeMail 3.9e) with ESMTP id 1003-1743317 for multiple; Wed, 23 Mar 2011 10:54:29 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Wed, 23 Mar 2011 10:54:22 +0100 From: Stephan Wenger To: Harald Alvestrand , Roni Even Message-ID: Thread-Topic: [payload] Latest agenda for AVTcore at IETF80 In-Reply-To: <4D89C026.7090104@alvestrand.no> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3383722469_147234" X-Originating-IP: 156.106.233.102 X-Authenticated-User: stewe@stewe.org Cc: payload@ietf.org Subject: Re: [payload] Latest agenda for AVTcore at IETF80 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 09:52:57 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3383722469_147234 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Harald, A good number of the video payload experts are rather busy with a JCTVC and MPEG meeting currently ongoing in Geneva. I would not be surprised that there were comments just before the IETF session, not because of obstruction, but because people were swamped with the 12 hour sessions over 8 straight days (including the weekend) over the last week and a half. Stephan From: Harald Alvestrand Date: Wed, 23 Mar 2011 10:40:54 +0100 To: Roni Even Cc: Subject: Re: [payload] Latest agenda for AVTcore at IETF80 On 03/21/11 22:58, Roni Even wrote: > > > > Hi, > > Attached is the agenda for the AVTcore session. Hopefully the final one > > See you in Prague > > > Note - Roni has stated that the status of draft-westin-payload-vp8-02 will be addressed in the payload status update agenda item. I've ensured that we have people present to answer any technical questions that people want to raise, but given the relative calm on the topic on the list, I am not surprised if there are none. If there are none, I assume that we can start the last calls after Prague. Harald _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --B_3383722469_147234 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Harald,
A good num= ber of the video payload experts are rather busy with a JCTVC and MPEG meeti= ng currently ongoing in Geneva.  I would not be surprised that there we= re comments just before the IETF session, not because of obstruction, but be= cause people were swamped with the 12 hour sessions over 8 straight days (in= cluding the weekend) over the last week and a half.
Stephan
<= div>
From: Harald Alvestrand &l= t;harald@alvestrand.no>
Date: Wed, 23 Mar 2011 10:40:54 +0100
= To: Roni Even <Even.roni@huawei.com>
Cc: <payload@ietf.org= >
Subject: Re: [payload] Latest= agenda for AVTcore at IETF80

On 03/21/11 22:58, Roni Even wrote:

Hi,

Attached is the agenda for the AVTcore session. Hopefully the final one

See you in Prague

Note - Roni has stated that the status of draft-westin-payload-vp8-02 will be addressed in the payload status update agenda item.

I've ensured that we have people present to answer any technical questions that people want to raise, but given the relative calm on the topic on the list, I am not surprised if there are none.

If there are none, I assume that we can start the last calls after Prague.

            = ;      Harald

_______________________________________________ payload mailing list payload@ietf.org https://www.ietf.or= g/mailman/listinfo/payload --B_3383722469_147234-- From Even.roni@huawei.com Wed Mar 23 06:50:46 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84573A6914 for ; Wed, 23 Mar 2011 06:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.494 X-Spam-Level: X-Spam-Status: No, score=-104.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 pCXTyBkJ3qKO for ; Wed, 23 Mar 2011 06:50:45 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 712EF3A6839 for ; Wed, 23 Mar 2011 06:50:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LII00JYVJUN1L@szxga04-in.huawei.com> for payload@ietf.org; Wed, 23 Mar 2011 21:51:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LII005EUJUN1R@szxga04-in.huawei.com> for payload@ietf.org; Wed, 23 Mar 2011 21:51:59 +0800 (CST) Received: from windows8d787f9 ([156.106.246.49]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LII00J9IJUGUR@szxml12-in.huawei.com>; Wed, 23 Mar 2011 21:51:59 +0800 (CST) Date: Wed, 23 Mar 2011 15:51:33 +0200 From: Roni Even In-reply-to: <4D89C026.7090104@alvestrand.no> To: 'Harald Alvestrand' Message-id: <001901cbe961$6fcb11f0$4f6135d0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qQ5OIzFBUnvuuFUhyTqeow)" Content-language: en-us Thread-index: AcvpPndcc5N7cETTQjeX2DfHXrHphwAA4hIA References: <000001cbe813$31ed2980$95c77c80$%roni@huawei.com> <4D89C026.7090104@alvestrand.no> Cc: payload@ietf.org Subject: Re: [payload] Latest agenda for AVTcore at IETF80 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 13:50:47 -0000 This is a multi-part message in MIME format. --Boundary_(ID_qQ5OIzFBUnvuuFUhyTqeow) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Harald, We need first to adopt it as a WG document. After the adoption you will need to submit the document as a WG document and then we can go to WGLC. This will happen after the Prague meeting. Thanks Roni Even From: Harald Alvestrand [mailto:harald@alvestrand.no] Sent: Wednesday, March 23, 2011 11:41 AM To: Roni Even Cc: payload@ietf.org Subject: Re: [payload] Latest agenda for AVTcore at IETF80 On 03/21/11 22:58, Roni Even wrote: Hi, Attached is the agenda for the AVTcore session. Hopefully the final one See you in Prague Note - Roni has stated that the status of draft-westin-payload-vp8-02 will be addressed in the payload status update agenda item. I've ensured that we have people present to answer any technical questions that people want to raise, but given the relative calm on the topic on the list, I am not surprised if there are none. If there are none, I assume that we can start the last calls after Prague. Harald --Boundary_(ID_qQ5OIzFBUnvuuFUhyTqeow) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Harald,

We need first to adopt it as a WG document.   After the adoption you will need to submit the document as a WG document and then we can go to WGLC. This will happen after the Prague meeting.

Thanks

Roni Even

 

From: Harald Alvestrand [mailto:harald@alvestrand.no]
Sent: Wednesday, March 23, 2011 11:41 AM
To: Roni Even
Cc: payload@ietf.org
Subject: Re: [payload] Latest agenda for AVTcore at IETF80

 

On 03/21/11 22:58, Roni Even wrote:

Hi,

Attached is the agenda for the AVTcore session. Hopefully the final one

See you in Prague

Note - Roni has stated that the status of draft-westin-payload-vp8-02 will be addressed in the payload status update agenda item.

I've ensured that we have people present to answer any technical questions that people want to raise, but given the relative calm on the t opic on sed if there are none.

If there are none, I assume that we can start the last calls after Prague.

                  Harald

--Boundary_(ID_qQ5OIzFBUnvuuFUhyTqeow)-- From yekui.wang@huawei.com Wed Mar 23 07:54:29 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B983A685A; Wed, 23 Mar 2011 07:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 W4Qaqm1uvNst; Wed, 23 Mar 2011 07:54:27 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 5D9973A684B; Wed, 23 Mar 2011 07:54:27 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LII00E6ZMTC1A@usaga04-in.huawei.com>; Wed, 23 Mar 2011 09:56:00 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LII00LJ6MT053@usaga04-in.huawei.com>; Wed, 23 Mar 2011 09:56:00 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Mar 2011 07:55:52 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.47]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 23 Mar 2011 07:55:47 -0700 Date: Wed, 23 Mar 2011 14:55:46 +0000 From: Ye-Kui Wang In-reply-to: <71C9EC0544D1F64D8B7D91EDCC62202006890498@NABSREX027324.NAB.ORG> X-Originating-IP: [10.200.218.160] To: "Allison, Art" , "payload@ietf.org" , "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-index: AQHL6TfkNG8bu5QUBkWtpBAtPXzvbpQ6866QgAAMmMA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <71C9EC0544D1F64D8B7D91EDCC62202006890479@NABSREX027324.NAB.ORG> <71C9EC0544D1F64D8B7D91EDCC62202006890498@NABSREX027324.NAB.ORG> Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 14:54:29 -0000 The 1000 and 1200 are for Video Coding Layer (VCL) and Network Abstraction = Layer (NAL), respectively, and the numbers (magic or not) were from the H.2= 64/AVC spec. The unit of bits is for buffer size, and the unit of bits per = second is for bitrate (which are clear from the text), they have to be diff= erent (which you call inconsistency). Many times you have to be inconsisten= t to be correct :-) The changes are now sent to the (two) lists for review, and we authors welc= ome any comments, and particularly those that point out concrete further ch= anges that are needed. BR, YK -----Original Message----- From: Allison, Art [mailto:AAllison@nab.org]=20 Sent: Wednesday, March 23, 2011 10:37 AM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO = payload drafts I admit significant ignorance of the technical details. =20 My main point, based on decades of standards development experience, was th= at last minute changes such as these often result in failure to fix the iss= ue precisely and that the due process group should be given time to assure = the correct fix has been made. Rushing can work, but often has a bad outco= me.=20 As to specifics; I saw that the values of 1000 and 1200 as the correct unit= sizes for NAL stream overhead (in some cases). In one place these are ass= erted to be bits (no rate units) as a multiplier and in another place these= are described as bits-per-second. These are clearly different usages. Perh= aps both usages are correct - I do not know - but it appeared to be inconsi= stent. (And this type of inconsistency is exactly the kind of thing that I= have seen happen when last minute patches are made to a standard.) By magic number, I meant was it correct that these values have two differen= t uses, perhaps due to their fundamental nature. I do not assert anything is wrong, I suggest that unless there is a vital n= eed to push this out fast, that the draft be referred back to the drafting = group. Maybe all those folks have had time to carefully consider and respon= d before the deadline...and this is specious. I believe that you can make better decisions when more i= nformation is provided. I commented to so assist. =20 Art Allison Senior Director Advanced Engineering, Science and Technology National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone=A0 202 429 5418=20 Fax=A0 202 775 4981 www.nab.org Advocacy =A0Education=A0 Innovation -----Original Message----- From: Ye-Kui Wang [mailto:yekui.wang@huawei.com]=20 Sent: Wednesday, March 23, 2011 4:54 AM To: Allison, Art; payload@ietf.org; avt@ietf.org Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO = payload drafts The units of the values of 1000 and 1200 are clearly specified. Where is no= t clear, could you clarify?=20 What is "that" in "Is that a coincidence, error or a magic number effect?"? If you read carefully the previous two emails on this subject I sent out, y= ou would have noticed that the factor you mentioned, which is not only for = High profile, but for many other profiles, and the factor can be different = for different profiles, has been addressed. Please let us know if you found= any place that is not well addressed. Finally, what is "this" in "I think this should be sent back for correction= ..."? I guess you meant for the entire draft. But if you don't point out th= e place that needs to be corrected, what we can do? BR, YK -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Allis= on, Art Sent: Monday, March 21, 2011 4:47 PM To: payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO = payload drafts It has been by experience that discovery of a significant technical issue t= hat is 'patched' in a draft standard in a hurry to get it published is alwa= ys risky and often results in an internal inconsistency. Seems to me that is a few weeks delay for the formulating body to review is= prudent - even if such change can be done.=20 Just reading for consistency, as I am no expert in the codec; I see the 100= 0 and 1200 values expressed as pure multipliers and bits per second? Is tha= t a coincidence, error or a magic number effect? And the High Profile facto= r of 1.25 (to these values) that is in the AVC standard seems to be relevan= t, but is not being discussed. Is that covered elsewhere in a clear fashion= and independent? I think this should be sent back for correction...and thanks go to the shar= p eye who caught the discrepancy. Art Art Allison Senior Director Advanced Engineering, Science and Technology National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone=A0 202 429 5418=20 Fax=A0 202 775 4981 www.nab.org Advocacy =A0Education=A0 Innovation -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Charl= es Eckel (eckelcu) Sent: Monday, March 21, 2011 1:52 PM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC,and RCDO p= ayload drafts Hi YK, Thank you for providing this clear description of the proposed changes. The changes look good to me. Cheers, Charles > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Monday, March 21, 2011 1:11 AM > To: payload@ietf.org; avt@ietf.org > Subject: Re: [payload] Some changes to rfc3984bis, SVC,and RCDO payload drafts >=20 > Further discussions with the same group of persons led to a decision to stay with the unscaled units > for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title > and H.241. With this, the changes needed are listed below (the originally suggested changes are > dropped from this email). This time I have highlighted the changes, and I have also described the > nature the changes below. Hope these may help understand better what have been changed, and can lead > to a quicker decision by the group, including WG chairs, and our AD. >=20 >=20 >=20 > BR, YK >=20 >=20 >=20 > ------------------------------------Start of suggested changes -------------------------------------- >=20 >=20 >=20 > Section 8.1: >=20 > OLD: >=20 > profile-level-id: > A base16 [7] (hexadecimal) representation of the following > three bytes in the sequence parameter set NAL unit is specified > in [1]: 1) profile_idc, 2) a byte herein referred to as > profile-iop, composed of the values of constraint_set0_flag, > constraint_set1_flag,constraint_set2_flag, > constraint_set3_flag, and reserved_zero_4bits in bit- > significance order, starting from the most-significant bit, and > 3) level_idc. Note that reserved_zero_4bits is required to be > equal to 0 in [1], but other values for it may be specified in > the future by ITU-T or ISO/IEC. >=20 > NEW: (note that the change here is purely editorial) >=20 > profile-level-id: >=20 > A base16 [7] (hexadecimal) representation of the following >=20 > three bytes in the sequence parameter set NAL unit is specified >=20 > in [1]: 1) profile_idc, 2) a byte herein referred to as >=20 > profile-iop, composed of the values of constraint_set0_flag, >=20 > constraint_set1_flag,constraint_set2_flag, >=20 > constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, >=20 > and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and >=20 > 3) level_idc. Note that reserved_zero_2bits is required to be >=20 > equal to 0 in [1], but other values for it may be specified in >=20 > the future by ITU-T or ISO/IEC. >=20 >=20 >=20 > OLD: >=20 > For example, in the table above, profile_idc equal to 58 > (Extended) with profile-iop equal to 11xx0000 indicates the > same sub-profile corresponding to profile_idc equal to 42 > (Baseline) with profile-iop equal to x1xx0000. Note that other > combinations of profile_idc and profile-iop (not listed in > Table 5) may represent a sub-profile equivalent to the common > subset of coding tools for more than one profile. Note also > that a decoder conforming to a certain profile may be able to > decode bitstreams conforming to other profiles. For example, a > decoder conforming to the High 4:4:4 profile, at a certain > level, must be able to decode bitstreams conforming to the > Constrained Baseline, Main, High, High 10, or High 4:2:2 > profile at the same or a lower level. >=20 > NEW: (note that the change here is purely editorial) >=20 > For example, in the table above, profile_idc equal to 58 >=20 > (Extended) with profile-iop equal to 11xx0000 indicates the >=20 > same sub-profile corresponding to profile_idc equal to 42 >=20 > (Baseline) with profile-iop equal to x1xx0000. Note that other >=20 > combinations of profile_idc and profile-iop (not listed in >=20 > Table 5) may represent a sub-profile equivalent to the common >=20 > subset of coding tools for more than one profile. Note also >=20 > that a decoder conforming to a certain profile may be able to >=20 > decode bitstreams conforming to other profiles. >=20 >=20 >=20 > OLD: >=20 > If the profile-level-id parameter is used for capability > exchange or session setup procedure, it indicates the subset of > coding tools, which is equal to the default sub-profile, that > the codec supports for both receiving and sending. >=20 > NEW: (note that the change here is purely editorial) >=20 > If the profile-level-id parameter is used for capability >=20 > exchange or session setup, it indicates the subset of >=20 > coding tools, which is equal to the default sub-profile, that >=20 > the codec supports for both receiving and sending. >=20 >=20 >=20 > OLD: >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters (see A.3.1, item i of [1]) and in units of 1200 bits >=20 > for the NAL HRD parameters (see A.3.1, item j of [1]). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters and in units of 1200 bits >=20 > for the NAL HRD parameters. >=20 >=20 >=20 > OLD: >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 1024 bytes. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDPB value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * >=20 > 256 * ChromaFormatFactor ), 16) >=20 >=20 >=20 > PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are >=20 > defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDPB given in Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 > NEW: (When this change can be considered as editorial can be discussed, but the nature of this change > as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to > unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note > that compared to RFC 3984, the bits on the wire do not change.) >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 8/3 macroblocks. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDpbMbs value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) >=20 >=20 >=20 > Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in >=20 > Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 >=20 >=20 > OLD: >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters (see A.3.1, item i of [1]) and in units of 1200 bits > per second for the NAL HRD parameters (see A.3.1, item j of > [1]). > ... >=20 > For example, if a receiver signals capability for Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters and in units of 1200 bits > per second for the NAL HRD parameters. > ... >=20 > For example, if a receiver signals capability for Main profile Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 >=20 >=20 > ------------------------------------End of suggested changes -------------------------------------- >=20 >=20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Sunday, March 20, 2011 4:21 AM > To: payload@ietf.org; avt@ietf.org > Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts >=20 >=20 >=20 > Folks, >=20 >=20 >=20 > The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt- > rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. >=20 >=20 >=20 > The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of > the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC > spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC > version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is > different from the original one (i.e. 1024 bytes). >=20 >=20 >=20 > The problem applies also to the SVC payload format, the RCDO payload format, and H.241. >=20 >=20 >=20 > A solution has been found and agreed, involving rfc3984bis authors and some key people related to > H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). > Furthermore, we have found that there are also a couple of places that need fixes due to similar > changes from the initial version of H.264/AVC to the latest version. >=20 >=20 >=20 > Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for > review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft- > ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different > changes are needed to draft-ietf-avt-rtp-svc-27. >=20 >=20 >=20 > Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many > thanks! >=20 >=20 >=20 > BR, YK >=20 >=20 _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From harald@alvestrand.no Wed Mar 23 08:02:28 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965E73A685B for ; Wed, 23 Mar 2011 08:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 DXRgNwFNvTGJ for ; Wed, 23 Mar 2011 08:02:27 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 7C7203A6922 for ; Wed, 23 Mar 2011 08:02:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B2D1839E17B; Wed, 23 Mar 2011 16:03:22 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtM4pyXrDwMt; Wed, 23 Mar 2011 16:03:22 +0100 (CET) Received: from [192.168.1.16] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3D6E939E16B; Wed, 23 Mar 2011 16:03:22 +0100 (CET) Message-ID: <4D8A0BEB.70402@alvestrand.no> Date: Wed, 23 Mar 2011 16:04:11 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: Roni Even References: <000001cbe813$31ed2980$95c77c80$%roni@huawei.com> <4D89C026.7090104@alvestrand.no> <001901cbe961$6fcb11f0$4f6135d0$%roni@huawei.com> In-Reply-To: <001901cbe961$6fcb11f0$4f6135d0$%roni@huawei.com> Content-Type: multipart/alternative; boundary="------------020608080105030701090207" Cc: payload@ietf.org Subject: Re: [payload] Latest agenda for AVTcore at IETF80 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 15:02:28 -0000 This is a multi-part message in MIME format. --------------020608080105030701090207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/23/2011 02:51 PM, Roni Even wrote: > > Harald, > > We need first to adopt it as a WG document. After the adoption you > will need to submit the document as a WG document and then we can go > to WGLC. This will happen after the Prague meeting. > OK - can I assume that the chairs will invite anyone with objections to adoption as a WG document, and anyone with technical objections to the content, to speak up at the Monday meeting (where they've hopefully overcome their post-MPEG exhaustion)? I'm pushing this, because the sooner we know if there are issues with it, the sooner we can fix them. Harald --------------020608080105030701090207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/23/2011 02:51 PM, Roni Even wrote:

Harald,

We need first to adopt it as a WG document.   After the adoption you will need to submit the document as a WG document and then we can go to WGLC. This will happen after the Prague meeting.

OK - can I assume that the chairs will invite anyone with objections to adoption as a WG document, and anyone with technical objections to the content, to speak up at the Monday meeting (where they've hopefully overcome their post-MPEG exhaustion)?

I'm pushing this, because the sooner we know if there are issues with it, the sooner we can fix them.

                      Harald

--------------020608080105030701090207-- From Even.roni@huawei.com Wed Mar 23 11:18:23 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775E928C114 for ; Wed, 23 Mar 2011 11:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.179 X-Spam-Level: X-Spam-Status: No, score=-100.179 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 QpHJWl+GDCFe for ; Wed, 23 Mar 2011 11:18:22 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 7353328C0D6 for ; Wed, 23 Mar 2011 11:18:22 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LII009W4W8XR2@szxga05-in.huawei.com> for payload@ietf.org; Thu, 24 Mar 2011 02:19:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LII005TAW8X4V@szxga05-in.huawei.com> for payload@ietf.org; Thu, 24 Mar 2011 02:19:45 +0800 (CST) Received: from windows8d787f9 (cust.static.109-164-246-172.swisscomdata.ch [109.164.246.172]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LII00LYVW8Q2Z@szxml12-in.huawei.com>; Thu, 24 Mar 2011 02:19:45 +0800 (CST) Date: Wed, 23 Mar 2011 20:19:20 +0200 From: Roni Even In-reply-to: <4D8A0BEB.70402@alvestrand.no> To: 'Harald Alvestrand' Message-id: <000001cbe986$d8849c50$898dd4f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_OpCi06gF3tymk1fFnntrBw)" Content-language: en-us Thread-index: Acvpa7ZV7GnDU9/fTXG6LMQedyYohwAA9gfQ References: <000001cbe813$31ed2980$95c77c80$%roni@huawei.com> <4D89C026.7090104@alvestrand.no> <001901cbe961$6fcb11f0$4f6135d0$%roni@huawei.com> <4D8A0BEB.70402@alvestrand.no> Cc: payload@ietf.org Subject: Re: [payload] Latest agenda for AVTcore at IETF80 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 18:18:23 -0000 This is a multi-part message in MIME format. --Boundary_(ID_OpCi06gF3tymk1fFnntrBw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Harald, What we ask if people agree that the individual draft can be used as a starting point to address the milestone Roni From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Harald Alvestrand Sent: Wednesday, March 23, 2011 5:04 PM To: Roni Even Cc: payload@ietf.org Subject: Re: [payload] Latest agenda for AVTcore at IETF80 On 03/23/2011 02:51 PM, Roni Even wrote: Harald, We need first to adopt it as a WG document. After the adoption you will need to submit the document as a WG document and then we can go to WGLC. This will happen after the Prague meeting. OK - can I assume that the chairs will invite anyone with objections to adoption as a WG document, and anyone with technical objections to the content, to speak up at the Monday meeting (where they've hopefully overcome their post-MPEG exhaustion)? I'm pushing this, because the sooner we know if there are issues with it, the sooner we can fix them. Harald --Boundary_(ID_OpCi06gF3tymk1fFnntrBw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Harald,

What we ask if people agree that the individual draft can be used as a starting point to address the milestone

Roni

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Harald AlvestrandSen 3, 2011 5:04 PM
To: Roni Even
Cc: payload@ietf.org
Subject: Re: [payload] Latest agenda for AVTcore at IETF80

 

On 03/23/2011 02:51 PM, Roni Even wrote:

Harald,

We need first to adopt it as a WG document.   After the adoption you will need to submit the document as a WG document and then we can go to WGLC. This will happen after the Prague meeting.

OK - can I assume that the chairs will invite anyone with objections to adoption as a WG document, and anyone with technical objections to the content, to speak up at the Monday meeting (where they've hopefully overcome their post-MPEG exhau stion)?< because the sooner we know if there are issues with it, the sooner we can fix them.

                      Harald

--Boundary_(ID_OpCi06gF3tymk1fFnntrBw)-- From Even.roni@huawei.com Wed Mar 23 11:18:25 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E9E28C116; Wed, 23 Mar 2011 11:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.984 X-Spam-Level: X-Spam-Status: No, score=-99.984 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 FyS775tqhOii; Wed, 23 Mar 2011 11:18:23 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0075528C110; Wed, 23 Mar 2011 11:18:23 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LII002T8W93IP@szxga05-in.huawei.com>; Thu, 24 Mar 2011 02:19:51 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LII00IQ2W92R8@szxga05-in.huawei.com>; Thu, 24 Mar 2011 02:19:51 +0800 (CST) Received: from windows8d787f9 (cust.static.109-164-246-172.swisscomdata.ch [109.164.246.172]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LII00LYVW8Q2Z@szxml12-in.huawei.com>; Thu, 24 Mar 2011 02:19:50 +0800 (CST) Date: Wed, 23 Mar 2011 20:19:20 +0200 From: Roni Even In-reply-to: <71C9EC0544D1F64D8B7D91EDCC62202006890498@NABSREX027324.NAB.ORG> To: "'Allison, Art'" , 'Ye-Kui Wang' , payload@ietf.org, avt@ietf.org Message-id: <000501cbe986$db1902d0$914b0870$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=windows-1255 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AQHL6TfkNG8bu5QUBkWtpBAtPXzvbpQ6866QgAAOfWA= References: <71C9EC0544D1F64D8B7D91EDCC62202006890479@NABSREX027324.NAB.ORG> <71C9EC0544D1F64D8B7D91EDCC62202006890498@NABSREX027324.NAB.ORG> Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 18:18:25 -0000 Hi, The changes were done taking advantage of the fact that all relevant = experts were in Geneva to ITU-T SG16 meeting (both the H.264 guys and the signaling). After a couple of days of email exchange everybody met face = to face to iron up the issue. I was part of the email exchange and asked = them to post to the avtcore and payload mailing list. Since it has been = posted the only feedback on the list was about procedure and not technical.=20 My assumption is that we will not see any technical comments but will = wait till next week. As for the timeline- this changes are also relevant to H.241 which is = the H.323 signaling for H.323. The changes were incorporated there as well = and reviewed and will be approved this week since we are all now in the = ITU-T study group 16 meeting Regards Roni Even > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Wednesday, March 23, 2011 4:37 PM > To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org > Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and > RCDO payload drafts >=20 > I admit significant ignorance of the technical details. >=20 > My main point, based on decades of standards development experience, > was that last minute changes such as these often result in failure to > fix the issue precisely and that the due process group should be given > time to assure the correct fix has been made. Rushing can work, but > often has a bad outcome. >=20 > As to specifics; I saw that the values of 1000 and 1200 as the correct > unit sizes for NAL stream overhead (in some cases). In one place = these > are asserted to be bits (no rate units) as a multiplier and in another > place these are described as bits-per-second. These are clearly > different usages. Perhaps both usages are correct - I do not know - = but > it appeared to be inconsistent. (And this type of inconsistency is > exactly the kind of thing that I have seen happen when last minute > patches are made to a standard.) >=20 > By magic number, I meant was it correct that these values have two > different uses, perhaps due to their fundamental nature. >=20 > I do not assert anything is wrong, I suggest that unless there is a > vital need to push this out fast, that the draft be referred back to > the drafting group. Maybe all those folks have had time to carefully > consider and respond before the deadline...and this is specious. >=20 > I believe that you can make better decisions when > more information is provided. I commented to so assist. >=20 >=20 > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone=A0 202 429 5418 > Fax=A0 202 775 4981 > www.nab.org > Advocacy =A0Education=A0 Innovation >=20 >=20 > -----Original Message----- > From: Ye-Kui Wang [mailto:yekui.wang@huawei.com] > Sent: Wednesday, March 23, 2011 4:54 AM > To: Allison, Art; payload@ietf.org; avt@ietf.org > Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and > RCDO payload drafts >=20 > The units of the values of 1000 and 1200 are clearly specified. Where > is not clear, could you clarify? >=20 > What is "that" in "Is that a coincidence, error or a magic number > effect?"? >=20 > If you read carefully the previous two emails on this subject I sent > out, you would have noticed that the factor you mentioned, which is = not > only for High profile, but for many other profiles, and the factor can > be different for different profiles, has been addressed. Please let us > know if you found any place that is not well addressed. >=20 > Finally, what is "this" in "I think this should be sent back for > correction..."? I guess you meant for the entire draft. But if you > don't point out the place that needs to be corrected, what we can do? >=20 > BR, YK >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Allison, Art > Sent: Monday, March 21, 2011 4:47 PM > To: payload@ietf.org; avt@ietf.org > Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and > RCDO payload drafts >=20 > It has been by experience that discovery of a significant technical > issue that is 'patched' in a draft standard in a hurry to get it > published is always risky and often results in an internal > inconsistency. >=20 > Seems to me that is a few weeks delay for the formulating body to > review is prudent - even if such change can be done. >=20 > Just reading for consistency, as I am no expert in the codec; I see = the > 1000 and 1200 values expressed as pure multipliers and bits per = second? > Is that a coincidence, error or a magic number effect? And the High > Profile factor of 1.25 (to these values) that is in the AVC standard > seems to be relevant, but is not being discussed. Is that covered > elsewhere in a clear fashion and independent? >=20 > I think this should be sent back for correction...and thanks go to the > sharp eye who caught the discrepancy. >=20 > Art >=20 > Art Allison > Senior Director Advanced Engineering, Science and Technology > National Association of Broadcasters > 1771 N Street NW > Washington, DC 20036 > Phone=A0 202 429 5418 > Fax=A0 202 775 4981 > www.nab.org > Advocacy =A0Education=A0 Innovation >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Charles Eckel (eckelcu) > Sent: Monday, March 21, 2011 1:52 PM > To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org > Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC,and > RCDO payload drafts >=20 > Hi YK, >=20 > Thank you for providing this clear description of the proposed = changes. > The changes look good to me. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Ye-Kui Wang > > Sent: Monday, March 21, 2011 1:11 AM > > To: payload@ietf.org; avt@ietf.org > > Subject: Re: [payload] Some changes to rfc3984bis, SVC,and RCDO > payload drafts > > > > Further discussions with the same group of persons led to a decision > to stay with the unscaled units > > for max-br and max-cpb, thus fewer changes are needed to the three > payload formats listed in the title > > and H.241. With this, the changes needed are listed below (the > originally suggested changes are > > dropped from this email). This time I have highlighted the changes, > and I have also described the > > nature the changes below. Hope these may help understand better what > have been changed, and can lead > > to a quicker decision by the group, including WG chairs, and our AD. > > > > > > > > BR, YK > > > > > > > > ------------------------------------Start of suggested changes > -------------------------------------- > > > > > > > > Section 8.1: > > > > OLD: > > > > profile-level-id: > > A base16 [7] (hexadecimal) representation of the following > > three bytes in the sequence parameter set NAL unit is > specified > > in [1]: 1) profile_idc, 2) a byte herein referred to as > > profile-iop, composed of the values of = constraint_set0_flag, > > constraint_set1_flag,constraint_set2_flag, > > constraint_set3_flag, and reserved_zero_4bits in bit- > > significance order, starting from the most-significant bit, > and > > 3) level_idc. Note that reserved_zero_4bits is required to > be > > equal to 0 in [1], but other values for it may be specified > in > > the future by ITU-T or ISO/IEC. > > > > NEW: (note that the change here is purely editorial) > > > > profile-level-id: > > > > A base16 [7] (hexadecimal) representation of the following > > > > three bytes in the sequence parameter set NAL unit is > specified > > > > in [1]: 1) profile_idc, 2) a byte herein referred to as > > > > profile-iop, composed of the values of = constraint_set0_flag, > > > > constraint_set1_flag,constraint_set2_flag, > > > > constraint_set3_flag, constraint_set4_flag, > constraint_set5_flag, > > > > and reserved_zero_2bits in bit-significance order, starting from = the > most-significant bit, and > > > > 3) level_idc. Note that reserved_zero_2bits is required to > be > > > > equal to 0 in [1], but other values for it may be specified > in > > > > the future by ITU-T or ISO/IEC. > > > > > > > > OLD: > > > > For example, in the table above, profile_idc equal to 58 > > (Extended) with profile-iop equal to 11xx0000 indicates the > > same sub-profile corresponding to profile_idc equal to 42 > > (Baseline) with profile-iop equal to x1xx0000. Note that > other > > combinations of profile_idc and profile-iop (not listed in > > Table 5) may represent a sub-profile equivalent to the > common > > subset of coding tools for more than one profile. Note = also > > that a decoder conforming to a certain profile may be able > to > > decode bitstreams conforming to other profiles. For > example, > a > > decoder conforming to the High 4:4:4 profile, at a certain > > level, must be able to decode bitstreams conforming to the > > Constrained Baseline, Main, High, High 10, or High 4:2:2 > > profile at the same or a lower level. > > > > NEW: (note that the change here is purely editorial) > > > > For example, in the table above, profile_idc equal to 58 > > > > (Extended) with profile-iop equal to 11xx0000 indicates the > > > > same sub-profile corresponding to profile_idc equal to 42 > > > > (Baseline) with profile-iop equal to x1xx0000. Note that > other > > > > combinations of profile_idc and profile-iop (not listed in > > > > Table 5) may represent a sub-profile equivalent to the > common > > > > subset of coding tools for more than one profile. Note = also > > > > that a decoder conforming to a certain profile may be able > to > > > > decode bitstreams conforming to other profiles. > > > > > > > > OLD: > > > > If the profile-level-id parameter is used for capability > > exchange or session setup procedure, it indicates the = subset > of > > coding tools, which is equal to the default sub-profile, > that > > the codec supports for both receiving and sending. > > > > NEW: (note that the change here is purely editorial) > > > > If the profile-level-id parameter is used for capability > > > > exchange or session setup, it indicates the subset of > > > > coding tools, which is equal to the default sub-profile, > that > > > > the codec supports for both receiving and sending. > > > > > > > > OLD: > > > > max-cpb: The value of max-cpb is an integer indicating the > maximum > > > > coded picture buffer size in units of 1000 bits for the VCL > HRD > > > > parameters (see A.3.1, item i of [1]) and in units of 1200 > bits > > > > for the NAL HRD parameters (see A.3.1, item j of [1]). > > > > NEW: (note that the change here is purely editorial) > > > > max-cpb: The value of max-cpb is an integer indicating the > maximum > > > > coded picture buffer size in units of 1000 bits for the VCL > HRD > > > > parameters and in units of 1200 bits > > > > for the NAL HRD parameters. > > > > > > > > OLD: > > > > max-dpb: The value of max-dpb is an integer indicating the > maximum > > > > decoded picture buffer size in units of 1024 bytes. The > max- > > > > dpb parameter signals that the receiver has more memory = than > > > > the minimum amount of decoded picture buffer memory = required > by > > > > the signaled highest level conveyed in the value of the > > > > profile-level-id parameter or the max-recv-level parameter. > > > > When max-dpb is signaled, the receiver MUST be able to > decode > > > > NAL unit streams that conform to the signaled highest = level, > > > > with the exception that the MaxDPB value in Table A-1 of = [1] > > > > for the signaled highest level is replaced with the value = of > > > > max-dpb. Consequently, a receiver that signals max-dpb = MUST > be > > > > capable of storing the following number of decoded frames, > > > > complementary field pairs, and non-paired fields in its > decoded > > > > picture buffer: > > > > > > > > Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs = * > > > > 256 * ChromaFormatFactor ), 16) > > > > > > > > PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are > > > > defined in [1]. > > > > > > > > The value of max-dpb MUST be greater than or equal to the > value > > > > of MaxDPB given in Table A-1 of [1] for the highest level. > > > > Senders MAY use this knowledge to construct coded video > streams > > > > with improved compression. > > > > NEW: (When this change can be considered as editorial can be > discussed, but the nature of this change > > as follows. On the other hand, if not changed, then the semantics of > max-dpb is simply equivalent to > > unspecified, as MaxDPB and ChromaFormatFactor are not found in the > latest H.264 spec any more. Note > > that compared to RFC 3984, the bits on the wire do not change.) > > > > max-dpb: The value of max-dpb is an integer indicating the > maximum > > > > decoded picture buffer size in units of 8/3 macroblocks. > The > max- > > > > dpb parameter signals that the receiver has more memory = than > > > > the minimum amount of decoded picture buffer memory = required > by > > > > the signaled highest level conveyed in the value of the > > > > profile-level-id parameter or the max-recv-level parameter. > > > > When max-dpb is signaled, the receiver MUST be able to > decode > > > > NAL unit streams that conform to the signaled highest = level, > > > > with the exception that the MaxDpbMbs value in Table A-1 of > [1] > > > > for the signaled highest level is replaced with the value = of > > > > max-dpb * 3 / 8. Consequently, a receiver that signals > max-dpb MUST be > > > > capable of storing the following number of decoded frames, > > > > complementary field pairs, and non-paired fields in its > decoded > > > > picture buffer: > > > > > > > > Min(max-dpb * 3 / 8 / ( PicWidthInMbs * > FrameHeightInMbs), > 16) > > > > > > > > Wherein PicWidthInMbs and FrameHeightInMbs are defined in > [1]. > > > > > > > > The value of max-dpb MUST be greater than or equal to the > value > > > > of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is > given > in > > > > Table A-1 of [1] for the highest level. > > > > Senders MAY use this knowledge to construct coded video > streams > > > > with improved compression. > > > > > > > > OLD: > > > > max-br: The value of max-br is an integer indicating the > maximum > > video bitrate in units of 1000 bits per second for the VCL > HRD > > parameters (see A.3.1, item i of [1]) and in units of 1200 > bits > > per second for the NAL HRD parameters (see A.3.1, item j of > > [1]). > > ... > > > > For example, if a receiver signals capability for Level 1.2 > > > > with max-br equal to 1550, this indicates a maximum video > > > > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum > > > > video bitrate of 1860 kbits/sec for NAL HRD parameters, and > a > > > > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). > > > > NEW: (note that the change here is purely editorial) > > > > max-br: The value of max-br is an integer indicating the > maximum > > video bitrate in units of 1000 bits per second for the VCL > HRD > > parameters and in units of 1200 bits > > per second for the NAL HRD parameters. > > ... > > > > For example, if a receiver signals capability for Main > profile Level 1.2 > > > > with max-br equal to 1550, this indicates a maximum video > > > > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum > > > > video bitrate of 1860 kbits/sec for NAL HRD parameters, and > a > > > > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). > > > > > > > > ------------------------------------End of suggested changes > -------------------------------------- > > > > > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf = Of > Ye-Kui Wang > > Sent: Sunday, March 20, 2011 4:21 AM > > To: payload@ietf.org; avt@ietf.org > > Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload > drafts > > > > > > > > Folks, > > > > > > > > The three H.264/AVC related payload formats, namely, > draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt- > > rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the > AUTH48 > stage. > > > > > > > > The RFC-Editor has found the following problem: In > draft-ietf-avt-rtp-rfc3984bis-12, the definition of > > the max-dpb media parameter refers to the MaxDPB that was defined = the > first version of the H.264/AVC > > spec, but not any more in the latest version (the 2010 version). The > parameter in the latest H.264/AVC > > version corresponding to MaxDPB is MaxDpbMbs, and the unit of the = new > parameter (i.e., macroblocks) is > > different from the original one (i.e. 1024 bytes). > > > > > > > > The problem applies also to the SVC payload format, the RCDO payload > format, and H.241. > > > > > > > > A solution has been found and agreed, involving rfc3984bis authors > and > some key people related to > > H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., > Stephen Botzko and Patrick Luthi). > > Furthermore, we have found that there are also a couple of places > that > need fixes due to similar > > changes from the initial version of H.264/AVC to the latest version. > > > > > > > > Per Roni's suggestion, I am sending in below the changes to > draft-ietf-avt-rtp-rfc3984bis-12 for > > review by the Payload and AVTcore WGs. It seems that exactly the = same > changes are needed to draft- > > ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), = and > similar but slightly different > > changes are needed to draft-ietf-avt-rtp-svc-27. > > > > > > > > Since the drafts are at the AUTH48 stage, please provide comments by > Monday, March 21, if any. Many > > thanks! > > > > > > > > BR, YK > > > > >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt From stewe@stewe.org Sat Mar 26 01:55:40 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404B53A6900; Sat, 26 Mar 2011 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 qkyKyzZxmQol; Sat, 26 Mar 2011 01:55:39 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 190C13A68FD; Sat, 26 Mar 2011 01:55:38 -0700 (PDT) Received: from [192.168.0.4] (unverified [84.187.126.113]) by stewe.org (SurgeMail 3.9e) with ESMTP id 2138-1743317 for multiple; Sat, 26 Mar 2011 09:57:13 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Sat, 26 Mar 2011 09:56:41 +0100 From: Stephan Wenger To: IETF AVT WG , Message-ID: Thread-Topic: VP8 payload format Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3383978221_4045035" X-Originating-IP: 84.187.126.113 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (84.187.126.113) was found in the spamhaus database. http://www.spamhaus.net Subject: [payload] VP8 payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 08:55:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3383978221_4045035 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, I had a brief look at the payload format specification as well as the VP8 codec specification. I support the adoption of the payload format as a PAYLOAD work item. However, we Vidyo people (Alex, Jonathan, and myself) would like to suggest adding a few mechanisms to efficiently support temporal scalability, so to at least partially enable the use of VP8 in applications like ours. We believe that the VP8 codec does support temporal scalability, but only when those mechanisms are present in the payload (or in the VP8 bitstream). These mechanisms are based on lessons learned during the implementation of more subtle parts of the SVC payload. Let's get together in Prague and see how far we can get with this. Thanks, Stephan --B_3383978221_4045035 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
I had a br= ief look at the payload format specification as well as the VP8 codec specif= ication.  I support the adoption of the payload format as a PAYLOAD wor= k item.  However, we Vidyo people (Alex, Jonathan, and myself) would li= ke to suggest adding a few mechanisms to efficiently support temporal scalab= ility, so to at least partially enable the use of VP8 in applications like o= urs.  We believe that the VP8 codec does support temporal scalability, = but only when those mechanisms are present in the payload (or in the VP8 bit= stream).  These mechanisms are based on lessons learned during the impl= ementation of more subtle parts of the SVC payload.  Let's get together= in Prague and see how far we can get with this.
Thanks,
Stephan


--B_3383978221_4045035-- From mzanaty@cisco.com Sat Mar 26 21:21:21 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77003A689A; Sat, 26 Mar 2011 21:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] 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 Z-O37E7-IJRb; Sat, 26 Mar 2011 21:21:08 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 90B093A68B0; Sat, 26 Mar 2011 21:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mzanaty@cisco.com; l=47621; q=dns/txt; s=iport; t=1301199765; x=1302409365; h=mime-version:subject:date:message-id:from:to:cc; bh=smy0kyrYbGLzdKsutnzXoXbv/Egyj3Nkb5pozoZVReQ=; b=CNHN4+m3mgdjYBSlPUzNsBi0eENyO93aPrn8M4/Rz8fDbJYvRGyORVAd O113mx/aoVSDjYKmWk+pIdKC5rPt98JBjrbQTF9b/KGs2+7Tc4g3oWX1U vPOKK642Hi1VvaFByEeQf8yaGCldfvCuus3tSxGTk5MOowcEOuOlXuANw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAAAi7jk2tJXHB/2dsb2JhbACCYJVJjTx3p1+ae4VpBIU6ixc X-IronPort-AV: E=Sophos;i="4.63,249,1299456000"; d="scan'208,217";a="281506558" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-4.cisco.com with ESMTP; 27 Mar 2011 04:22:44 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2R4Mhuo024360; Sun, 27 Mar 2011 04:22:43 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Mar 2011 23:22:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEC36.9E4B4891" Date: Sat, 26 Mar 2011 23:22:42 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-Index: Acvm161AAF2A6AC0R/ODLEMZyh1IcgAwzyEAAIkXUFAAnXzNcA== From: "Mo Zanaty (mzanaty)" To: "Ye-Kui Wang" , , X-OriginalArrivalTime: 27 Mar 2011 04:22:44.0030 (UTC) FILETIME=[9E6995E0:01CBEC36] Cc: Gary Sullivan , Roni Even Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 04:21:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEC36.9E4B4891 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proposed changes to max-dpb, max-cpb and max-br sacrifice some backward compatibility with RFC 3984 and forward compatibility with H.264. The latter seems intentional but the former seems unintentional. Further changes are needed to fix or clearly convey these incompatibilities. =20 What was discussed and decided regarding max-dpb, max-cpb and max-br in the ITU/IETF F2F meetings? Based on the original suggested changes (at the end without color coding), forward compatibility with H.264 appears to be the focus. But after "further discussions", the newest suggested changes (with color coding) appear focused on backward compatibility with RFC 3984, but don't fully achieve this. =20 The problem with RFC 3984 backward compatibility is that changing the units of max-dpb (from 1024 bytes to 8/3 macroblocks) only works for the 4:2:0 chroma format, which is the primary format used in most profiles and applications. However, the high profiles support other chroma formats, and this change breaks backward compatibility for them. =20 For example, consider an RFC 3984 implementation that declares max-dpb=3D8100 (KB) to support 3 reference frames of 720p at 4:4:4. The proposed change would misinterpret this declaration to mean 6 reference frames of 720p at any chroma format including 4:4:4, hence potentially overflowing the old RFC 3984 receiver's DPB by a factor of 2. =20 (Note that H.264 got away with changing MaxDPB since the original 2003 version only supported 4:2:0. When the high profiles which support other chroma formats were added in 2005, MaxDPB was explicitly redefined in terms of 4:2:0 so it remains constant across all chroma formats. For further clarity, MaxDpbMbs later replaced MaxDPB. But RFC 3984 never kept up with these changes, so implementations are stuck with the 2003 definitions even for later features such as the high profiles and other chroma formats.) =20 The problem with H.264 forward compatibility is that NOT changing the units of max-cpb and max-br for the high profiles (to include the scaling factors 1.25/3/4) obviously creates confusion and incompatibility between H.264 and this bis draft. This seems like an intentional change after "further discussions" decided to focus on RFC 3984 backward compatibility at the expense of H.264 forward compatibility. =20 Before deciding on specific new text, the WG should decide on whether the focus of this draft should be backward compatibility with RFC 3984 or forward compatibility with H.264. Or if the intent is to strike some balance between the two, then clearly convey the intentional incompatibilities in the text. =20 Regards, Mo Zanaty =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Monday, March 21, 2011 4:11 AM To: payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload drafts =20 Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD. =20 BR, YK =20 ------------------------------------Start of suggested changes -------------------------------------- =20 Section 8.1: OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: =20 Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) =20 PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. =20 The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. NEW: (When this change can be considered as editorial can be discussed, but the nature of this change as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: =20 Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) =20 Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. =20 The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in=20 Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. =20 =20 ------------------------------------End of suggested changes -------------------------------------- =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Sunday, March 20, 2011 4:21 AM To: payload@ietf.org; avt@ietf.org Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts =20 Folks, =20 The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. =20 The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is different from the original one (i.e. 1024 bytes). =20 The problem applies also to the SVC payload format, the RCDO payload format, and H.241. =20 A solution has been found and agreed, involving rfc3984bis authors and some key people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). Furthermore, we have found that there are also a couple of places that need fixes due to similar changes from the initial version of H.264/AVC to the latest version. =20 Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different changes are needed to draft-ietf-avt-rtp-svc-27. =20 Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many thanks! =20 BR, YK =20 =20 ------------------------------------Start of suggested changes -------------------------------------- =20 Section 8.1: OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size. For Constrained Baseline, Baseline, Main=20 and Extended profiles, the unit is 1000 bits for the VCL HRD parameters and 1200 bits for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,=20 High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits for the VCL HRD and cpbBrNalFactor bits for the NAL HRD parameters. =20 OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). NEW:=20 max-br: The value of max-br is an integer indicating the maximum video bitrate. For Constrained Baseline, Baseline, Main=20 and Extended profiles, the unit is 1000 bits per second for the VCL HRD parameters and 1200 bits per second for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,=20 High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits per second for the VCL HRD and cpbBrNalFactor bits per second for the NAL HRD parameters. =20 ------------------------------------End of suggested changes -------------------------------------- =20 =20 ------_=_NextPart_001_01CBEC36.9E4B4891 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The proposed changes to max-dpb, max-cpb and = max-br sacrifice some backward compatibility with RFC 3984 and forward = compatibility with H.264. The latter seems intentional but the former = seems unintentional. Further changes are needed to fix or clearly convey = these incompatibilities.

 

What was discussed = and decided regarding max-dpb, max-cpb and max-br in the ITU/IETF F2F = meetings? Based on the original suggested changes (at the end without = color coding), forward compatibility with H.264 appears to be the focus. = But after “further discussions”, the newest suggested = changes (with color coding) appear focused on backward compatibility = with RFC 3984, but don’t fully achieve = this.

 

The problem with RFC = 3984 backward compatibility is that changing the units of max-dpb (from = 1024 bytes to 8/3 macroblocks) only works for the 4:2:0 chroma format, = which is the primary format used in most profiles and applications. = However, the high profiles support other chroma formats, and this change = breaks backward compatibility for them.

 

For example, consider = an RFC 3984 implementation that declares max-dpb=3D8100 (KB) to support = 3 reference frames of 720p at 4:4:4. The proposed change would = misinterpret this declaration to mean 6 reference frames of 720p at any = chroma format including 4:4:4, hence potentially overflowing the old RFC = 3984 receiver’s DPB by a factor of 2.

 

(Note that H.264 got = away with changing MaxDPB since the original 2003 version only supported = 4:2:0. When the high profiles which support other chroma formats were = added in 2005, MaxDPB was explicitly redefined in terms of 4:2:0 so it = remains constant across all chroma formats. For further clarity, = MaxDpbMbs later replaced MaxDPB. But RFC 3984 never kept up with these = changes, so implementations are stuck with the 2003 definitions even for = later features such as the high profiles and other chroma = formats.)

 

The problem with = H.264 forward compatibility is that NOT changing the units of max-cpb = and max-br for the high profiles (to include the scaling factors = 1.25/3/4) obviously creates confusion and incompatibility between H.264 = and this bis draft. This seems like an intentional change after = “further discussions” decided to focus on RFC 3984 backward = compatibility at the expense of H.264 forward = compatibility.

 

Before deciding on = specific new text, the WG should decide on whether the focus of this = draft should be backward compatibility with RFC 3984 or forward = compatibility with H.264. Or if the intent is to strike some balance = between the two, then clearly convey the intentional incompatibilities = in the text.

 

Regards,

Mo = Zanaty

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ye-Kui Wang
Sent: Monday, March 21, 2011 4:11 = AM
To: payload@ietf.org; avt@ietf.org
Subject: Re: = [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload = drafts

 

Further = discussions with the same group of persons led to a decision to stay = with the unscaled units for max-br and max-cpb, thus fewer changes are = needed to the three payload formats listed in the title and H.241. With = this, the changes needed are listed below (the originally suggested = changes are dropped from this email). This time I have highlighted the = changes, and I have also described the nature the changes below. Hope = these may help understand better what have been changed, and can lead to = a quicker decision by the group, including WG chairs, and our = AD.

 

BR, = YK

 

------------------------------------= Start of suggested changes = --------------------------------------

 

Section = 8.1:

OLD:=

=       max-dpb: The value of max-dpb is an = integer indicating the maximum

=          decoded picture buffer = size in units of 1024 bytes.  The max-

=          dpb parameter signals = that the receiver has more memory than

=          the minimum amount of = decoded picture buffer memory required by

=          the signaled highest = level conveyed in the value of the

=          profile-level-id = parameter or the max-recv-level parameter.

=          When max-dpb is = signaled, the receiver MUST be able to decode

=          NAL unit streams that = conform to the signaled highest level,

=          with the exception that = the MaxDPB value in Table A-1 of [1]

=          for the signaled = highest level is replaced with the value of

=          max-dpb.  = Consequently, a receiver that signals max-dpb MUST = be

=          capable of storing the = following number of decoded frames,

=          complementary field = pairs, and non-paired fields in its decoded

=          picture = buffer:

=  

=             = Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs = *

=             256 * = ChromaFormatFactor ), 16)

=  

=          PicWidthInMbs, = FrameHeightInMbs, and ChromaFormatFactor are

=          defined in = [1].

=  

=          The value of max-dpb = MUST be greater than or equal to the value

=          of MaxDPB given in = Table A-1 of [1] for the highest level.

=          Senders MAY use this = knowledge to construct coded video streams

=          with improved = compression.

NEW: (When this change can be = considered as editorial can be discussed, but the nature of this change = as follows. On the other hand, if not changed, then the semantics of = max-dpb is simply equivalent to unspecified, as MaxDPB and = ChromaFormatFactor are not found in the latest H.264 spec any more. Note = that compared to RFC 3984, the bits on the wire do not = change.)

=       max-dpb: The value of max-dpb is an = integer indicating the maximum

=          decoded picture buffer = size in units of 8/3 macroblocks.  The max-

=          dpb parameter signals = that the receiver has more memory than

=          the minimum amount of = decoded picture buffer memory required by

=          the signaled highest = level conveyed in the value of the

=          profile-level-id = parameter or the max-recv-level parameter.

=          When max-dpb is = signaled, the receiver MUST be able to decode

=          NAL unit streams that = conform to the signaled highest level,

=          with the exception that = the MaxDpbMbs = value in Table A-1 of [1]

     &nbs= p;   for the signaled highest level is replaced with the value = of

     &nbs= p;   max-dpb * 3 / 8= .  Consequently, a receiver that signals max-dpb MUST = be

=          capable of storing the = following number of decoded frames,

=          complementary field = pairs, and non-paired fields in its decoded

=          picture = buffer:

=  

=             Min(max-dpb * 3 / 8 / ( = PicWidthInMbs * FrameHeightInMbs), 16)

 

     &nbs= p;   Wherein PicWidthInMbs and FrameHeightInMbs are defined in = [1].=

=  

=          The value of max-dpb = MUST be greater than or equal to the value

=          of MaxDpbMbs * 3 / 8, = wherein the value of MaxDpbMbs is given in =

Table A-1 of [1] for the highest = level.=

=          Senders MAY use this = knowledge to construct coded video streams

=          with improved = compression.

=  

 

------------------------------------= End of suggested changes = --------------------------------------

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On = Behalf Of Ye-Kui Wang
Sent: Sunday, March 20, 2011 4:21 = AM
To: payload@ietf.org; avt@ietf.org
Subject: = [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload = drafts

 

Folks,

 

The three = H.264/AVC related payload formats, namely, = draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and = draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 = stage.

 

The = RFC-Editor has found the following problem: In = draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media = parameter refers to the MaxDPB that was defined the first version of the = H.264/AVC spec, but not any more in the latest version (the 2010 = version). The parameter in the latest H.264/AVC version corresponding to = MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., = macroblocks) is different from the original one (i.e. 1024 = bytes).

 

The problem = applies also to the SVC payload format, the RCDO payload format, and = H.241.

 

A solution = has been found and agreed, involving rfc3984bis authors and some key = people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and = H.241 (e.g., Stephen Botzko and Patrick Luthi). Furthermore, we have = found that there are also a couple of places that need fixes due to = similar changes from the initial version of H.264/AVC to the latest = version.

 

Per = Roni’s suggestion, I am sending in below the changes to = draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore = WGs. It seems that exactly the same changes are needed to = draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), = and similar but slightly different changes are needed to = draft-ietf-avt-rtp-svc-27.

 

Since the = drafts are at the AUTH48 stage, please provide comments by Monday, March = 21, if any. Many thanks!

 

BR, = YK

 

 

------------------------------------= Start of suggested changes = --------------------------------------

 

Section = 8.1:

OLD:=

=       max-cpb: The value of max-cpb is an = integer indicating the maximum

=          coded picture buffer = size in units of 1000 bits for the VCL HRD

=          parameters (see A.3.1, = item i of [1]) and in units of 1200 bits

=          for the NAL HRD = parameters (see A.3.1, item j of [1]).

NEW:=

=       max-cpb: The value of max-cpb is an = integer indicating the maximum

=          coded picture buffer = size. For Constrained Baseline, Baseline, Main

= and Extended profiles, the unit is 1000 bits for the VCL = HRD

=          parameters and 1200 = bits for the NAL HRD parameters. For High, High = 10,

= High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, =

= High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is = cpbBrVclFactor

= bits for the VCL HRD and cpbBrNalFactor bits for the NAL HRD = parameters.

=  

OLD:= 

      =
max-br: The value of max-br is an integer indicating the =
maximum
      =
   video bitrate in units of 1000 bits per second for the VCL =
HRD
      =
   parameters (see A.3.1, item i of [1]) and in units of 1200 =
bits
      =
   per second for the NAL HRD parameters (see A.3.1, item j =
of
      =
   [1]).

NEW: = 

      =
max-br: The value of max-br is an integer indicating the =
maximum

=          video bitrate.  = For Constrained Baseline, Baseline, Main

= and Extended profiles, the unit is 1000 bits per second for the VCL = HRD

=          parameters and 1200 = bits per second for the NAL HRD parameters. For High, High = 10,

= High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, =

= High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is = cpbBrVclFactor

= bits per second for the VCL HRD and cpbBrNalFactor bits per second for = the NAL HRD parameters.

 

------------------------------------= End of suggested changes = --------------------------------------

 

 

------_=_NextPart_001_01CBEC36.9E4B4891-- From Even.roni@huawei.com Sat Mar 26 22:23:18 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D243A6991; Sat, 26 Mar 2011 22:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.339 X-Spam-Level: X-Spam-Status: No, score=-97.339 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_PROFILE1=2.555, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 WhlhkNzp4E7L; Sat, 26 Mar 2011 22:23:03 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 6402E3A698E; Sat, 26 Mar 2011 22:23:02 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIP00HTQB0Q82@szxga05-in.huawei.com>; Sun, 27 Mar 2011 13:24:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIP0091LB0PSW@szxga05-in.huawei.com>; Sun, 27 Mar 2011 13:24:26 +0800 (CST) Received: from windows8d787f9 (dhcp-4795.meeting.ietf.org [130.129.71.149]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIP000AKB092N@szxml12-in.huawei.com>; Sun, 27 Mar 2011 13:24:25 +0800 (CST) Date: Sun, 27 Mar 2011 07:23:50 +0200 From: Roni Even In-reply-to: To: "'Mo Zanaty (mzanaty)'" , 'Ye-Kui Wang' , payload@ietf.org, avt@ietf.org Message-id: <003501cbec3f$2d8448d0$888cda70$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Y4Tbp7ToHbsmjs6ecv17SA)" Content-language: en-us Thread-index: Acvm161AAF2A6AC0R/ODLEMZyh1IcgAwzyEAAIkXUFAAnXzNcAACDXKA iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: Cc: 'Gary Sullivan' Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 05:23:19 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Y4Tbp7ToHbsmjs6ecv17SA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT HI Mo, When the solution was discussed there are two assumptions 1. Old implementations (RFC3984) expecting the maxdpb parameter in kbyes only supported 4:2:0 8-bit and no other color because otherwise using only Kbytes and not macro blocks will not work for them. 2. New implementation(RFC6184 - the assigned RFC number to 3984bis) expects a value in macroblocks and will interpret the value in maxdpb as macroblocks. So see my comments inline Roni Even As individual From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty) Sent: Sunday, March 27, 2011 6:23 AM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Cc: Gary Sullivan; Roni Even Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts The proposed changes to max-dpb, max-cpb and max-br sacrifice some backward compatibility with RFC 3984 and forward compatibility with H.264. The latter seems intentional but the former seems unintentional. Further changes are needed to fix or clearly convey these incompatibilities. What was discussed and decided regarding max-dpb, max-cpb and max-br in the ITU/IETF F2F meetings? Based on the original suggested changes (at the end without color coding), forward compatibility with H.264 appears to be the focus. But after "further discussions", the newest suggested changes (with color coding) appear focused on backward compatibility with RFC 3984, but don't fully achieve this. The problem with RFC 3984 backward compatibility is that changing the units of max-dpb (from 1024 bytes to 8/3 macroblocks) only works for the 4:2:0 chroma format, which is the primary format used in most profiles and applications. However, the high profiles support other chroma formats, and this change breaks backward compatibility for them. RE: See assumption 1 For example, consider an RFC 3984 implementation that declares max-dpb=8100 (KB) to support 3 reference frames of 720p at 4:4:4. The proposed change would misinterpret this declaration to mean 6 reference frames of 720p at any chroma format including 4:4:4, hence potentially overflowing the old RFC 3984 receiver's DPB by a factor of 2. RE: if the system is old it will calculate the KB and will not start from MBs and convert. Also we have assumption 1. (Note that H.264 got away with changing MaxDPB since the original 2003 version only supported 4:2:0. When the high profiles which support other chroma formats were added in 2005, MaxDPB was explicitly redefined in terms of 4:2:0 so it remains constant across all chroma formats. For further clarity, MaxDpbMbs later replaced MaxDPB. But RFC 3984 never kept up with these changes, so implementations are stuck with the 2003 definitions even for later features such as the high profiles and other chroma formats.) RE: so this is why the two assumption are there. The problem with H.264 forward compatibility is that NOT changing the units of max-cpb and max-br for the high profiles (to include the scaling factors 1.25/3/4) obviously creates confusion and incompatibility between H.264 and this bis draft. This seems like an intentional change after "further discussions" decided to focus on RFC 3984 backward compatibility at the expense of H.264 forward compatibility. Before deciding on specific new text, the WG should decide on whether the focus of this draft should be backward compatibility with RFC 3984 or forward compatibility with H.264. Or if the intent is to strike some balance between the two, then clearly convey the intentional incompatibilities in the text. Regards, Mo Zanaty From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Monday, March 21, 2011 4:11 AM To: payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload drafts Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD. BR, YK ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. NEW: (When this change can be considered as editorial can be discussed, but the nature of this change as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. ------------------------------------End of suggested changes -------------------------------------- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Sunday, March 20, 2011 4:21 AM To: payload@ietf.org; avt@ietf.org Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts Folks, The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is different from the original one (i.e. 1024 bytes). The problem applies also to the SVC payload format, the RCDO payload format, and H.241. A solution has been found and agreed, involving rfc3984bis authors and some key people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). Furthermore, we have found that there are also a couple of places that need fixes due to similar changes from the initial version of H.264/AVC to the latest version. Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different changes are needed to draft-ietf-avt-rtp-svc-27. Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many thanks! BR, YK ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size. For Constrained Baseline, Baseline, Main and Extended profiles, the unit is 1000 bits for the VCL HRD parameters and 1200 bits for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits for the VCL HRD and cpbBrNalFactor bits for the NAL HRD parameters. OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: max-br: The value of max-br is an integer indicating the maximum video bitrate. For Constrained Baseline, Baseline, Main and Extended profiles, the unit is 1000 bits per second for the VCL HRD parameters and 1200 bits per second for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits per second for the VCL HRD and cpbBrNalFactor bits per second for the NAL HRD parameters. ------------------------------------End of suggested changes -------------------------------------- --Boundary_(ID_Y4Tbp7ToHbsmjs6ecv17SA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

HI Mo,

When the solution was discussed there are two assumptions

1.        Old implementations (RFC3984) expecting the maxdpb parameter in kbyes only supported 4:2:0 8-bit and no other color because otherwise using only Kbytes and not macro blocks will not work for them. 2.       New implementation(RFC6184 – the assigned RFC number to 3984bis) expects a value in macroblocks and will interpret the value in maxdpb as macroblocks.

So see my comments inline

Roni Even

As individual

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Mo Zanaty (mzanaty)
Sent: Sunday, March 27, 2011 6:23 AM
To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org
Cc: Gary Sullivan; Roni Even
Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts

 

The proposed changes to max-dpb, max-cpb and max-br sacrifice some backward compatibility with RFC 3984 and forward compatibility with H.264. The latter seems intentional but the former seems unintentional. Further changes are nee ded to f e incompatibilities.

 

What was discussed and decided regarding max-dpb, max-cpb and max-br in the ITU/IETF F2F meetings? Based on the original suggested changes (at the end without color coding), forward compatibility with H.264 appears to be the focus. But after “further discussions”, the newest suggested changes (with color coding) appear focused on backward compatibility with RFC 3984, but don’t fully achieve this.

 

The problem with RFC 3984 backward compatibility is that changing the units of max-dpb (from 1024 bytes to 8/3 macroblocks) only works for the 4:2:0 chroma format, which is the primary format used in most profiles and applications. However, the high pro files su s, and this change breaks backward compatibility for them.

 

RE: See assumption 1

 

For example, consider an RFC 3984 implementation that declares max-dpb=8100 (KB) to support 3 reference frames of 720p at 4:4:4. The proposed change would misinterpret this declaration to mean 6 reference frames of 720p at any chroma format including 4:4:4, hence potentially overflowing the old RFC 3984 receiver’s DPB by a factor of 2.

 

RE: if the system is old it will calculate the KB and will not start fr we have assumption 1.

 

(Note that H.264 got away with changing MaxDPB since the original 2003 version only supported 4:2:0. When the high profiles which support other chroma formats were added in 2005, MaxDPB was explicitly redefined in terms of 4:2:0 so it remains constant across all chroma formats. For further clarity, MaxDpbMbs later replaced MaxDPB. But RFC 3984 never kept up with these changes, so implementations are stuck with the 2003 definitions even for later features such as the high profiles and other chroma formats.)

 

RE: so this is why the two assumption are there.

  ;< mal>The problem with H.264 forward compatibility is that NOT changing the units of max-cpb and max-br for the high profiles (to include the scaling factors 1.25/3/4) obviously creates confusion and incompatibility between H.264 and this bis draft. This seems like an intentional change after “further discussions” decided to focus on RFC 3984 backward compatibility at the expense of H.264 forward compatibility.

 

 

Before deciding on specific new text, the WG should decide on whether the focus of this draft should be backward compatibility with RFC 3984 or forward compatibility with H.264. Or if the intent is to strike some balance between the two, then clearly convey the intentional incompatibilities i n the te

 

Regards,

Mo Zanaty

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang
Sent: Monday, March 21, 2011 4:11 AM
To: payload@ietf.org; avt@ietf.org
Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload drafts

 

Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD.

 

BR, YK

 

------------------------------------Start of suggested changes --------------------------------------

&nb Normal>Section 8.1:

OLD:

      max-dpb: The value of max-dpb is an integer indicating the maximum

         decoded picture buffer size in units of 1024 bytes.  The max-

         dpb parameter signals that the than

         the minimum amount of decoded picture buffer memory required by

         the signaled highest level conveyed in the value of the

         profile-level-id parameter or the max-recv-level parameter.

         When max-dpb is signaled, the receiver MUST be able to decode

         NAL unit streams that conform to the signaled highest level,

         with the exception that the MaxDPB value in Table A-1 of [1]

         for the signaled highest level is replaced with the value of

nbsp;    max-dpb.  Consequently, a receiver that signals max-dpb MUST be

         capable of storing the following number of decoded frames,

         complementary field pairs, and non-paired fields in its decoded

         

            Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs *

            256 * ChromaFormatFactor ), 16)

 

                 defined in [1].

 

         The value of max-dpb MUST be greater than or equal to the value

                 Senders MAY use this knowledge to construct coded video streams

         with improved compression.

NEW: (When this change can be considered as editorial can be discussed, but the nature of this change as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note that compared to RFC 398 o not change.)

      max-dpb: The value of max-dpb is an integer indicating the maximum

         decoded picture buffer size in units of 8/3 macroblocks.  The max-

         dpb parameter signals that the receiver has more memory than

         the minimum amount of decoded picture buffer memory required by

         the signaled highest level conveyed in the value of the

         profile-level-id parameter or the max-recv-level parameter.

         When max-dpb is signaled, the receiver MUST be abl e to dec

         NAL unit streams that conform to the signaled highest level,

         with the exception that the MaxDpbMbs value in Table A-1 of [1]

         for the signaled highest level is replaced with the value of

         max-dpb * 3 / 8.  Consequently, a receiver that signals max-dpb MUST be

         capable of storing the following number of decoded frames,

         complementary field pairs, and non-paired fields in its decoded         picture buffer:

 

            Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16)

 

&n bsp;&nbs ;   Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1].

 

         The value of max-dpb MUST be greater than or equal to the value

         of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in

< eft style='text-align:left;text-indent:.75in'>Table A-1 of [1] for the highest level.

         Senders MAY use this knowledge to construct coded video streams

         with improved compression.

 

 

- ----------End of suggested changes --------------------------------------

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang
Sent: Sunday, March 20, 2011 4:21 AM
To: payload@ietf.org; avt@ietf.org
Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts

 

Folks,

 

The three H.264/AVC related payload formats, namely, draft-ietf-avt- rtp-rfc3 -rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage.

 

The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is different from the original one (i.e. 1024 bytes).

 

The problem applies also to the SVC payload format, the RCDO payload format, and H.241.

 

A solution has been found and agreed, involving rfc3984bis authors and some key people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schw arz) and zko and Patrick Luthi). Furthermore, we have found that there are also a couple of places that need fixes due to similar changes from the initial version of H.264/AVC to the latest version.

 

Per Roni’s suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different changes are needed to draft-ietf-avt-rtp-svc-27.

 

Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many thanks!

 

BR, YK

 

 

------- ----Start of suggested changes --------------------------------------

 

Section 8.1:

OLD:

      max-cpb: The value of max-cpb is an integer indicating the maximum

         coded picture buffer size in units of 1000 bits for the VCL HRD

                 for the NAL HRD parameters (see A.3.1, item j of [1]).

NEW:

      max-cpb: The value of max-cpb is an integer indicating the maximum

         coded picture buffer size. For Constrained Baseline, Baseline, Main

span style='font-size:12.0pt;font-family:SimSun'>and Extended profiles, the unit is 1000 bits for the VCL HRD

         parameters and 1200 bits for the NAL HRD parameters. For High, High 10,

High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,

High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor

bits for the VCL HRD a nd cpbBr L HRD parameters.

 

OLD:

      max-br: The value of max-br is an integer indicating the maximum
         video bitrate in units of 1000 bits per second for the VCL HRD
         parameters (see A.3.1, item i of [1]) and in units of 1200 bits
         per second for the NAL HRD parameters (see A.3.1, item j of
 &
bsp;   [1]).

NEW: 

      max-br: The value of max-br is an integer indicating the maximum

         video bitrate.  For Constrained Baseline, Baseline, Main

and Extended profiles, the unit is 1000 bits per second for the VCL HRD

        &n ont-size:12.0pt;font-family:SimSun'> parameters and 1200 bits per second for the NAL HRD parameters. For High, High 10,

High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,

High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor

bits per second for the VCL HRD and cpbBrNalFactor bits per second for the NAL HRD parameters.

 

------------------------------------End of suggested changes --------------------------------------

 

--Boundary_(ID_Y4Tbp7ToHbsmjs6ecv17SA)-- From yekui.wang@huawei.com Sun Mar 27 06:00:44 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DF43A6822; Sun, 27 Mar 2011 06:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 aB3dgBFEt-JS; Sun, 27 Mar 2011 06:00:29 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 5B7993A6823; Sun, 27 Mar 2011 06:00:29 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIP00L6ZW7HJU@usaga02-in.huawei.com>; Sun, 27 Mar 2011 06:02:05 -0700 (PDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIP00B3LW7G4G@usaga02-in.huawei.com>; Sun, 27 Mar 2011 06:02:04 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sun, 27 Mar 2011 06:02:04 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.54]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Sun, 27 Mar 2011 06:01:31 -0700 Date: Sun, 27 Mar 2011 13:01:30 +0000 From: Ye-Kui Wang In-reply-to: X-Originating-IP: [10.47.138.6] To: "Mo Zanaty (mzanaty)" , "payload@ietf.org" , "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_S2WDxSbD8uh4J8yJq+CNww)" Content-language: en-US Accept-Language: en-US Thread-topic: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-index: Acvm161AAF2A6AC0R/ODLEMZyh1IcgAwzyEAAIkXUFAAnXzNcAAR3LnQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: Gary Sullivan , Roni Even Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 13:00:44 -0000 --Boundary_(ID_S2WDxSbD8uh4J8yJq+CNww) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I think the statement "The proposed changes to max-dpb, max-cpb and max-br sacrifice some backward compatibility with RFC 3984 and forward compatibility with H.264." is incorrect. On backward compatibility with RFC 3984: The semantics in RFC 3984 does not work with color formats other than YUV 4:2:0 and bit depth other than 8 bits, and the new profiles defined in H.264 after RFC 3984's publication. The proposed changes fix this bug in a way that is backward compatible to RFC 3984, i.e., the fix now covers all color formats and bit depths, while for the video formats and profiles supported in RFC 3984, the bits on the wire remain unchanged. Therefore, I don't think the changes sacrifice backward compatibility with RFC 3984. On the so-called forward compatibility with H.264: "NOT changing the units of max-cpb and max-br for the high profiles (to include the scaling factors 1.25/3/4)" means that the numbers in the referred H.264 spec must be scaled before they are put into the payload format signaling as specified in the new RFC. Note that whether the scaling factor is considered or not, there is no problem with RFC 3984 backward compatibility. Are you saying you prefer to have the scaled units for the semantics of max-cpb and max-br? If yes, could you please explain why that is better? BR, YK From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com] Sent: Sunday, March 27, 2011 12:23 AM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Cc: Roni Even; Stephen Botzko; Gary Sullivan Subject: RE: [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload drafts The proposed changes to max-dpb, max-cpb and max-br sacrifice some backward compatibility with RFC 3984 and forward compatibility with H.264. The latter seems intentional but the former seems unintentional. Further changes are needed to fix or clearly convey these incompatibilities. What was discussed and decided regarding max-dpb, max-cpb and max-br in the ITU/IETF F2F meetings? Based on the original suggested changes (at the end without color coding), forward compatibility with H.264 appears to be the focus. But after "further discussions", the newest suggested changes (with color coding) appear focused on backward compatibility with RFC 3984, but don't fully achieve this. The problem with RFC 3984 backward compatibility is that changing the units of max-dpb (from 1024 bytes to 8/3 macroblocks) only works for the 4:2:0 chroma format, which is the primary format used in most profiles and applications. However, the high profiles support other chroma formats, and this change breaks backward compatibility for them. For example, consider an RFC 3984 implementation that declares max-dpb=8100 (KB) to support 3 reference frames of 720p at 4:4:4. The proposed change would misinterpret this declaration to mean 6 reference frames of 720p at any chroma format including 4:4:4, hence potentially overflowing the old RFC 3984 receiver's DPB by a factor of 2. (Note that H.264 got away with changing MaxDPB since the original 2003 version only supported 4:2:0. When the high profiles which support other chroma formats were added in 2005, MaxDPB was explicitly redefined in terms of 4:2:0 so it remains constant across all chroma formats. For further clarity, MaxDpbMbs later replaced MaxDPB. But RFC 3984 never kept up with these changes, so implementations are stuck with the 2003 definitions even for later features such as the high profiles and other chroma formats.) The problem with H.264 forward compatibility is that NOT changing the units of max-cpb and max-br for the high profiles (to include the scaling factors 1.25/3/4) obviously creates confusion and incompatibility between H.264 and this bis draft. This seems like an intentional change after "further discussions" decided to focus on RFC 3984 backward compatibility at the expense of H.264 forward compatibility. Before deciding on specific new text, the WG should decide on whether the focus of this draft should be backward compatibility with RFC 3984 or forward compatibility with H.264. Or if the intent is to strike some balance between the two, then clearly convey the intentional incompatibilities in the text. Regards, Mo Zanaty From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Monday, March 21, 2011 4:11 AM To: payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload drafts Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD. BR, YK ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. NEW: (When this change can be considered as editorial can be discussed, but the nature of this change as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. ------------------------------------End of suggested changes -------------------------------------- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Sunday, March 20, 2011 4:21 AM To: payload@ietf.org; avt@ietf.org Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts Folks, The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is different from the original one (i.e. 1024 bytes). The problem applies also to the SVC payload format, the RCDO payload format, and H.241. A solution has been found and agreed, involving rfc3984bis authors and some key people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). Furthermore, we have found that there are also a couple of places that need fixes due to similar changes from the initial version of H.264/AVC to the latest version. Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different changes are needed to draft-ietf-avt-rtp-svc-27. Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many thanks! BR, YK ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size. For Constrained Baseline, Baseline, Main and Extended profiles, the unit is 1000 bits for the VCL HRD parameters and 1200 bits for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits for the VCL HRD and cpbBrNalFactor bits for the NAL HRD parameters. OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: max-br: The value of max-br is an integer indicating the maximum video bitrate. For Constrained Baseline, Baseline, Main and Extended profiles, the unit is 1000 bits per second for the VCL HRD parameters and 1200 bits per second for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits per second for the VCL HRD and cpbBrNalFactor bits per second for the NAL HRD parameters. ------------------------------------End of suggested changes -------------------------------------- --Boundary_(ID_S2WDxSbD8uh4J8yJq+CNww) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I think the statement “The proposed changes to max-dpb, max-cpb and max-br sacrifice some backward compatibility with RFC 3984 and forward compatibility with H.264.” is incorrect.

 

On backward compatibility with RFC 3984: The semantics in RFC 3984 does not work with color formats other than YUV 4:2:0 and bit depth other than 8 bits, and the new profiles defined in H.264 after RFC 3984’s publication. The proposed changes fix this bug in a way that is backward compatible to RFC 3984, i.e., the fix now covers all color formats and bit depths, while for the video formats and profiles supported in RFC 3984, the bits on the wire remain unchanged. Therefore, I don’t think the changes sacrifice backward compatibility with RFC 3984.

 

On the so-called forward compatibility with H.264: “NOT changing the units of max-cpb and max-br for the high profiles (to include the scaling factors 1.25/3/4)” means that the numbers in the referred H.264 spec must be scaled before they are put into the payload format signaling as specified in the new RFC. Note that whether the scaling factor is considered or not, there is no problem with RFC 3984 backward compatibility. Are you saying you prefer to have the scaled units for the semantics of max-cpb and max-br? If yes, could you please explain why that is better?

 

BR, YK

 

From: Mo Zanaty (mzanaty) [mailto:mzanaty@cisco.com]
Sent: Sunday, March 27, 2011 12:23 AM
To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org
Cc: Roni Even; Stephen Botzko; Gary Sullivan
Subject: RE: [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload drafts

 

The proposed changes to max-dpb, max-cpb and max-br sacrifice some backward compatibility with RFC 3984 and forward compatibility with H.264. The latter seems intentional but the former seems unintentional. Further changes are needed to fix or clearly convey these incompatibilities.

 

What was discussed and decided regarding max-dpb, max-cpb and max-br in the ITU/IETF F2F meetings? Based on the original suggested changes (at the end without color coding), forward compatibility with H.264 appears to be the focus. But after “further discussions”, the newest suggested changes (with color coding) appear focused on backward compatibility with RFC 3984, but don’t fully achieve this.

 

The problem with RFC 3984 backward compatibility is that changing the units of max-dpb (from 1024 bytes to 8/3 macroblocks) only works for the 4:2:0 chroma format, which is the primary format used in most profiles and applications. However, the high profiles support other chroma formats, and this change breaks backward compatibility for them.

 

For example, consider an RFC 3984 implementation that declares max-dpb=8100 (KB) to support 3 reference frames of 720p at 4:4:4. The proposed change would misinterpret this declaration to mean 6 reference frames of 720p at any chroma format including 4:4:4, hence potentially overflowing the old RFC 3984 receiver’s DPB by a factor of 2.

 

(Note that H.264 got away with changing MaxDPB since the original 2003 version only supported 4:2:0. When the high profiles which support other chroma formats were added in 2005, MaxDPB was explicitly redefined in terms of 4:2:0 so it remains constant across all chroma formats. For further clarity, MaxDpbMbs later replaced MaxDPB. But RFC 3984 never kept up with these changes, so implementations are stuck with the 2003 definitions even for later features such as the high profiles and other chroma formats.)

 

The problem with H.264 forward compatibility is that NOT changing the units of max-cpb and max-br for the high profiles (to include the scaling factors 1.25/3/4) obviously creates confusion and incompatibility between H.264 and this bis draft. This seems like an intentional change after “further discussions” decided to focus on RFC 3984 backward compatibility at the expense of H.264 forward compatibility.

 

Before deciding on specific new text, the WG should decide on whether the focus of this draft should be backward compatibility with RFC 3984 or forward compatibility with H.264. Or if the intent is to strike some balance between the two, then clearly convey the intentional incompatibilities in the text.

 

Regards,

Mo Zanaty

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang
Sent: Monday, March 21, 2011 4:11 AM
To: payload@ietf.org; avt@ietf.org
Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload drafts

 

Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD.

 

BR, YK

 

------------------------------------Start of suggested changes --------------------------------------

 

Section 8.1:

OLD:

      max-dpb: The value of max-dpb is an integer indicating the maximum

         decoded picture buffer size in units of 1024 bytes.  The max-

         dpb parameter signals that the receiver has more memory than

         the minimum amount of decoded picture buffer memory required by

         the signaled highest level conveyed in the value of the

         profile-level-id parameter or the max-recv-level parameter.

         When max-dpb is signaled, the receiver MUST be able to decode

         NAL unit streams that conform to the signaled highest level,

         with the exception that the MaxDPB value in Table A-1 of [1]

         for the signaled highest level is replaced with the value of

         max-dpb.  Consequently, a receiver that signals max-dpb MUST be

         capable of storing the following number of decoded frames,

         complementary field pairs, and non-paired fields in its decoded

         picture buffer:

 

            Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs *

            256 * ChromaFormatFactor ), 16)

 

         PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are

         defined in [1].

 

         The value of max-dpb MUST be greater than or equal to the value

         of MaxDPB given in Table A-1 of [1] for the highest level.

         Senders MAY use this knowledge to construct coded video streams

         with improved compression.

NEW: (When this change can be considered as editorial can be discussed, but the nature of this change as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change.)

      max-dpb: The value of max-dpb is an integer indicating the maximum

         decoded picture buffer size in units of 8/3 macroblocks.  The max-

         dpb parameter signals that the receiver has more memory than

         the minimum amount of decoded picture buffer memory required by

         the signaled highest level conveyed in the value of the

         profile-level-id parameter or the max-recv-level parameter.

         When max-dpb is signaled, the receiver MUST be able to decode

         NAL unit streams that conform to the signaled highest level,

         with the exception that the MaxDpbMbs value in Table A-1 of [1]

         for the signaled highest level is replaced with the value of

         max-dpb * 3 / 8.  Consequently, a receiver that signals max-dpb MUST be

         capable of storing the following number of decoded frames,

         complementary field pairs, and non-paired fields in its decoded

         picture buffer:

 

            Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16)

 

         Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1].

 

         The value of max-dpb MUST be greater than or equal to the value

         of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in

Table A-1 of [1] for the highest level.

         Senders MAY use this knowledge to construct coded video streams

         with improved compression.

 

 

------------------------------------End of suggested changes --------------------------------------

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang
Sent: Sunday, March 20, 2011 4:21 AM
To: payload@ietf.org; avt@ietf.org
Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts

 

Folks,

 

The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage.

 

The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is different from the original one (i.e. 1024 bytes).

 

The problem applies also to the SVC payload format, the RCDO payload format, and H.241.

 

A solution has been found and agreed, involving rfc3984bis authors and some key people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). Furthermore, we have found that there are also a couple of places that need fixes due to similar changes from the initial version of H.264/AVC to the latest version.

 

Per Roni’s suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different changes are needed to draft-ietf-avt-rtp-svc-27.

 

Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many thanks!

 

BR, YK

 

 

------------------------------------Start of suggested changes --------------------------------------

 

Section 8.1:

OLD:

      max-cpb: The value of max-cpb is an integer indicating the maximum

         coded picture buffer size in units of 1000 bits for the VCL HRD

         parameters (see A.3.1, item i of [1]) and in units of 1200 bits

         for the NAL HRD parameters (see A.3.1, item j of [1]).

NEW:

      max-cpb: The value of max-cpb is an integer indicating the maximum

         coded picture buffer size. For Constrained Baseline, Baseline, Main

and Extended profiles, the unit is 1000 bits for the VCL HRD

         parameters and 1200 bits for the NAL HRD parameters. For High, High 10,

High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,

High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor

bits for the VCL HRD and cpbBrNalFactor bits for the NAL HRD parameters.

 

OLD:

      max-br: The value of max-br is an integer indicating the maximum
         video bitrate in units of 1000 bits per second for the VCL HRD
         parameters (see A.3.1, item i of [1]) and in units of 1200 bits
         per second for the NAL HRD parameters (see A.3.1, item j of
         [1]).

NEW: 

      max-br: The value of max-br is an integer indicating the maximum

         video bitrate.  For Constrained Baseline, Baseline, Main

and Extended profiles, the unit is 1000 bits per second for the VCL HRD

         parameters and 1200 bits per second for the NAL HRD parameters. For High, High 10,

High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,

High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor

bits per second for the VCL HRD and cpbBrNalFactor bits per second for the NAL HRD parameters.

 

------------------------------------End of suggested changes --------------------------------------

 

 

--Boundary_(ID_S2WDxSbD8uh4J8yJq+CNww)-- From sjoerd.simons@collabora.co.uk Sun Mar 27 08:03:24 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F573A6818 for ; Sun, 27 Mar 2011 08:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 wR7SLjP935SY for ; Sun, 27 Mar 2011 08:03:24 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by core3.amsl.com (Postfix) with ESMTP id DC49C3A6868 for ; Sun, 27 Mar 2011 08:03:23 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: sjoerd) with ESMTPSA id 317756011D0 Received: by night.luon.net (Postfix, from userid 1000) id 9644175587; Sun, 27 Mar 2011 16:04:59 +0100 (BST) From: Sjoerd Simons To: Harald Alvestrand , patrik.westin@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Organization: Collabora Ltd. Date: Sun, 27 Mar 2011 16:04:59 +0100 Message-ID: <1301238299.19152.4.camel@night> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Cc: payload@ietf.org Subject: [payload] VP8 RTP specification implemetation notes X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 15:03:24 -0000 Hey all, Just before the first vp8 draft was sent to the IETF i sent some of my experiences to the webm discussion list: https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_threa= d/thread/b5963b4228133341/1653b4b0f8f5387d?lnk=3Dgst&q=3Drtp#1653b4b0f8f538= 7d It would be nice if some of those experiences could be taken into account when moving the specification forward. --=20 Sjoerd Simons Collabora Ltd. From aallison@nab.org Wed Mar 23 07:35:59 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690C33A691F; Wed, 23 Mar 2011 07:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 Qzs8Id-pEHFx; Wed, 23 Mar 2011 07:35:56 -0700 (PDT) Received: from p01c11o144.mxlogic.net (p01c11o144.mxlogic.net [208.65.144.67]) by core3.amsl.com (Postfix) with ESMTP id CF7F43A6919; Wed, 23 Mar 2011 07:35:55 -0700 (PDT) Received: from unknown [208.97.234.91] (EHLO NABSREX027324.NAB.ORG) by p01c11o144.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 9a50a8d4.0.4901.00-359.11364.p01c11o144.mxlogic.net (envelope-from ); Wed, 23 Mar 2011 08:37:30 -0600 (MDT) X-MXL-Hash: 4d8a05aa7aa51c8b-773f1af9b788741c36c04e14422ae7a08c8a1333 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Mar 2011 10:37:26 -0400 Message-ID: <71C9EC0544D1F64D8B7D91EDCC62202006890498@NABSREX027324.NAB.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-Index: AQHL6TfkNG8bu5QUBkWtpBAtPXzvbpQ6866Q References: <71C9EC0544D1F64D8B7D91EDCC62202006890479@NABSREX027324.NAB.ORG> From: "Allison, Art" To: "Ye-Kui Wang" , , X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [208.97.234.91] X-AnalysisOut: [v=1.0 c=1 a=DzHdTxL-66EA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-] X-AnalysisOut: [IA:10 a=tFGTPFZixTZ3yCXJchW01Q==:17 a=g0FpLpFZAAAA:8 a=i0E] X-AnalysisOut: [eH86SAAAA:8 a=48vgC7mUAAAA:8 a=KFtVM71Ojwk9vxD59x0A:9 a=4s] X-AnalysisOut: [WVP4qkbm72IdYnaWEA:7 a=h_9P7y10rm6nB48iuRaEXH9nOWgA:4 a=wP] X-AnalysisOut: [NLvfGTeEIA:10 a=8SgyfJxrfqYA:10 a=-9UqKSle32gA:10 a=Qd0007] X-AnalysisOut: [q6B0YA:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=XbQgGpvnme] X-AnalysisOut: [2S4Gwb:21 a=VOCzThdEtGMs-80J:21] X-Mailman-Approved-At: Sun, 27 Mar 2011 13:22:55 -0700 Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 14:35:59 -0000 I admit significant ignorance of the technical details. =20 My main point, based on decades of standards development experience, was = that last minute changes such as these often result in failure to fix = the issue precisely and that the due process group should be given time = to assure the correct fix has been made. Rushing can work, but often = has a bad outcome.=20 As to specifics; I saw that the values of 1000 and 1200 as the correct = unit sizes for NAL stream overhead (in some cases). In one place these = are asserted to be bits (no rate units) as a multiplier and in another = place these are described as bits-per-second. These are clearly = different usages. Perhaps both usages are correct - I do not know - but = it appeared to be inconsistent. (And this type of inconsistency is = exactly the kind of thing that I have seen happen when last minute = patches are made to a standard.) By magic number, I meant was it correct that these values have two = different uses, perhaps due to their fundamental nature. I do not assert anything is wrong, I suggest that unless there is a = vital need to push this out fast, that the draft be referred back to the = drafting group. Maybe all those folks have had time to carefully = consider and respond before the deadline...and this is specious. I believe that you can make better decisions when = more information is provided. I commented to so assist. =20 Art Allison Senior Director Advanced Engineering, Science and Technology National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone=A0 202 429 5418=20 Fax=A0 202 775 4981 www.nab.org Advocacy =A0Education=A0 Innovation -----Original Message----- From: Ye-Kui Wang [mailto:yekui.wang@huawei.com]=20 Sent: Wednesday, March 23, 2011 4:54 AM To: Allison, Art; payload@ietf.org; avt@ietf.org Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and = RCDO payload drafts The units of the values of 1000 and 1200 are clearly specified. Where is = not clear, could you clarify?=20 What is "that" in "Is that a coincidence, error or a magic number = effect?"? If you read carefully the previous two emails on this subject I sent = out, you would have noticed that the factor you mentioned, which is not = only for High profile, but for many other profiles, and the factor can = be different for different profiles, has been addressed. Please let us = know if you found any place that is not well addressed. Finally, what is "this" in "I think this should be sent back for = correction..."? I guess you meant for the entire draft. But if you don't = point out the place that needs to be corrected, what we can do? BR, YK -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Allison, Art Sent: Monday, March 21, 2011 4:47 PM To: payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and = RCDO payload drafts It has been by experience that discovery of a significant technical = issue that is 'patched' in a draft standard in a hurry to get it = published is always risky and often results in an internal = inconsistency. Seems to me that is a few weeks delay for the formulating body to review = is prudent - even if such change can be done.=20 Just reading for consistency, as I am no expert in the codec; I see the = 1000 and 1200 values expressed as pure multipliers and bits per second? = Is that a coincidence, error or a magic number effect? And the High = Profile factor of 1.25 (to these values) that is in the AVC standard = seems to be relevant, but is not being discussed. Is that covered = elsewhere in a clear fashion and independent? I think this should be sent back for correction...and thanks go to the = sharp eye who caught the discrepancy. Art Art Allison Senior Director Advanced Engineering, Science and Technology National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone=A0 202 429 5418=20 Fax=A0 202 775 4981 www.nab.org Advocacy =A0Education=A0 Innovation -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Charles Eckel (eckelcu) Sent: Monday, March 21, 2011 1:52 PM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC,and = RCDO payload drafts Hi YK, Thank you for providing this clear description of the proposed changes. The changes look good to me. Cheers, Charles > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Monday, March 21, 2011 1:11 AM > To: payload@ietf.org; avt@ietf.org > Subject: Re: [payload] Some changes to rfc3984bis, SVC,and RCDO payload drafts >=20 > Further discussions with the same group of persons led to a decision to stay with the unscaled units > for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title > and H.241. With this, the changes needed are listed below (the originally suggested changes are > dropped from this email). This time I have highlighted the changes, and I have also described the > nature the changes below. Hope these may help understand better what have been changed, and can lead > to a quicker decision by the group, including WG chairs, and our AD. >=20 >=20 >=20 > BR, YK >=20 >=20 >=20 > ------------------------------------Start of suggested changes -------------------------------------- >=20 >=20 >=20 > Section 8.1: >=20 > OLD: >=20 > profile-level-id: > A base16 [7] (hexadecimal) representation of the following > three bytes in the sequence parameter set NAL unit is specified > in [1]: 1) profile_idc, 2) a byte herein referred to as > profile-iop, composed of the values of constraint_set0_flag, > constraint_set1_flag,constraint_set2_flag, > constraint_set3_flag, and reserved_zero_4bits in bit- > significance order, starting from the most-significant bit, and > 3) level_idc. Note that reserved_zero_4bits is required to be > equal to 0 in [1], but other values for it may be specified in > the future by ITU-T or ISO/IEC. >=20 > NEW: (note that the change here is purely editorial) >=20 > profile-level-id: >=20 > A base16 [7] (hexadecimal) representation of the following >=20 > three bytes in the sequence parameter set NAL unit is specified >=20 > in [1]: 1) profile_idc, 2) a byte herein referred to as >=20 > profile-iop, composed of the values of constraint_set0_flag, >=20 > constraint_set1_flag,constraint_set2_flag, >=20 > constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, >=20 > and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and >=20 > 3) level_idc. Note that reserved_zero_2bits is required to be >=20 > equal to 0 in [1], but other values for it may be specified in >=20 > the future by ITU-T or ISO/IEC. >=20 >=20 >=20 > OLD: >=20 > For example, in the table above, profile_idc equal to 58 > (Extended) with profile-iop equal to 11xx0000 indicates the > same sub-profile corresponding to profile_idc equal to 42 > (Baseline) with profile-iop equal to x1xx0000. Note that other > combinations of profile_idc and profile-iop (not listed in > Table 5) may represent a sub-profile equivalent to the common > subset of coding tools for more than one profile. Note also > that a decoder conforming to a certain profile may be able to > decode bitstreams conforming to other profiles. For example, a > decoder conforming to the High 4:4:4 profile, at a certain > level, must be able to decode bitstreams conforming to the > Constrained Baseline, Main, High, High 10, or High 4:2:2 > profile at the same or a lower level. >=20 > NEW: (note that the change here is purely editorial) >=20 > For example, in the table above, profile_idc equal to 58 >=20 > (Extended) with profile-iop equal to 11xx0000 indicates the >=20 > same sub-profile corresponding to profile_idc equal to 42 >=20 > (Baseline) with profile-iop equal to x1xx0000. Note that other >=20 > combinations of profile_idc and profile-iop (not listed in >=20 > Table 5) may represent a sub-profile equivalent to the common >=20 > subset of coding tools for more than one profile. Note also >=20 > that a decoder conforming to a certain profile may be able to >=20 > decode bitstreams conforming to other profiles. >=20 >=20 >=20 > OLD: >=20 > If the profile-level-id parameter is used for capability > exchange or session setup procedure, it indicates the subset of > coding tools, which is equal to the default sub-profile, that > the codec supports for both receiving and sending. >=20 > NEW: (note that the change here is purely editorial) >=20 > If the profile-level-id parameter is used for capability >=20 > exchange or session setup, it indicates the subset of >=20 > coding tools, which is equal to the default sub-profile, that >=20 > the codec supports for both receiving and sending. >=20 >=20 >=20 > OLD: >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters (see A.3.1, item i of [1]) and in units of 1200 bits >=20 > for the NAL HRD parameters (see A.3.1, item j of [1]). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-cpb: The value of max-cpb is an integer indicating the maximum >=20 > coded picture buffer size in units of 1000 bits for the VCL HRD >=20 > parameters and in units of 1200 bits >=20 > for the NAL HRD parameters. >=20 >=20 >=20 > OLD: >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 1024 bytes. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDPB value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * >=20 > 256 * ChromaFormatFactor ), 16) >=20 >=20 >=20 > PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are >=20 > defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDPB given in Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 > NEW: (When this change can be considered as editorial can be discussed, but the nature of this change > as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to > unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note > that compared to RFC 3984, the bits on the wire do not change.) >=20 > max-dpb: The value of max-dpb is an integer indicating the maximum >=20 > decoded picture buffer size in units of 8/3 macroblocks. The max- >=20 > dpb parameter signals that the receiver has more memory than >=20 > the minimum amount of decoded picture buffer memory required by >=20 > the signaled highest level conveyed in the value of the >=20 > profile-level-id parameter or the max-recv-level parameter. >=20 > When max-dpb is signaled, the receiver MUST be able to decode >=20 > NAL unit streams that conform to the signaled highest level, >=20 > with the exception that the MaxDpbMbs value in Table A-1 of [1] >=20 > for the signaled highest level is replaced with the value of >=20 > max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be >=20 > capable of storing the following number of decoded frames, >=20 > complementary field pairs, and non-paired fields in its decoded >=20 > picture buffer: >=20 >=20 >=20 > Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) >=20 >=20 >=20 > Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. >=20 >=20 >=20 > The value of max-dpb MUST be greater than or equal to the value >=20 > of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in >=20 > Table A-1 of [1] for the highest level. >=20 > Senders MAY use this knowledge to construct coded video streams >=20 > with improved compression. >=20 >=20 >=20 > OLD: >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters (see A.3.1, item i of [1]) and in units of 1200 bits > per second for the NAL HRD parameters (see A.3.1, item j of > [1]). > ... >=20 > For example, if a receiver signals capability for Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 > NEW: (note that the change here is purely editorial) >=20 > max-br: The value of max-br is an integer indicating the maximum > video bitrate in units of 1000 bits per second for the VCL HRD > parameters and in units of 1200 bits > per second for the NAL HRD parameters. > ... >=20 > For example, if a receiver signals capability for Main profile Level 1.2 >=20 > with max-br equal to 1550, this indicates a maximum video >=20 > bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum >=20 > video bitrate of 1860 kbits/sec for NAL HRD parameters, and a >=20 > CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). >=20 >=20 >=20 > ------------------------------------End of suggested changes -------------------------------------- >=20 >=20 >=20 > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang > Sent: Sunday, March 20, 2011 4:21 AM > To: payload@ietf.org; avt@ietf.org > Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts >=20 >=20 >=20 > Folks, >=20 >=20 >=20 > The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt- > rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. >=20 >=20 >=20 > The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of > the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC > spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC > version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is > different from the original one (i.e. 1024 bytes). >=20 >=20 >=20 > The problem applies also to the SVC payload format, the RCDO payload format, and H.241. >=20 >=20 >=20 > A solution has been found and agreed, involving rfc3984bis authors and some key people related to > H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). > Furthermore, we have found that there are also a couple of places that need fixes due to similar > changes from the initial version of H.264/AVC to the latest version. >=20 >=20 >=20 > Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for > review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft- > ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different > changes are needed to draft-ietf-avt-rtp-svc-27. >=20 >=20 >=20 > Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many > thanks! >=20 >=20 >=20 > BR, YK >=20 >=20 _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From mzanaty@cisco.com Sat Mar 26 20:54:27 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B4943A687B; Sat, 26 Mar 2011 20:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] 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 0L+UddTb3rOX; Sat, 26 Mar 2011 20:54:04 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 21EDB3A68AA; Sat, 26 Mar 2011 20:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mzanaty@cisco.com; l=111890; q=dns/txt; s=iport; t=1301198140; x=1302407740; h=mime-version:subject:date:message-id:from:to:cc; bh=f3VUDMqzhYm5PWLXhIm9UoPZ2O7axpKGPKGWhLVSotM=; b=MgdVIfVtW2HTRjOsA5GHk1yF1kKJ9mUOybIvnvKrqqySReZcXOXxew9n sNxU6l0GnXV014Lr6o9gH6b69H1ZlOw63Q1iSomohzTBorVmlUbtftvS8 gQOcRZzyl+XFblWgPFW5aN5voEZWVMrZohUrzqC87qdZVlPVasf3hPHAq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAAOW0jk2tJV2Y/2dsb2JhbACCYJVJjTx3p3yae4VpBIU6ixc X-IronPort-AV: E=Sophos;i="4.63,249,1299456000"; d="scan'208,217";a="325205369" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-2.cisco.com with ESMTP; 27 Mar 2011 03:55:38 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2R3tcSc024759; Sun, 27 Mar 2011 03:55:38 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Mar 2011 22:55:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEC32.D58B7903" Date: Sat, 26 Mar 2011 22:55:36 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-Index: Acvm161AAF2A6AC0R/ODLEMZyh1IcgAwzyEAAIkXUFA= From: "Mo Zanaty (mzanaty)" To: "Ye-Kui Wang" , , X-OriginalArrivalTime: 27 Mar 2011 03:55:38.0834 (UTC) FILETIME=[D5B85B20:01CBEC32] X-Mailman-Approved-At: Sun, 27 Mar 2011 13:22:55 -0700 Cc: Gary Sullivan , Roni Even Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 03:54:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEC32.D58B7903 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proposed changes to max-dpb, max-cpb and max-br sacrifice some backward compatibility with RFC 3984 and forward compatibility with H.264. The latter seems intentional but the former seems unintentional. Further changes are needed to fix or clearly convey these incompatibilities. =20 What was discussed and decided regarding max-dpb, max-cpb and max-br in the ITU/IETF F2F meetings? Based on the original suggested changes (at the end without color coding), forward compatibility with H.264 appears to be the focus. But after "further discussions", the newest suggested changes (with color coding) appear focused on backward compatibility with RFC 3984, but don't fully achieve this. =20 The problem with RFC 3984 backward compatibility is that changing the units of max-dpb (from 1024 bytes to 8/3 macroblocks) only works for the 4:2:0 chroma format, which is the primary format used in most profiles and applications. However, the high profiles support other chroma formats, and this change breaks backward compatibility for them. =20 For example, consider an RFC 3984 implementation that declares max-dpb=3D8100 (KB) to support 3 reference frames of 720p at 4:4:4. The proposed change would misinterpret this declaration to mean 6 reference frames of 720p at any chroma format including 4:4:4, hence potentially overflowing the old RFC 3984 receiver's DPB by a factor of 2. =20 (Note that H.264 got away with changing MaxDPB since the original 2003 version only supported 4:2:0. When the high profiles which support other chroma formats were added in 2005, MaxDPB was explicitly redefined in terms of 4:2:0 so it remains constant across all chroma formats. For further clarity, MaxDpbMbs later replaced MaxDPB. But RFC 3984 never kept up with these changes, so implementations are stuck with the 2003 definitions even for later features such as the high profiles and other chroma formats.) =20 The problem with H.264 forward compatibility is that NOT changing the units of max-cpb and max-br for the high profiles (to include the scaling factors 1.25/3/4) obviously creates confusion and incompatibility between H.264 and this bis draft. This seems like an intentional change after "further discussions" decided to focus on RFC 3984 backward compatibility at the expense of H.264 forward compatibility. =20 Before deciding on specific new text, the WG should decide on whether the focus of this draft should be backward compatibility with RFC 3984 or forward compatibility with H.264. Or if the intent is to strike some balance between the two, then clearly convey the intentional incompatibilities in the text. =20 Regards, Mo Zanaty =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Monday, March 21, 2011 4:11 AM To: payload@ietf.org; avt@ietf.org Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload drafts =20 Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD. =20 BR, YK =20 ------------------------------------Start of suggested changes -------------------------------------- =20 Section 8.1: OLD: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_4bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. NEW: (note that the change here is purely editorial) profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. =20 OLD: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. For example, a decoder conforming to the High 4:4:4 profile, at a certain level, must be able to decode bitstreams conforming to the Constrained Baseline, Main, High, High 10, or High 4:2:2 profile at the same or a lower level. NEW: (note that the change here is purely editorial) For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. =20 OLD: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. NEW: (note that the change here is purely editorial) If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. =20 OLD:=20 max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: (note that the change here is purely editorial) max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters and in units of 1200 bits for the NAL HRD parameters. =20 OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: =20 Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) =20 PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. =20 The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. NEW: (When this change can be considered as editorial can be discussed, but the nature of this change as follows. On the other hand, if not changed, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the latest H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: =20 Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) =20 Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. =20 The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in=20 Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. =20 OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). ... For example, if a receiver signals capability for Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). NEW: (note that the change here is purely editorial)=20 max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters and in units of 1200 bits per second for the NAL HRD parameters. ... For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). =20 ------------------------------------End of suggested changes -------------------------------------- =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Sunday, March 20, 2011 4:21 AM To: payload@ietf.org; avt@ietf.org Subject: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts =20 Folks, =20 The three H.264/AVC related payload formats, namely, draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 stage. =20 The RFC-Editor has found the following problem: In draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media parameter refers to the MaxDPB that was defined the first version of the H.264/AVC spec, but not any more in the latest version (the 2010 version). The parameter in the latest H.264/AVC version corresponding to MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., macroblocks) is different from the original one (i.e. 1024 bytes). =20 The problem applies also to the SVC payload format, the RCDO payload format, and H.241. =20 A solution has been found and agreed, involving rfc3984bis authors and some key people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and H.241 (e.g., Stephen Botzko and Patrick Luthi). Furthermore, we have found that there are also a couple of places that need fixes due to similar changes from the initial version of H.264/AVC to the latest version. =20 Per Roni's suggestion, I am sending in below the changes to draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore WGs. It seems that exactly the same changes are needed to draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), and similar but slightly different changes are needed to draft-ietf-avt-rtp-svc-27. =20 Since the drafts are at the AUTH48 stage, please provide comments by Monday, March 21, if any. Many thanks! =20 BR, YK =20 =20 ------------------------------------Start of suggested changes -------------------------------------- =20 Section 8.1: OLD: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_4bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. NEW: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. =20 OLD: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. For example, a decoder conforming to the High 4:4:4 profile, at a certain level, must be able to decode bitstreams conforming to the Constrained Baseline, Main, High, High 10, or High 4:2:2 profile at the same or a lower level. NEW: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. =20 OLD: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. NEW: If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. =20 OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size. For Constrained Baseline, Baseline, Main=20 and Extended profiles, the unit is 1000 bits for the VCL HRD parameters and 1200 bits for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,=20 High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits for the VCL HRD and cpbBrNalFactor bits for the NAL HRD parameters. =20 OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: =20 Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) =20 PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. =20 The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. NEW: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: =20 Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) =20 Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. =20 The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in=20 Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. =20 OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). ... For example, if a receiver signals capability for Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). NEW:=20 max-br: The value of max-br is an integer indicating the maximum video bitrate. For Constrained Baseline, Baseline, Main=20 and Extended profiles, the unit is 1000 bits per second for the VCL HRD parameters and 1200 bits per second for the NAL HRD parameters. For High, High 10, High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra,=20 High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is cpbBrVclFactor bits per second for the VCL HRD and cpbBrNalFactor bits per second for the NAL HRD parameters. ... For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). =20 ------------------------------------End of suggested changes -------------------------------------- =20 =20 ------_=_NextPart_001_01CBEC32.D58B7903 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The proposed changes to max-dpb, max-cpb and = max-br sacrifice some backward compatibility with RFC 3984 and forward = compatibility with H.264. The latter seems intentional but the former = seems unintentional. Further changes are needed to fix or clearly convey = these incompatibilities.

 

What was discussed = and decided regarding max-dpb, max-cpb and max-br in the ITU/IETF F2F = meetings? Based on the original suggested changes (at the end without = color coding), forward compatibility with H.264 appears to be the focus. = But after “further discussions”, the newest suggested = changes (with color coding) appear focused on backward compatibility = with RFC 3984, but don’t fully achieve = this.

 

The problem with RFC = 3984 backward compatibility is that changing the units of max-dpb (from = 1024 bytes to 8/3 macroblocks) only works for the 4:2:0 chroma format, = which is the primary format used in most profiles and applications. = However, the high profiles support other chroma formats, and this change = breaks backward compatibility for them.

 

For example, consider = an RFC 3984 implementation that declares max-dpb=3D8100 (KB) to support = 3 reference frames of 720p at 4:4:4. The proposed change would = misinterpret this declaration to mean 6 reference frames of 720p at any = chroma format including 4:4:4, hence potentially overflowing the old RFC = 3984 receiver’s DPB by a factor of 2.

 

(Note that H.264 got = away with changing MaxDPB since the original 2003 version only supported = 4:2:0. When the high profiles which support other chroma formats were = added in 2005, MaxDPB was explicitly redefined in terms of 4:2:0 so it = remains constant across all chroma formats. For further clarity, = MaxDpbMbs later replaced MaxDPB. But RFC 3984 never kept up with these = changes, so implementations are stuck with the 2003 definitions even for = later features such as the high profiles and other chroma = formats.)

 

The problem with = H.264 forward compatibility is that NOT changing the units of max-cpb = and max-br for the high profiles (to include the scaling factors = 1.25/3/4) obviously creates confusion and incompatibility between H.264 = and this bis draft. This seems like an intentional change after = “further discussions” decided to focus on RFC 3984 backward = compatibility at the expense of H.264 forward = compatibility.

 

Before deciding on = specific new text, the WG should decide on whether the focus of this = draft should be backward compatibility with RFC 3984 or forward = compatibility with H.264. Or if the intent is to strike some balance = between the two, then clearly convey the intentional incompatibilities = in the text.

 

Regards,

Mo = Zanaty

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Ye-Kui Wang
Sent: Monday, March 21, 2011 4:11 = AM
To: payload@ietf.org; avt@ietf.org
Subject: Re: = [AVTCORE] Some changes to rfc3984bis, SVC,and RCDO payload = drafts

 

Further = discussions with the same group of persons led to a decision to stay = with the unscaled units for max-br and max-cpb, thus fewer changes are = needed to the three payload formats listed in the title and H.241. With = this, the changes needed are listed below (the originally suggested = changes are dropped from this email). This time I have highlighted the = changes, and I have also described the nature the changes below. Hope = these may help understand better what have been changed, and can lead to = a quicker decision by the group, including WG chairs, and our = AD.

 

BR, = YK

 

------------------------------------= Start of suggested changes = --------------------------------------

 

Section = 8.1:

OLD:= 

      =
profile-level-id:
      =
   A base16 [7] (hexadecimal) representation of the =
following
      =
   three bytes in the sequence parameter set NAL unit is =
specified
      =
   in [1]: 1) profile_idc, 2) a byte herein referred to =
as
      =
   profile-iop, composed of the values of =
constraint_set0_flag,
      =
   =
constraint_set1_flag,constraint_set2_flag,
      =
   constraint_set3_flag, and reserved_zero_4bits in =
bit-
      =
   significance order, starting from the most-significant bit, =
and
      =
   3) level_idc.  Note that reserved_zero_4bits is =
required to be
      =
   equal to 0 in [1], but other values for it may be specified =
in
      =
   the future by ITU-T or ISO/IEC.

 NEW: (note that the change here = is purely editorial)

=       profile-level-id:

=          A base16 [7] = (hexadecimal) representation of the following

=          three bytes in the = sequence parameter set NAL unit is specified

=          in [1]: 1) profile_idc, = 2) a byte herein referred to as

=          profile-iop, composed = of the values of constraint_set0_flag,

=          = constraint_set1_flag,constraint_set2_flag,

=          constraint_set3_flag, = constraint_set4_flag, = constraint_set5_flag,

 and = reserved_zero_2bits= in bit-significance order, starting from the most-significant bit, = and

=          3) level_idc.  = Note that reserved_zero_2bits is required to be

=          equal to 0 in [1], but = other values for it may be specified in

=          the future by ITU-T or = ISO/IEC.

 

OLD:= 

      =
   For example, in the table above, profile_idc equal to =
58
      =
   (Extended) with profile-iop equal to 11xx0000 indicates =
the
      =
   same sub-profile corresponding to profile_idc equal to =
42
      =
   (Baseline) with profile-iop equal to x1xx0000.  Note =
that other
      =
   combinations of profile_idc and profile-iop (not listed =
in
 =
        Table 5) may represent a =
sub-profile equivalent to the common
      =
   subset of coding tools for more than one profile.  =
Note also
      =
   that a decoder conforming to a certain profile may be able =
to
      =
   decode bitstreams conforming to other profiles.  For example, =
a
&nb=
sp;        decoder conforming to the =
High 4:4:4 profile, at a certain
&nb=
sp;        level, must be able to =
decode bitstreams conforming to the
&nb=
sp;        Constrained Baseline, =
Main, High, High 10, or High 4:2:2
&nb=
sp;        profile at the same or a =
lower level.

 NEW: (note that the change here = is purely editorial)

=          For example, in the = table above, profile_idc equal to 58

=          (Extended) with = profile-iop equal to 11xx0000 indicates the

=          same sub-profile = corresponding to profile_idc equal to 42

=          (Baseline) with = profile-iop equal to x1xx0000.  Note that = other

=          combinations of = profile_idc and profile-iop (not listed in

=          Table 5) may represent = a sub-profile equivalent to the common

=          subset of coding tools = for more than one profile.  Note also

=          that a decoder = conforming to a certain profile may be able to

=          decode bitstreams = conforming to other profiles.

=  

OLD:= 

      =
   If the profile-level-id parameter is used for =
capability
      =
   exchange or session setup procedure, it =
indicates the subset of
      =
   coding tools, which is equal to the default sub-profile, =
that
      =
   the codec supports for both receiving and =
sending.

 NEW: (note that the change here = is purely editorial)

=          If the profile-level-id = parameter is used for capability

=          exchange or session = setup, it indicates the subset of

=          coding tools, which is = equal to the default sub-profile, that

=          the codec supports for = both receiving and sending.

 

OLD: =

=       max-cpb: The value of max-cpb is an = integer indicating the maximum

=          coded picture buffer = size in units of 1000 bits for the VCL HRD

=          parameters (see A.3.1, item i of = [1]) and in units of 1200 bits

=          for the NAL HRD = parameters (see A.3.1, = item j of [1]).

NEW: (note that the change here = is purely editorial)

=       max-cpb: The value of max-cpb is an = integer indicating the maximum

=          coded picture buffer = size in units of 1000 bits for the VCL HRD

=          parameters and in units = of 1200 bits

=          for the NAL HRD = parameters.

=  

OLD:=

=       max-dpb: The value of max-dpb is an = integer indicating the maximum

=          decoded picture buffer = size in units of 1024 bytes.  The max-

=          dpb parameter signals = that the receiver has more memory than

=          the minimum amount of = decoded picture buffer memory required by

=          the signaled highest = level conveyed in the value of the

=          profile-level-id = parameter or the max-recv-level parameter.

=          When max-dpb is = signaled, the receiver MUST be able to decode

=          NAL unit streams that = conform to the signaled highest level,

=          with the exception that = the MaxDPB value in Table A-1 of [1]

=          for the signaled = highest level is replaced with the value of

=          max-dpb.  = Consequently, a receiver that signals max-dpb MUST = be

=          capable of storing the = following number of decoded frames,

=          complementary field = pairs, and non-paired fields in its decoded

=          picture = buffer:

=  

=             = Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs = *

=             256 * = ChromaFormatFactor ), 16)

=  

=          PicWidthInMbs, = FrameHeightInMbs, and ChromaFormatFactor are

=          defined in = [1].

=  

=          The value of max-dpb = MUST be greater than or equal to the value

=          of MaxDPB given in = Table A-1 of [1] for the highest level.

=          Senders MAY use this = knowledge to construct coded video streams

=          with improved = compression.

NEW: (When this change can be = considered as editorial can be discussed, but the nature of this change = as follows. On the other hand, if not changed, then the semantics of = max-dpb is simply equivalent to unspecified, as MaxDPB and = ChromaFormatFactor are not found in the latest H.264 spec any more. Note = that compared to RFC 3984, the bits on the wire do not = change.)

=       max-dpb: The value of max-dpb is an = integer indicating the maximum

=          decoded picture buffer = size in units of 8/3 macroblocks.  The max-

=          dpb parameter signals = that the receiver has more memory than

=          the minimum amount of = decoded picture buffer memory required by

=          the signaled highest = level conveyed in the value of the

=          profile-level-id = parameter or the max-recv-level parameter.

=          When max-dpb is = signaled, the receiver MUST be able to decode

=          NAL unit streams that = conform to the signaled highest level,

=          with the exception that = the MaxDpbMbs = value in Table A-1 of [1]

     &nbs= p;   for the signaled highest level is replaced with the value = of

     &nbs= p;   max-dpb * 3 / 8= .  Consequently, a receiver that signals max-dpb MUST = be

=          capable of storing the = following number of decoded frames,

=          complementary field = pairs, and non-paired fields in its decoded

=          picture = buffer:

=  

=             Min(max-dpb * 3 / 8 / ( = PicWidthInMbs * FrameHeightInMbs), 16)

 

     &nbs= p;   Wherein PicWidthInMbs and FrameHeightInMbs are defined in = [1].=

=  

=          The value of max-dpb = MUST be greater than or equal to the value

=          of MaxDpbMbs * 3 / 8, = wherein the value of MaxDpbMbs is given in =

Table A-1 of [1] for the highest = level.=

=          Senders MAY use this = knowledge to construct coded video streams

=          with improved = compression.

=  

OLD:= 

      =
max-br: The value of max-br is an integer indicating the =
maximum
      =
   video bitrate in units of 1000 bits per second for the VCL =
HRD
      =
   parameters (see A.3.1, item i of =
[1]) and in units of 1200 bits
      =
   per second for the NAL HRD parameters (see A.3.1, item j =
of
      =
   [1]).=

      =
   …

=          For example, if a = receiver signals capability for Level 1.2

=          with max-br equal to = 1550, this indicates a maximum video

=          bitrate of 1550 = kbits/sec for VCL HRD parameters, a maximum

=          video bitrate of 1860 = kbits/sec for NAL HRD parameters, and a

=          CPB size of 4036458 = bits (1550000 / 384000 * 1000 * 1000).

NEW: (note that the change here = is purely editorial) 

      =
max-br: The value of max-br is an integer indicating the =
maximum
      =
   video bitrate in units of 1000 bits per second for the VCL =
HRD
      =
   parameters and in units of 1200 =
bits
      =
   per second for the NAL HRD =
parameters.
      =
   …

=          For example, if a = receiver signals capability for Main profile = Level 1.2

=          with max-br equal to = 1550, this indicates a maximum video

=          bitrate of 1550 = kbits/sec for VCL HRD parameters, a maximum

=          video bitrate of 1860 = kbits/sec for NAL HRD parameters, and a

=          CPB size of 4036458 = bits (1550000 / 384000 * 1000 * 1000).

 

------------------------------------= End of suggested changes = --------------------------------------

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On = Behalf Of Ye-Kui Wang
Sent: Sunday, March 20, 2011 4:21 = AM
To: payload@ietf.org; avt@ietf.org
Subject: = [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload = drafts

 

Folks,

 

The three = H.264/AVC related payload formats, namely, = draft-ietf-avt-rtp-rfc3984bis-12, draft-ietf-avt-rtp-svc-27, and = draft-ietf-avt-rtp-h264-rcdo-08, are all at the AUTH48 = stage.

 

The = RFC-Editor has found the following problem: In = draft-ietf-avt-rtp-rfc3984bis-12, the definition of the max-dpb media = parameter refers to the MaxDPB that was defined the first version of the = H.264/AVC spec, but not any more in the latest version (the 2010 = version). The parameter in the latest H.264/AVC version corresponding to = MaxDPB is MaxDpbMbs, and the unit of the new parameter (i.e., = macroblocks) is different from the original one (i.e. 1024 = bytes).

 

The problem = applies also to the SVC payload format, the RCDO payload format, and = H.241.

 

A solution = has been found and agreed, involving rfc3984bis authors and some key = people related to H.264/AVC (e.g., Gary Sullivan and Heiko Schwarz) and = H.241 (e.g., Stephen Botzko and Patrick Luthi). Furthermore, we have = found that there are also a couple of places that need fixes due to = similar changes from the initial version of H.264/AVC to the latest = version.

 

Per = Roni’s suggestion, I am sending in below the changes to = draft-ietf-avt-rtp-rfc3984bis-12 for review by the Payload and AVTcore = WGs. It seems that exactly the same changes are needed to = draft-ietf-avt-rtp-h264-rcdo-08 (co-authors of this draft may confirm), = and similar but slightly different changes are needed to = draft-ietf-avt-rtp-svc-27.

 

Since the = drafts are at the AUTH48 stage, please provide comments by Monday, March = 21, if any. Many thanks!

 

BR, = YK

 

 

------------------------------------= Start of suggested changes = --------------------------------------

 

Section = 8.1:

OLD:= 

      =
profile-level-id:
      =
   A base16 [7] (hexadecimal) representation of the =
following
      =
   three bytes in the sequence parameter set NAL unit is =
specified
      =
   in [1]: 1) profile_idc, 2) a byte herein referred to =
as
      =
   profile-iop, composed of the values of =
constraint_set0_flag,
      =
   =
constraint_set1_flag,constraint_set2_flag,
      =
   constraint_set3_flag, and reserved_zero_4bits in =
bit-
      =
   significance order, starting from the most-significant bit, =
and
     =
    3) level_idc.  Note that =
reserved_zero_4bits is required to be
      =
   equal to 0 in [1], but other values for it may be specified =
in
      =
   the future by ITU-T or ISO/IEC.

 NEW:<= /span>

=       profile-level-id:

=          A base16 [7] = (hexadecimal) representation of the following

=          three bytes in the = sequence parameter set NAL unit is specified

=          in [1]: 1) profile_idc, = 2) a byte herein referred to as

=          profile-iop, composed = of the values of constraint_set0_flag,

=          = constraint_set1_flag,constraint_set2_flag,

=          constraint_set3_flag, = constraint_set4_flag, constraint_set5_flag,

=  and reserved_zero_2bits in bit-significance order, starting from = the most-significant bit, and

=          3) level_idc.  = Note that reserved_zero_2bits is required to be

=          equal to 0 in [1], but = other values for it may be specified in

=          the future by ITU-T or = ISO/IEC.

 

OLD:= 

      =
   For example, in the table above, profile_idc equal to =
58
      =
   (Extended) with profile-iop equal to 11xx0000 indicates =
the
      =
   same sub-profile corresponding to profile_idc equal to =
42
      =
   (Baseline) with profile-iop equal to x1xx0000.  Note =
that other
      =
   combinations of profile_idc and profile-iop (not listed =
in
      =
   Table 5) may represent a sub-profile equivalent to the =
common
      =
   subset of coding tools for more than one profile.  =
Note also
      =
   that a decoder conforming to a certain profile may be able =
to
      =
   decode bitstreams conforming to other profiles.  For =
example, a
      =
   decoder conforming to the High 4:4:4 profile, at a =
certain
      =
   level, must be able to decode bitstreams conforming to =
the
      =
   Constrained Baseline, Main, High, High 10, or High =
4:2:2
      =
   profile at the same or a lower =
level.

 NEW:<= /span>

=          For example, in the = table above, profile_idc equal to 58

=          (Extended) with = profile-iop equal to 11xx0000 indicates the

=          same sub-profile = corresponding to profile_idc equal to 42

=          (Baseline) with = profile-iop equal to x1xx0000.  Note that = other

=          combinations of = profile_idc and profile-iop (not listed in

=          Table 5) may represent = a sub-profile equivalent to the common

=          subset of coding tools = for more than one profile.  Note also

=          that a decoder = conforming to a certain profile may be able to

=          decode bitstreams = conforming to other profiles.

=  

OLD:= 

      =
   If the profile-level-id parameter is used for =
capability
      =
   exchange or session setup procedure, it indicates the =
subset of
      =
   coding tools, which is equal to the default sub-profile, =
that
      =
   the codec supports for both receiving and =
sending.

 NEW:<= /span>

=          If the profile-level-id = parameter is used for capability

=          exchange or session = setup, it indicates the subset of

=          coding tools, which is = equal to the default sub-profile, that

=          the codec supports for = both receiving and sending.

 

OLD:=

=       max-cpb: The value of max-cpb is an = integer indicating the maximum

=          coded picture buffer = size in units of 1000 bits for the VCL HRD

=          parameters (see A.3.1, = item i of [1]) and in units of 1200 bits

=          for the NAL HRD = parameters (see A.3.1, item j of [1]).

NEW:=

=       max-cpb: The value of max-cpb is an = integer indicating the maximum

=          coded picture buffer = size. For Constrained Baseline, Baseline, Main

= and Extended profiles, the unit is 1000 bits for the VCL = HRD

=          parameters and 1200 = bits for the NAL HRD parameters. For High, High = 10,

= High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, =

= High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is = cpbBrVclFactor

= bits for the VCL HRD and cpbBrNalFactor bits for the NAL HRD = parameters.

=  

OLD:=

=       max-dpb: The value of max-dpb is an = integer indicating the maximum

=          decoded picture buffer = size in units of 1024 bytes.  The max-

=          dpb parameter signals = that the receiver has more memory than

=          the minimum amount of = decoded picture buffer memory required by

=          the signaled highest = level conveyed in the value of the

=          profile-level-id = parameter or the max-recv-level parameter.

=          When max-dpb is = signaled, the receiver MUST be able to decode

=          NAL unit streams that = conform to the signaled highest level,

=          with the exception that = the MaxDPB value in Table A-1 of [1]

=          for the signaled = highest level is replaced with the value of

=          max-dpb.  = Consequently, a receiver that signals max-dpb MUST = be

=          capable of storing the = following number of decoded frames,

=          complementary field = pairs, and non-paired fields in its decoded

=          picture = buffer:

=  

=             = Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs = *

=             256 * = ChromaFormatFactor ), 16)

=  

=          PicWidthInMbs, = FrameHeightInMbs, and ChromaFormatFactor are

=          defined in = [1].

=  

=          The value of max-dpb = MUST be greater than or equal to the value

=          of MaxDPB given in = Table A-1 of [1] for the highest level.

=          Senders MAY use this = knowledge to construct coded video streams

=          with improved = compression.

NEW:=

=       max-dpb: The value of max-dpb is an = integer indicating the maximum

=          decoded picture buffer = size in units of 8/3 macroblocks.  The max-

=          dpb parameter signals = that the receiver has more memory than

=          the minimum amount of = decoded picture buffer memory required by

=          the signaled highest = level conveyed in the value of the

=          profile-level-id = parameter or the max-recv-level parameter.

=          When max-dpb is = signaled, the receiver MUST be able to decode

=          NAL unit streams that = conform to the signaled highest level,

=          with the exception that = the MaxDpbMbs value in Table A-1 of [1]

=          for the signaled = highest level is replaced with the value of

=          max-dpb * 3 / 8.  = Consequently, a receiver that signals max-dpb MUST = be

=          capable of storing the = following number of decoded frames,

=          complementary field = pairs, and non-paired fields in its decoded

=          picture = buffer:

=  

=             = Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), = 16)

=  

=          Wherein PicWidthInMbs = and FrameHeightInMbs are defined in [1].

=  

=          The value of max-dpb = MUST be greater than or equal to the value

=          of MaxDpbMbs * 3 / 8, = wherein the value of MaxDpbMbs is given in

= Table A-1 of [1] for the highest level.

=          Senders MAY use this = knowledge to construct coded video streams

=          with improved = compression.

=  

OLD:= 

      =
max-br: The value of max-br is an integer indicating the =
maximum
      =
   video bitrate in units of 1000 bits per second for the VCL =
HRD
      =
   parameters (see A.3.1, item i of [1]) and in units of 1200 =
bits
      =
   per second for the NAL HRD parameters (see A.3.1, item j =
of
      =
   [1]).
      =
   …

=          For example, if a = receiver signals capability for Level 1.2

=          with max-br equal to = 1550, this indicates a maximum video

=          bitrate of 1550 = kbits/sec for VCL HRD parameters, a maximum

=          video bitrate of 1860 = kbits/sec for NAL HRD parameters, and a

=          CPB size of 4036458 = bits (1550000 / 384000 * 1000 * 1000).

NEW: = 

      =
max-br: The value of max-br is an integer indicating the =
maximum

=          video bitrate.  = For Constrained Baseline, Baseline, Main

= and Extended profiles, the unit is 1000 bits per second for the VCL = HRD

=          parameters and 1200 = bits per second for the NAL HRD parameters. For High, High = 10,

= High 4:2:2, High 4:4:4 Predictive, High 10 Intra, High 4:2:2 Intra, =

= High 4:4:4 Intra and CAVLC 4:4:4 Intra profiles, the unit is = cpbBrVclFactor

= bits per second for the VCL HRD and cpbBrNalFactor bits per second for = the NAL HRD parameters.

      =
   …

=          For example, if a = receiver signals capability for Main profile Level = 1.2

=          with max-br equal to = 1550, this indicates a maximum video

=          bitrate of 1550 = kbits/sec for VCL HRD parameters, a maximum

=          video bitrate of 1860 = kbits/sec for NAL HRD parameters, and a

=          CPB size of 4036458 = bits (1550000 / 384000 * 1000 * 1000).

 

------------------------------------= End of suggested changes = --------------------------------------

 

 

------_=_NextPart_001_01CBEC32.D58B7903-- From hlundin@google.com Sun Mar 27 21:40:28 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783773A67F2 for ; Sun, 27 Mar 2011 21:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 3Kc45yA4uubA for ; Sun, 27 Mar 2011 21:40:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 3699E3A67E9 for ; Sun, 27 Mar 2011 21:40:26 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p2S4g2M9012333 for ; Sun, 27 Mar 2011 21:42:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1301287323; bh=ZlogHuAgYk75fvdStYaRgzu7ft8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ewapppg2rv06XGSzVMgsgdp2oiDhrM4itbymsmrq+pXZ3lJcX6D0spr0S9IsA3aIv bk+JkgIuSbgd7pPUrdzug== Received: from qyk36 (qyk36.prod.google.com [10.241.83.164]) by kpbe12.cbf.corp.google.com with ESMTP id p2S4g0ET012112 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 27 Mar 2011 21:42:01 -0700 Received: by qyk36 with SMTP id 36so1167924qyk.4 for ; Sun, 27 Mar 2011 21:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GjuG0YY2cwAr09euZpEEUyChVun+RqFM0FJg7eoHKE0=; b=yxeFLf5ChkTVsT45+X3kIULOKAEZC7yOHe8mwoWKBrKH7dfmwy2v4/LcG7VqFSvwto 3lBKWgydQr5qno/nTn+A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aRexIcoFDaFED3wUWr4cqEJCvFu0RQb2JVq6FSCXRTdYKmDniwQW7x1WAzFMIrhUP0 ZO35GNvC0zsZ1Y4B43PQ== MIME-Version: 1.0 Received: by 10.229.44.141 with SMTP id a13mr2730996qcf.101.1301287320305; Sun, 27 Mar 2011 21:42:00 -0700 (PDT) Received: by 10.229.0.136 with HTTP; Sun, 27 Mar 2011 21:42:00 -0700 (PDT) In-Reply-To: <1301238299.19152.4.camel@night> References: <1301238299.19152.4.camel@night> Date: Mon, 28 Mar 2011 06:42:00 +0200 Message-ID: From: Henrik Lundin To: Sjoerd Simons Content-Type: multipart/alternative; boundary=001636831fa07a4588049f83906a X-System-Of-Record: true Cc: payload@ietf.org, patrik.westin@gmail.com Subject: Re: [payload] VP8 RTP specification implemetation notes X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 04:40:28 -0000 --001636831fa07a4588049f83906a Content-Type: text/plain; charset=ISO-8859-1 Hi Sjoerd, Thanks for notifying us. We will review your comments carefully and incorporate them in the process. Any chance to see you in Prague this week? Thanks, /Henrik On Sun, Mar 27, 2011 at 5:04 PM, Sjoerd Simons < sjoerd.simons@collabora.co.uk> wrote: > Hey all, > > Just before the first vp8 draft was sent to the IETF i sent some of my > experiences to the webm discussion list: > > https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/b5963b4228133341/1653b4b0f8f5387d?lnk=gst&q=rtp#1653b4b0f8f5387d > > It would be nice if some of those experiences could be taken into > account when moving the specification forward. > > -- > Sjoerd Simons > Collabora Ltd. > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --001636831fa07a4588049f83906a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Sjoerd,

Thanks for notifying us. We will review your = comments carefully and incorporate them in the process. Any chance to see y= ou in Prague this week?

Thanks,
/Henrik<= /div>



On Sun, Mar 27, 2011= at 5:04 PM, Sjoerd Simons <sjoerd.simons@collabora.co.uk> wrote:<= br>
Hey all,

Just before the first vp8 draft was sent to the IETF i sent some of my
experiences to the webm discussion list:
https://groups.google.com/a/webmprojec= t.org/group/webm-discuss/browse_thread/thread/b5963b4228133341/1653b4b0f8f5= 387d?lnk=3Dgst&q=3Drtp#1653b4b0f8f5387d

It would be nice if some of those experiences could be taken into
account when moving the specification forward.

--
Sjoerd Simons <sjoerd.s= imons@collabora.co.uk>
Collabora Ltd.
_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload

--001636831fa07a4588049f83906a-- From iesg-secretary@ietf.org Sun Mar 27 22:59:37 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AE9F3A681D; Sun, 27 Mar 2011 22:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tu95IIMRYlYV; Sun, 27 Mar 2011 22:59:35 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68CAD3A6820; Sun, 27 Mar 2011 22:59:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.13 Message-ID: <20110328055934.15797.50345.idtracker@localhost> Date: Sun, 27 Mar 2011 22:59:34 -0700 Cc: payload chair , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP Payload Format for IP-MR Speech Codec' to Proposed Standard (draft-ietf-avt-rtp-ipmr-15.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 05:59:37 -0000 The IESG has approved the following document: - 'RTP Payload Format for IP-MR Speech Codec' (draft-ietf-avt-rtp-ipmr-15.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-ipmr/ Technical Summary This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and introduced redundancy for robustness against packet loss. Working Group Summary This is a reasonably standard RTP payload format. The document has been reviewed by the AVT working group and all open issues were addressed. The payload is for the IP-MR codec and supplies enough information enabling an RTP decoder to pack and unpack the auiod frame information from the RTP payload. Annex A was added as to describe the packetization after the mailing list discussion. Document Quality The codec using this media packetization and media subtype specification is already deployed. Types review was initiated May 26, 2009. Personnel Roni Even is the document shepherd. The responsible area director is Robert Sparks. From sjoerd.simons@collabora.co.uk Mon Mar 28 01:32:58 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98203A690F for ; Mon, 28 Mar 2011 01:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] 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 iaOCQ2v-jEpC for ; Mon, 28 Mar 2011 01:32:58 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.128.226]) by core3.amsl.com (Postfix) with ESMTP id C89DB3A6893 for ; Mon, 28 Mar 2011 01:32:57 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: sjoerd) with ESMTPSA id AA0E16031D4 Received: by night.luon.net (Postfix, from userid 1000) id 1A05D75630; Mon, 28 Mar 2011 09:34:29 +0100 (BST) From: Sjoerd Simons To: Henrik Lundin In-Reply-To: References: <1301238299.19152.4.camel@night> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Organization: Collabora Ltd. Date: Mon, 28 Mar 2011 09:34:28 +0100 Message-ID: <1301301268.4824.4.camel@night> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Cc: payload@ietf.org, patrik.westin@gmail.com Subject: Re: [payload] VP8 RTP specification implemetation notes X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:32:58 -0000 On Mon, 2011-03-28 at 06:42 +0200, Henrik Lundin wrote: > Hi Sjoerd, >=20 > Thanks for notifying us. We will review your comments carefully and > incorporate them in the process.=20 Thanks > Any chance to see you in Prague this week? I won't be in Prague unfortunately.=20 --=20 Sjoerd Simons Collabora Ltd. From Even.roni@huawei.com Mon Mar 28 08:20:01 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46AE93A6820; Mon, 28 Mar 2011 08:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.917 X-Spam-Level: X-Spam-Status: No, score=-100.917 tagged_above=-999 required=5 tests=[AWL=3.577, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 DxlYRwMHCnvf; Mon, 28 Mar 2011 08:19:56 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DDAA73A67D6; Mon, 28 Mar 2011 08:19:45 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIR000AKXB8YU@szxga03-in.huawei.com>; Mon, 28 Mar 2011 23:21:08 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIR007DHXB8TK@szxga03-in.huawei.com>; Mon, 28 Mar 2011 23:21:08 +0800 (CST) Received: from windows8d787f9 (dhcp-1164.meeting.ietf.org [130.129.17.100]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIR00FFOXASMM@szxml12-in.huawei.com>; Mon, 28 Mar 2011 23:21:08 +0800 (CST) Date: Mon, 28 Mar 2011 17:20:32 +0200 From: Roni Even In-reply-to: <003501cbec3f$2d8448d0$888cda70$%roni@huawei.com> To: 'Ye-Kui Wang' , payload@ietf.org, avt@ietf.org Message-id: <001b01cbed5b$b7162600$25427200$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_z1bTfMJCnOpvzTDtOO/49w)" Content-language: en-us Thread-index: Acvm161AAF2A6AC0R/ODLEMZyh1IcgAwzyEAAIkXUFAAnXzNcAACDXKAAEZuowA= References: <003501cbec3f$2d8448d0$888cda70$%roni@huawei.com> Cc: 'Gary Sullivan' , 'Roni Even' Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:20:01 -0000 This is a multi-part message in MIME format. --Boundary_(ID_z1bTfMJCnOpvzTDtOO/49w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT YK, Maybe it will be helpful to add the assumption about 4:2:0 8-bit support in RFC3984 systems to the new 3984bis draft to clarify that you need to support the new parameter if you are using other color schemes Roni From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Sunday, March 27, 2011 7:24 AM To: 'Mo Zanaty (mzanaty)'; 'Ye-Kui Wang'; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan' Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts HI Mo, When the solution was discussed there are two assumptions 1. Old implementations (RFC3984) expecting the maxdpb parameter in kbyes only supported 4:2:0 8-bit and no other color because otherwise using only Kbytes and not macro blocks will not work for them. New implementation(RFC6184 - the assigned RFC number to 3984bis) expects a value in macroblocks and will interpret the value in maxdpb as macroblocks. So see my comments inline Roni Even As individual Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD. BR, YK ------------------------------------Start of suggested changes -------------------------------------- --Boundary_(ID_z1bTfMJCnOpvzTDtOO/49w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

YK,

Maybe it will be helpful to add the assumption about 4:2:0 8-bit support in RFC3984 systems to the new 3984bis draft to clarify that you need to support the new parameter if you are using other color schemes

Roni

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Sunday, March 27, 2011 7:24 AM
To: 'Mo Zanaty (mzanaty)'; 'Ye-Kui Wang'; payload@ietf.org; avt@ietf.org
Cc: 'Gary Sullivan'
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

 

HI Mo,

When the solution was discussed there are two assumptions

        Old implementations (RFC3984) expecting the maxdpb parameter in kbyes only supported 4:2:0 8-bit and no other color because otherwise using only Kbytes and not macro blocks will not work for them. New implementation(RFC6184 – the assigned RFC number to 3984bis) expects a value in macroblocks and will interpret the value in maxdpb as macroblocks.

So see my comments inline

Roni Even

As individual

 

Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD.

 

BR, YK

 

---- -------Start of suggested changes --------------------------------------

--Boundary_(ID_z1bTfMJCnOpvzTDtOO/49w)-- From yekui.wang@huawei.com Mon Mar 28 12:01:27 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4CEB3A691D; Mon, 28 Mar 2011 12:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0mZ1YVjii8ZB; Mon, 28 Mar 2011 12:01:22 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id BB9F43A6A6B; Mon, 28 Mar 2011 12:01:06 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIS00G6Y7KIG2@usaga02-in.huawei.com>; Mon, 28 Mar 2011 12:02:43 -0700 (PDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIS00LJH7KIND@usaga02-in.huawei.com>; Mon, 28 Mar 2011 12:02:42 -0700 (PDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 28 Mar 2011 12:02:40 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.54]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Mon, 28 Mar 2011 12:02:40 -0700 Date: Mon, 28 Mar 2011 19:02:40 +0000 From: Ye-Kui Wang In-reply-to: <001b01cbed5b$b7162600$25427200$%roni@huawei.com> X-Originating-IP: [10.193.125.214] To: Roni Even , "payload@ietf.org" , "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wtkyw5gZZqpWBpUp+0gzEA)" Content-language: en-US Accept-Language: en-US Thread-topic: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-index: AQHL7Xq13hWH9Vft5kKbNdH/qp/OIg== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <003501cbec3f$2d8448d0$888cda70$%roni@huawei.com> <001b01cbed5b$b7162600$25427200$%roni@huawei.com> Cc: 'Gary Sullivan' Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 19:01:27 -0000 --Boundary_(ID_wtkyw5gZZqpWBpUp+0gzEA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Roni, Yes, we can add some notes to clarify the reason for the changes and that the changes are backward compatible to RFC 3984. If people feel that other notes would be helpful too, please propose, I think we are open to all such additions as long as they would be helpful for readers and implementers. BR, YK From: Roni Even [mailto:even.roni@huawei.com] Sent: Monday, March 28, 2011 11:21 AM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan'; 'Roni Even'; 'Mo Zanaty (mzanaty)' Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts YK, Maybe it will be helpful to add the assumption about 4:2:0 8-bit support in RFC3984 systems to the new 3984bis draft to clarify that you need to support the new parameter if you are using other color schemes Roni From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Sunday, March 27, 2011 7:24 AM To: 'Mo Zanaty (mzanaty)'; 'Ye-Kui Wang'; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan' Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts HI Mo, When the solution was discussed there are two assumptions 1. Old implementations (RFC3984) expecting the maxdpb parameter in kbyes only supported 4:2:0 8-bit and no other color because otherwise using only Kbytes and not macro blocks will not work for them. New implementation(RFC6184 - the assigned RFC number to 3984bis) expects a value in macroblocks and will interpret the value in maxdpb as macroblocks. So see my comments inline Roni Even As individual Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD. BR, YK ------------------------------------Start of suggested changes -------------------------------------- --Boundary_(ID_wtkyw5gZZqpWBpUp+0gzEA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Roni,

 

Yes, we can add some notes to clarify the reason for the changes and that the changes are backward compatible to RFC 3984. If people feel that other notes would be helpful too, please propose, I think we are open to all such additions as long as they would be helpful for readers and implementers.

 

BR, YK

 

From: Roni Even [mailto:even.roni@huawei.com]
Sent: Monday, March 28, 2011 11:21 AM
To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org
Cc: 'Gary Sullivan'; 'Roni Even'; 'Mo Zanaty (mzanaty)'
Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

 

YK,

Maybe it will be helpful to add the assumption about 4:2:0 8-bit support in RFC3984 systems to the new 3984bis draft to clarify that you need to support the new parameter if you are using other color schemes

Roni

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even
Sent: Sunday, March 27, 2011 7:24 AM
To: 'Mo Zanaty (mzanaty)'; 'Ye-Kui Wang'; payload@ietf.org; avt@ietf.org
Cc: 'Gary Sullivan'
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

 

HI Mo,

When the solution was discussed there are two assumptions

1.        Old implementations (RFC3984) expecting the maxdpb parameter in kbyes only supported 4:2:0 8-bit and no other color because otherwise using only Kbytes and not macro blocks will not work for them. New implementation(RFC6184 – the assigned RFC number to 3984bis) expects a value in macroblocks and will interpret the value in maxdpb as macroblocks.

So see my comments inline

Roni Even

As individual

 

Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD.

 

BR, YK

 

------------------------------------Start of suggested changes --------------------------------------

--Boundary_(ID_wtkyw5gZZqpWBpUp+0gzEA)-- From Even.roni@huawei.com Wed Mar 30 00:31:59 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1653F3A6B21 for ; Wed, 30 Mar 2011 00:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.302 X-Spam-Level: X-Spam-Status: No, score=-101.302 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 k0VxqwUpqysB for ; Wed, 30 Mar 2011 00:31:58 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0BE0E3A6B20 for ; Wed, 30 Mar 2011 00:31:58 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV0091H0ZQ3V@szxga05-in.huawei.com> for payload@ietf.org; Wed, 30 Mar 2011 15:33:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIV00F3R0ZNO1@szxga05-in.huawei.com> for payload@ietf.org; Wed, 30 Mar 2011 15:33:26 +0800 (CST) Received: from windows8d787f9 (dhcp-44e0.meeting.ietf.org [130.129.68.224]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIV00AB30Z9SC@szxml12-in.huawei.com>; Wed, 30 Mar 2011 15:33:22 +0800 (CST) Date: Wed, 30 Mar 2011 09:32:47 +0200 From: Roni Even To: payload@ietf.org Message-id: <009d01cbeeac$b1776a90$14663fb0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rw7ndh24FGIDlFtIE075mA)" Content-language: en-us Thread-index: AcvurKqfJ4F/QjK6SnSc2t/tNaoDZw== Subject: [payload] Call for adoption of RRP payload format to VP8 document X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 07:31:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_rw7ndh24FGIDlFtIE075mA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Payload WG has a milestone for August 2011 for RTP Payload Format for VP8 Video for Proposed Standard There is an individual draft titled Proposal for the IETF on "RTP Payload Format for VP8 Video" http://tools.ietf.org/html/draft-westin-payload-vp8-02 Based on the feedback in the AVTcore session in Prague this is a WG call to adopt the above text as baseline text for this milestone. This is an initial text and can be updated based on feedback once it is a WG document. Please respond by Thursday April 14th 2011 with your positions. Roni Even PAYLOAD WG co-chair --Boundary_(ID_rw7ndh24FGIDlFtIE075mA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

Payload WG =
has a milestone for August =
2011 for RTP Payload Format for VP8 Video for Proposed =
Standard

 =

 = 

There is =
an individual draft titled Proposal =
for the IETF on "RTP Payload Format for VP8 Video"  =
; http://to=
ols.ietf.org/html/draft-westin-payload-vp8-02  =

 =

Based on = the feedback in the AVTcore session in Prague this is a WG call  to = adopt the above text as baseline text for this milestone. This is an = initial text and can be updated based on feedback once it is a WG = document.

 =

Please = respond by Thursday April 14th  2011 with your = positions.

 

Roni = Even

PAYLOAD WG = co-chair

 

 

= --Boundary_(ID_rw7ndh24FGIDlFtIE075mA)-- From yekui.wang@huawei.com Thu Mar 31 14:40:12 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC37B28C10C; Thu, 31 Mar 2011 14:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GxIAVVYMgr+6; Thu, 31 Mar 2011 14:39:58 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id C79C828C0EC; Thu, 31 Mar 2011 14:39:57 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIX007IRYXCDN@usaga04-in.huawei.com>; Thu, 31 Mar 2011 16:41:36 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LIX0010IYXB1V@usaga04-in.huawei.com>; Thu, 31 Mar 2011 16:41:35 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 31 Mar 2011 14:41:31 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.54]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Thu, 31 Mar 2011 14:41:31 -0700 Date: Thu, 31 Mar 2011 21:41:31 +0000 From: Ye-Kui Wang In-reply-to: X-Originating-IP: [10.193.125.214] To: Roni Even , "payload@ietf.org" , "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_C9ZhrGt7eeZHLEePb0bSNA)" Content-language: en-US Accept-Language: en-US Thread-topic: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-index: AQHL7Xq13hWH9Vft5kKbNdH/qp/OIpRIcyxQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <003501cbec3f$2d8448d0$888cda70$%roni@huawei.com> <001b01cbed5b$b7162600$25427200$%roni@huawei.com> X-Mailman-Approved-At: Thu, 31 Mar 2011 14:53:41 -0700 Cc: 'Gary Sullivan' Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 21:40:12 -0000 --Boundary_(ID_C9ZhrGt7eeZHLEePb0bSNA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Please find below the suggested changes for RFC3984bis with some informative notes added to the semantics of max-cpb, max-dpb, and max-cr. The added notes are all highlighted in yellow. There are no other additional changes besides the addition of these notes (compared to the previous post). These additions should address the specific concerns expressed so far. I hope we can close the issue and let the RFC publication process to proceed. As I said earlier, the changes to the SVC and RCDO payload drafts are very similar. However, please let the authors know if you would like those changes to be seen also on the PAYLOAD and AVTCORE mailing lists. ------------------------------------Start of suggested changes -------------------------------------- Section 8.1: OLD: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_4bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. NEW: (note that the change here is purely editorial) profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. OLD: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. For example, a decoder conforming to the High 4:4:4 profile, at a certain level, must be able to decode bitstreams conforming to the Constrained Baseline, Main, High, High 10, or High 4:2:2 profile at the same or a lower level. NEW: (note that the change here is purely editorial) For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. OLD: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. NEW: (note that the change here is purely editorial) If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. OLD: max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: (note that the change here is purely editorial) max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters and in units of 1200 bits for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 in [1]). OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. NEW: (The nature of this change as follows. If the semantics remain unchanged while the reference to H.264 spec is the 2010 version, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the 2010 H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change hence there is no backward compatibility issue.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. Informative note: In RFC 3984, which this document obsoletes, the unit of this parameter was 1024 bytes. The unit has been changed to 8/3 macroblocks in this document. This reason for this change was due to the changes from the 2003 version of the H.264 specification referenced by RFC 3984 to the 2010 version of the H.264 specification referenced by this document, particularly the changes to Table A-1 in the H.264 specification due to addition of color formats and bit depths not supported earlier. The changed semantics of this parameter keeps backward compatibility to RFC 3984 and supports all profiles defined in the 2010 version of the H.264 specification. OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). ... For example, if a receiver signals capability for Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). NEW: (note that the change here is purely editorial) max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters and in units of 1200 bits per second for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and cpbBrNALFactor (see Table A-1 in [1]). ... For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). ------------------------------------End of suggested changes -------------------------------------- Best Regards, Ye-Kui Wang From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Monday, March 28, 2011 3:03 PM To: Roni Even; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan' Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts Hi Roni, Yes, we can add some notes to clarify the reason for the changes and that the changes are backward compatible to RFC 3984. If people feel that other notes would be helpful too, please propose, I think we are open to all such additions as long as they would be helpful for readers and implementers. BR, YK From: Roni Even [mailto:even.roni@huawei.com] Sent: Monday, March 28, 2011 11:21 AM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan'; 'Roni Even'; 'Mo Zanaty (mzanaty)' Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts YK, Maybe it will be helpful to add the assumption about 4:2:0 8-bit support in RFC3984 systems to the new 3984bis draft to clarify that you need to support the new parameter if you are using other color schemes Roni From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Sunday, March 27, 2011 7:24 AM To: 'Mo Zanaty (mzanaty)'; 'Ye-Kui Wang'; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan' Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts HI Mo, When the solution was discussed there are two assumptions 1. Old implementations (RFC3984) expecting the maxdpb parameter in kbyes only supported 4:2:0 8-bit and no other color because otherwise using only Kbytes and not macro blocks will not work for them. New implementation(RFC6184 - the assigned RFC number to 3984bis) expects a value in macroblocks and will interpret the value in maxdpb as macroblocks. So see my comments inline Roni Even As individual Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD. BR, YK ------------------------------------Start of suggested changes -------------------------------------- --Boundary_(ID_C9ZhrGt7eeZHLEePb0bSNA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Please = find below the suggested changes for RFC3984bis with some informative notes= added to the semantics of max-cpb, max-dpb, and max-cr. The added notes ar= e all highlighted in yellow. There are no other additional changes besides the addition of these notes (compared = to the previous post). These additions should address the specific concerns= expressed so far. I hope we can close the issue and let the RFC publicatio= n process to proceed.

&n= bsp;

As I sa= id earlier, the changes to the SVC and RCDO payload drafts are very similar= . However, please let the authors know if you would like those changes to b= e seen also on the PAYLOAD and AVTCORE mailing lists.

&n= bsp;

----------------------------= --------Start of suggested changes --------------------------------------

 

Section= 8.1:

OLD:

      profile-level-id:<=
o:p>
         =
A base16 [7] (hexadecimal) representation of the following
         =
three bytes in the sequence parameter set NAL unit is specified<=
/span>
         =
in [1]: 1) profile_idc, 2) a byte herein referred to as

         =
profile-iop, composed of the values of constraint_set0_flag,


         =
constraint_set1_flag,constraint_set2_flag,


         =
constraint_set3_flag, and reserved_zero_4bits in bit-

         =
significance order, starting from the most-significant bit, and<=
/span>


         =
3) level_idc.  Note that reserved_zero_4bits is required to be


         =
equal to 0 in [1], but other values for it may be specified in


         =
the future by ITU-T or ISO/IEC.


 N=
EW: 
(note that the change here is purely editorial)

   =
   profile-level-id:


   =
      A base16 [7] (hexadecimal) representation of=
 the following


   =
      three bytes in the sequence parameter set NA=
L unit is specified


   =
      in [1]: 1) profile_idc, 2) a byte herein ref=
erred to as


   =
      profile-iop, composed of the values of const=
raint_set0_flag,


   =
      constraint_set1_flag,constraint_set2_flag,


   =
      constraint_set3_flag,
constraint_set4_flag=
, constraint_set5_flag,


 and reserved_zero_2bits
 in bit-significance order, starting from the most-significant bit, and


   =
      3) level_idc.  Note that reserved_zero_=
2bits is required to be


   =
      equal to 0 in [1], but other values for it m=
ay be specified in


   =
      the future by ITU-T or ISO/IEC.


&n=
bsp;


OLD:


         =
For example, in the table above, profile_idc equal to 58<=
/pre>

         =
(Extended) with profile-iop equal to 11xx0000 indicates the


         =
same sub-profile corresponding to profile_idc equal to 42=



         =
(Baseline) with profile-iop equal to x1xx0000.  Note that other


         =
combinations of profile_idc and profile-iop (not listed in


         =
Table 5) may represent a sub-profile equivalent to the common


         =
subset of coding tools for more than one profile.  Note also


         =
that a decoder conforming to a certain profile may be able to


         =
decode bitstreams conforming to other profiles.  For example, a


 =
        decoder conforming to the High 4=
:4:4 profile, at a certain


 =
        level, must be able to decode bi=
tstreams conforming to the


 =
        Constrained Baseline, Main, High=
, High 10, or High 4:2:2


 =
        profile at the same or a lower l=
evel.


 N=
EW: 
(note that the change here is purely editorial)

   =
      For example, in the table above, profile_idc=
 equal to 58


   =
      (Extended) with profile-iop equal to 11xx000=
0 indicates the


   =
      same sub-profile corresponding to profile_id=
c equal to 42


   =
      (Baseline) with profile-iop equal to x1xx000=
0.  Note that other


   =
      combinations of profile_idc and profile-iop =
(not listed in


   =
      Table 5) may represent a sub-profile equival=
ent to the common


   =
      subset of coding tools for more than one pro=
file.  Note also


   =
      that a decoder conforming to a certain profi=
le may be able to


   =
      decode bitstreams conforming to other profil=
es.


 <=
/span>


OLD:


         =
If the profile-level-id parameter is used for capability<=
/pre>

         =
exchange or session setup =
procedure, it indicates the subset of


         =
coding tools, which is equal to the default sub-profile, that


         =
the codec supports for both receiving and sending.


 N=
EW: 
(note that the change here is purely editorial)

   =
      If the profile-level-id parameter is used fo=
r capability


   =
      exchange or session setup, it indicates the =
subset of


   =
      coding tools, which is equal to the default =
sub-profile, that


   =
      the codec supports for both receiving and se=
nding.


&n=
bsp;


OLD: 


   =
   max-cpb: The value of max-cpb is an integer indicating the max=
imum


   =
      coded picture buffer size in units of 1000 b=
its for the VCL HRD


   =
      parameters
(see A.3.1, item i of [1])=
 and in units of 1200 bits


   =
      for the NAL HRD parameters
(see A.3.1, item j of [1])=
.


NEW: 
(note that the change here is purely editorial)

   =
   max-cpb: The value of max-cpb is an integer indicating the max=
imum


   =
      coded picture buffer size in units of 1000 b=
its for the VCL HRD


   =
      parameters and in units of 1200 bits for the=
 NAL HRD parameters.


         Note that this parameter does not use units of cpbBrV=
clFactor and



cpbBrNALFactor (see Table A-1 in [1]).


 <=
/span>


OLD:


   =
   max-dpb: The value of max-dpb is an integer indicating the max=
imum


   =
      decoded picture buffer size in units of 1024=
 bytes.  The max-


   =
      dpb parameter signals that the receiver has =
more memory than


   =
      the minimum amount of decoded picture buffer=
 memory required by


   =
      the signaled highest level conveyed in the v=
alue of the


   =
      profile-level-id parameter or the max-recv-l=
evel parameter.


   =
      When max-dpb is signaled, the receiver MUST =
be able to decode


   =
      NAL unit streams that conform to the signale=
d highest level,


   =
      with the exception that the MaxDPB value in =
Table A-1 of [1]


   =
      for the signaled highest level is replaced w=
ith the value of


   =
      max-dpb.  Consequently, a receiver that=
 signals max-dpb MUST be


   =
      capable of storing the following number of d=
ecoded frames,


   =
      complementary field pairs, and non-paired fi=
elds in its decoded


   =
      picture buffer:


 <=
/span>


   =
         Min(1024 * max-dpb / ( Pic=
WidthInMbs * FrameHeightInMbs *


   =
         256 * ChromaFormatFactor )=
, 16)


 <=
/span>


   =
      PicWidthInMbs, FrameHeightInMbs, and ChromaF=
ormatFactor are


    =
;     defined in [1].


 <=
/span>


   =
      The value of max-dpb MUST be greater than or=
 equal to the value


   =
      of MaxDPB given in Table A-1 of [1] for the =
highest level.


   =
      Senders MAY use this knowledge to construct =
coded video streams


   =
      with improved compression.=



 <=
/span>


   =
         Informative note: This par=
ameter was added primarily to


   =
         complement a similar codep=
oint in the ITU-T Recommendation


   =
         H.245, so as to facilitate=
 signaling gateway designs.  The


   =
         decoded picture buffer sto=
res reconstructed samples.  There


   =
         is no relationship between=
 the size of the decoded picture



 &n=
bsp;          buffer and the b=
uffers used in RTP, especially de-interleaving

 and de-jitter buffers.


 <=
/span>


NEW: 
(The nature of this change as follows. If the semantics remain unchanged wh=
ile the reference to H.264 spec  is the 2010 version, then the semanti=
cs of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaForm=
atFactor are not found in the 2010 H.264
 spec any more. Note that compared to RFC 3984, the bits on the wire do not=
 change hence there is no backward compatibility issue.)<=
/span>


   =
   max-dpb: The value of max-dpb is an integer indicating the max=
imum


   =
      decoded picture buffer size in units of
8/3 macroblocks.  The max-


   =
      dpb parameter signals that the receiver has =
more memory than


   =
      the minimum amount of decoded picture buffer=
 memory required by


   =
      the signaled highest level conveyed in the v=
alue of the


   =
      profile-level-id parameter or the max-recv-l=
evel parameter.


   =
      When max-dpb is signaled, the receiver MUST =
be able to decode


   =
      NAL unit streams that conform to the signale=
d highest level,


   =
      with the exception that
the MaxDpbMbs value =
in Table A-1 of [1]


         for the signaled h=
ighest level is replaced with the value of


         max-dpb * 3 / 8.&nb=
sp;
 Consequently, a receiver that signals max-dpb MUST be

   =
      capable of storing the following number of d=
ecoded frames,


   =
      complementary field pairs, and non-paired fi=
elds in its decoded


   =
      picture buffer:


 <=
/span>


   =
        
Min(max-dpb * 3 / 8 =
/ ( PicWidthInMbs * FrameHeightInMbs), 16)


 


         Wherein PicWidthIn=
Mbs and FrameHeightInMbs are defined in [1].


 <=
/span>


   =
      The value of max-dpb MUST be greater than or=
 equal to the value


   =
      of
MaxDpbMbs * 3 / 8, w=
herein the value of MaxDpbMbs is given in



Table A-1 of [1] for the highest level.


   =
      Senders MAY use this knowledge to construct =
coded video streams


   =
      with improved compression.=



 <=
/span>


   =
         Informative note: This par=
ameter was added primarily to


   =
         complement a similar codep=
oint in the ITU-T Recommendation


   =
         H.245, so as to facilitate=
 signaling gateway designs.  The


   =
         decoded picture buffer sto=
res reconstructed samples.  There


   =
         is no relationship between=
 the size of the decoded picture



 &n=
bsp;          buffer and the b=
uffers used in RTP, especially de-interleaving

 and de-jitter buffers.


 <=
/span>


   =
        
Informative note: In=
 RFC 3984, which this document obsoletes,



            =
the unit of this parameter was 1024 bytes.  The unit has been



            =
changed to 8/3 macroblocks in this document.  This reason for


            =
this change was due to the changes from the 2003 version of the<=
/span>


            =
H.264 specification referenced by RFC 3984 to the 2010 version


            =
of the H.264 specification referenced by this document, particularly


            =
the changes to Table A-1 in the H.264 specification due to addition



            =
of color formats and bit depths not supported earlier.  The



            =
changed semantics of this parameter keeps backward



            =
compatibility to RFC 3984 and supports all profiles defined in



            =
the 2010 version of the H.264 specification.


 <=
/span>


OLD:


      max-br: The value =
of max-br is an integer indicating the maximum


         =
video bitrate in units of 1000 bits per second for the VCL HRD


         =
parameters (see A.3.1, ite=
m i of [1]) and in units of 1200 bits


         =
per second for the NAL HRD parameters (see A.3.1, item j of


         =
[1]).


         =
…


   =
      For example, if a receiver signals capabilit=
y for Level 1.2


   =
      with max-br equal to 1550, this indicates a =
maximum video


   =
      bitrate of 1550 kbits/sec for VCL HRD parame=
ters, a maximum


   =
      video bitrate of 1860 kbits/sec for NAL HRD =
parameters, and a


    =
;     CPB size of 4036458 bits (1550000 / 384000 *=
 1000 * 1000).


NEW: 
(note that the change here is purely editorial) 

      max-br: The value =
of max-br is an integer indicating the maximum


         =
video bitrate in units of 1000 bits per second for the VCL HRD


         =
parameters and in units of 1200 bits per second for the NAL HRD parameters.=



   =
     
Note that this param=
eter does not use units of cpbBrVclFactor and



cpbBrNALFactor (see Table A-1 in [1]).


         =
…


   =
      For example, if a receiver signals capabilit=
y for
Main profile Level 1.2


   =
      with max-br equal to 1550, this indicates a =
maximum video


   =
      bitrate of 1550 kbits/sec for VCL HRD parame=
ters, a maximum


   =
      video bitrate of 1860 kbits/sec for NAL HRD =
parameters, and a


    =
;     CPB size of 4036458 bits (1550000 / 384000 *=
 1000 * 1000).


&n=
bsp;


----------------------------=
--------End of suggested changes --------------------------------------


&n=
bsp;


Best Re=
gards,


Ye-Kui =
Wang


&n=
bsp;


&n=
bsp;






From: avt-bounces@=
ietf.org [mailto:avt-bounces@ietf.org]
On Behalf Of Ye-Kui Wang

Sent: Monday, March 28, 2011 3:03 PM

To: Roni Even; payload@ietf.org; avt@ietf.org

Cc: 'Gary Sullivan'

Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, an=
d RCDO payload drafts






 


Hi Roni=
,


&n=
bsp;


Yes, we=
 can add some notes to clarify the reason for the changes and that the chan=
ges are backward compatible to RFC 3984. If people feel that other notes wo=
uld be helpful too, please propose, I
 think we are open to all such additions as long as they would be helpful f=
or readers and implementers.



&n=
bsp;


BR, YK<=
o:p>


&n=
bsp;






From: Roni Even [m=
ailto:even.roni@huawei.com]


Sent: Monday, March 28, 2011 11:21 AM

To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org

Cc: 'Gary Sullivan'; 'Roni Even'; 'Mo Zanaty (mzanaty)'

Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, an=
d RCDO payload drafts






 


YK,


Maybe it will be helpful to add the assumption about 4:2:0 8-bit =
support in RFC3984 systems to the new 3984bis draft to clarify that you nee=
d to support the new parameter if you
 are using other color schemes


Roni


 








From: avt-bounces@=
ietf.org [mailto:avt-bounces@ietf.org]
On Behalf Of Roni Even

Sent: Sunday, March 27, 2011 7:24 AM

To: 'Mo Zanaty (mzanaty)'; 'Ye-Kui Wang'; payload@ietf.org; avt@ietf=
.org

Cc: 'Gary Sullivan'

Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, an=
d RCDO payload drafts






 


HI Mo,


When the solution was discussed there are two assumptions


1.      
 Old implementations (RFC3984) expecting the maxdpb =
parameter in kbyes only supported 4:2:0 8-bit and no other color because ot=
herwise using only Kbytes and not macro blocks
 will not work for them. New implementation(RFC6184 – the assigned RF=
C number to 3984bis) expects a value in macroblocks and will interpret the =
value in maxdpb as macroblocks.


So see my comments inline


Roni Even


As individual


 






Further discussions with the same group =
of persons led to a decision to stay with the unscaled units for
 max-br and max-cpb, thus fewer changes are needed to the three payload for=
mats listed in the title and H.241. With this, the changes needed are liste=
d below (the originally suggested changes are dropped from this email). Thi=
s time I have highlighted the changes,
 and I have also described the nature the changes below. Hope these may hel=
p understand better what have been changed, and can lead to a quicker decis=
ion by the group, including WG chairs, and our AD.


 


BR, =
YK


 


----------------------------=
--------Start of suggested changes --------------------------------------
--Boundary_(ID_C9ZhrGt7eeZHLEePb0bSNA)-- From mzanaty@cisco.com Thu Mar 31 18:54:25 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015613A6AD2; Thu, 31 Mar 2011 18:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 FH0RyFiXr4Cn; Thu, 31 Mar 2011 18:54:11 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9AEA63A6AAE; Thu, 31 Mar 2011 18:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mzanaty@cisco.com; l=78363; q=dns/txt; s=iport; t=1301622951; x=1302832551; h=mime-version:subject:date:message-id:from:to:cc; bh=QpZxebCsuBQMXR0EmgMR5wtXA1v+Zfxdlk8FwYpc2LE=; b=LPBU64JsSo8m59ehLxND4xsagFeHn/GZzQ6dXqTxSdNDXqEM5GRqkuAa ZzGoak3Fxq407oNSaGPIANvMYoCB47MrpSaxvSJLqe3BwN4aV9FiThRBb 6NA0WR1m9dUTqcwfmNQ7FAMBkqAhr3WAFzzS/swKVrGwnxLmKHROUXMW2 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAEswlU2tJV2b/2dsb2JhbACCXpU+jT53pQCcPoVrBIVCizI X-IronPort-AV: E=Sophos;i="4.63,280,1299456000"; d="scan'208,217";a="287016563" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2011 01:55:50 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p311to9w010904; Fri, 1 Apr 2011 01:55:50 GMT Received: from xmb-rcd-201.cisco.com ([72.163.62.208]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 20:55:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBF00F.ECDFF27B" Date: Thu, 31 Mar 2011 20:55:48 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts Thread-Index: AQHL7Xq13hWH9Vft5kKbNdH/qp/OIpRIcyxQ///PMBA= From: "Mo Zanaty (mzanaty)" To: "Ye-Kui Wang" , "Roni Even" , , X-OriginalArrivalTime: 01 Apr 2011 01:55:50.0180 (UTC) FILETIME=[ED038E40:01CBF00F] X-Mailman-Approved-At: Thu, 31 Mar 2011 21:54:51 -0700 Cc: Gary Sullivan Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 01:54:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBF00F.ECDFF27B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support these proposed changes. =20 Best regards, Mo Zanaty =20 From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Thursday, March 31, 2011 5:42 PM To: Roni Even; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan' Subject: Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts =20 Please find below the suggested changes for RFC3984bis with some informative notes added to the semantics of max-cpb, max-dpb, and max-cr. The added notes are all highlighted in yellow. There are no other additional changes besides the addition of these notes (compared to the previous post). These additions should address the specific concerns expressed so far. I hope we can close the issue and let the RFC publication process to proceed.=20 =20 As I said earlier, the changes to the SVC and RCDO payload drafts are very similar. However, please let the authors know if you would like those changes to be seen also on the PAYLOAD and AVTCORE mailing lists. =20 ------------------------------------Start of suggested changes -------------------------------------- =20 Section 8.1: OLD: profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, and reserved_zero_4bits in bit- significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_4bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. NEW: (note that the change here is purely editorial) profile-level-id: A base16 [7] (hexadecimal) representation of the following three bytes in the sequence parameter set NAL unit is specified in [1]: 1) profile_idc, 2) a byte herein referred to as profile-iop, composed of the values of constraint_set0_flag, constraint_set1_flag,constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag, and reserved_zero_2bits in bit-significance order, starting from the most-significant bit, and 3) level_idc. Note that reserved_zero_2bits is required to be equal to 0 in [1], but other values for it may be specified in the future by ITU-T or ISO/IEC. =20 OLD: For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. For example, a decoder conforming to the High 4:4:4 profile, at a certain level, must be able to decode bitstreams conforming to the Constrained Baseline, Main, High, High 10, or High 4:2:2 profile at the same or a lower level. NEW: (note that the change here is purely editorial) For example, in the table above, profile_idc equal to 58 (Extended) with profile-iop equal to 11xx0000 indicates the same sub-profile corresponding to profile_idc equal to 42 (Baseline) with profile-iop equal to x1xx0000. Note that other combinations of profile_idc and profile-iop (not listed in Table 5) may represent a sub-profile equivalent to the common subset of coding tools for more than one profile. Note also that a decoder conforming to a certain profile may be able to decode bitstreams conforming to other profiles. =20 OLD: If the profile-level-id parameter is used for capability exchange or session setup procedure, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. NEW: (note that the change here is purely editorial) If the profile-level-id parameter is used for capability exchange or session setup, it indicates the subset of coding tools, which is equal to the default sub-profile, that the codec supports for both receiving and sending. =20 OLD:=20 max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits for the NAL HRD parameters (see A.3.1, item j of [1]). NEW: (note that the change here is purely editorial) max-cpb: The value of max-cpb is an integer indicating the maximum coded picture buffer size in units of 1000 bits for the VCL HRD parameters and in units of 1200 bits for the NAL HRD parameters.=20 Note that this parameter does not use units of cpbBrVclFactor and=20 cpbBrNALFactor (see Table A-1 in [1]). =20 OLD: max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 1024 bytes. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDPB value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: =20 Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ), 16) =20 PicWidthInMbs, FrameHeightInMbs, and ChromaFormatFactor are defined in [1]. =20 The value of max-dpb MUST be greater than or equal to the value of MaxDPB given in Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. =20 Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. =20 NEW: (The nature of this change as follows. If the semantics remain unchanged while the reference to H.264 spec is the 2010 version, then the semantics of max-dpb is simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are not found in the 2010 H.264 spec any more. Note that compared to RFC 3984, the bits on the wire do not change hence there is no backward compatibility issue.) max-dpb: The value of max-dpb is an integer indicating the maximum decoded picture buffer size in units of 8/3 macroblocks. The max- dpb parameter signals that the receiver has more memory than the minimum amount of decoded picture buffer memory required by the signaled highest level conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: =20 Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16) =20 Wherein PicWidthInMbs and FrameHeightInMbs are defined in [1]. =20 The value of max-dpb MUST be greater than or equal to the value of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is given in=20 Table A-1 of [1] for the highest level. Senders MAY use this knowledge to construct coded video streams with improved compression. =20 Informative note: This parameter was added primarily to complement a similar codepoint in the ITU-T Recommendation H.245, so as to facilitate signaling gateway designs. The decoded picture buffer stores reconstructed samples. There is no relationship between the size of the decoded picture buffer and the buffers used in RTP, especially de-interleaving and de-jitter buffers. =20 Informative note: In RFC 3984, which this document obsoletes,=20 the unit of this parameter was 1024 bytes. The unit has been=20 changed to 8/3 macroblocks in this document. This reason for this change was due to the changes from the 2003 version of the H.264 specification referenced by RFC 3984 to the 2010 version of the H.264 specification referenced by this document, particularly the changes to Table A-1 in the H.264 specification due to addition=20 of color formats and bit depths not supported earlier. The=20 changed semantics of this parameter keeps backward=20 compatibility to RFC 3984 and supports all profiles defined in=20 the 2010 version of the H.264 specification. =20 OLD: max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters (see A.3.1, item i of [1]) and in units of 1200 bits per second for the NAL HRD parameters (see A.3.1, item j of [1]). ... For example, if a receiver signals capability for Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). NEW: (note that the change here is purely editorial)=20 max-br: The value of max-br is an integer indicating the maximum video bitrate in units of 1000 bits per second for the VCL HRD parameters and in units of 1200 bits per second for the NAL HRD parameters. Note that this parameter does not use units of cpbBrVclFactor and=20 cpbBrNALFactor (see Table A-1 in [1]). ... For example, if a receiver signals capability for Main profile Level 1.2 with max-br equal to 1550, this indicates a maximum video bitrate of 1550 kbits/sec for VCL HRD parameters, a maximum video bitrate of 1860 kbits/sec for NAL HRD parameters, and a CPB size of 4036458 bits (1550000 / 384000 * 1000 * 1000). =20 ------------------------------------End of suggested changes -------------------------------------- =20 Best Regards, Ye-Kui Wang =20 =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ye-Kui Wang Sent: Monday, March 28, 2011 3:03 PM To: Roni Even; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan' Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts =20 Hi Roni, =20 Yes, we can add some notes to clarify the reason for the changes and that the changes are backward compatible to RFC 3984. If people feel that other notes would be helpful too, please propose, I think we are open to all such additions as long as they would be helpful for readers and implementers.=20 =20 BR, YK =20 From: Roni Even [mailto:even.roni@huawei.com]=20 Sent: Monday, March 28, 2011 11:21 AM To: Ye-Kui Wang; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan'; 'Roni Even'; 'Mo Zanaty (mzanaty)' Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts =20 YK, Maybe it will be helpful to add the assumption about 4:2:0 8-bit support in RFC3984 systems to the new 3984bis draft to clarify that you need to support the new parameter if you are using other color schemes Roni =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Roni Even Sent: Sunday, March 27, 2011 7:24 AM To: 'Mo Zanaty (mzanaty)'; 'Ye-Kui Wang'; payload@ietf.org; avt@ietf.org Cc: 'Gary Sullivan' Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts =20 HI Mo, When the solution was discussed there are two assumptions 1. Old implementations (RFC3984) expecting the maxdpb parameter in kbyes only supported 4:2:0 8-bit and no other color because otherwise using only Kbytes and not macro blocks will not work for them. New implementation(RFC6184 - the assigned RFC number to 3984bis) expects a value in macroblocks and will interpret the value in maxdpb as macroblocks. So see my comments inline Roni Even As individual =20 Further discussions with the same group of persons led to a decision to stay with the unscaled units for max-br and max-cpb, thus fewer changes are needed to the three payload formats listed in the title and H.241. With this, the changes needed are listed below (the originally suggested changes are dropped from this email). This time I have highlighted the changes, and I have also described the nature the changes below. Hope these may help understand better what have been changed, and can lead to a quicker decision by the group, including WG chairs, and our AD. =20 BR, YK =20 ------------------------------------Start of suggested changes -------------------------------------- ------_=_NextPart_001_01CBF00F.ECDFF27B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support these proposed = changes.

 

Best = regards,

Mo Zanaty

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Ye-Kui Wang
Sent: Thursday, March 31, 2011 5:42 = PM
To: Roni Even; payload@ietf.org; avt@ietf.org
Cc: = 'Gary Sullivan'
Subject: Re: [payload] [AVTCORE] Some changes = to rfc3984bis, SVC, and RCDO payload = drafts

 

Please find below the = suggested changes for RFC3984bis with some informative notes added to = the semantics of max-cpb, max-dpb, and max-cr. The added notes are all = highlighted in yellow. There are no other additional changes besides the = addition of these notes (compared to the previous post). These additions = should address the specific concerns expressed so far. I hope we can = close the issue and let the RFC publication process to proceed. =

 

As I said earlier, = the changes to the SVC and RCDO payload drafts are very similar. = However, please let the authors know if you would like those changes to = be seen also on the PAYLOAD and AVTCORE mailing = lists.

 

------------------------------------= Start of suggested changes = --------------------------------------

 

Section = 8.1:

OLD:= 

      =
profile-level-id:
      =
   A base16 [7] (hexadecimal) representation of the =
following
      =
   three bytes in the sequence parameter set NAL unit is =
specified
      =
   in [1]: 1) profile_idc, 2) a byte herein referred to =
as
      =
   profile-iop, composed of the values of =
constraint_set0_flag,
      =
   =
constraint_set1_flag,constraint_set2_flag,
      =
   constraint_set3_flag, and reserved_zero_4bits in =
bit-
      =
   significance order, starting from the most-significant bit, =
and
      =
   3) level_idc.  Note that reserved_zero_4bits is =
required to be
      =
   equal to 0 in [1], but other values for it may be specified =
in
      =
   the future by ITU-T or ISO/IEC.

 NEW: (note that the change here = is purely editorial)

=       profile-level-id:

=          A base16 [7] = (hexadecimal) representation of the following

=          three bytes in the = sequence parameter set NAL unit is specified

=          in [1]: 1) profile_idc, = 2) a byte herein referred to as

=          profile-iop, composed = of the values of constraint_set0_flag,

=          = constraint_set1_flag,constraint_set2_flag,

=          constraint_set3_flag, = constraint_set4_flag, = constraint_set5_flag,

 and = reserved_zero_2bits= in bit-significance order, starting from the most-significant bit, = and

=          3) level_idc.  = Note that reserved_zero_2bits is required to be

=          equal to 0 in [1], but = other values for it may be specified in

=          the future by ITU-T or = ISO/IEC.

 

OLD:= 

      =
   For example, in the table above, profile_idc equal to =
58
      =
   (Extended) with profile-iop equal to 11xx0000 indicates =
the
      =
   same sub-profile corresponding to profile_idc equal to =
42
      =
   (Baseline) with profile-iop equal to x1xx0000.  Note =
that other
      =
   combinations of profile_idc and profile-iop (not listed =
in
 =
        Table 5) may represent a =
sub-profile equivalent to the common
      =
   subset of coding tools for more than one profile.  =
Note also
      =
   that a decoder conforming to a certain profile may be able =
to
      =
   decode bitstreams conforming to other profiles.  For example, =
a
&nb=
sp;        decoder conforming to the =
High 4:4:4 profile, at a certain
&nb=
sp;        level, must be able to =
decode bitstreams conforming to the
&nb=
sp;        Constrained Baseline, =
Main, High, High 10, or High 4:2:2
&nb=
sp;        profile at the same or a =
lower level.

 NEW: (note that the change here = is purely editorial)

=          For example, in the = table above, profile_idc equal to 58

=          (Extended) with = profile-iop equal to 11xx0000 indicates the

=          same sub-profile = corresponding to profile_idc equal to 42

=          (Baseline) with = profile-iop equal to x1xx0000.  Note that = other

=          combinations of = profile_idc and profile-iop (not listed in

=          Table 5) may represent = a sub-profile equivalent to the common

=          subset of coding tools = for more than one profile.  Note also

=          that a decoder = conforming to a certain profile may be able to

=          decode bitstreams = conforming to other profiles.

=  

OLD:= 

      =
   If the profile-level-id parameter is used for =
capability
      =
   exchange or session setup procedure, it =
indicates the subset of
      =
   coding tools, which is equal to the default sub-profile, =
that
      =
   the codec supports for both receiving and =
sending.

 NEW: (note that the change here = is purely editorial)

=          If the profile-level-id = parameter is used for capability

=          exchange or session = setup, it indicates the subset of

=          coding tools, which is = equal to the default sub-profile, that

=          the codec supports for = both receiving and sending.

 

OLD: =

=       max-cpb: The value of max-cpb is an = integer indicating the maximum

=          coded picture buffer = size in units of 1000 bits for the VCL HRD

=          parameters (see A.3.1, item i of = [1]) and in units of 1200 bits

=          for the NAL HRD = parameters (see A.3.1, = item j of [1]).

NEW: (note that the change here = is purely editorial)

=       max-cpb: The value of max-cpb is an = integer indicating the maximum

=          coded picture buffer = size in units of 1000 bits for the VCL HRD

=          parameters and in units = of 1200 bits for the NAL HRD parameters. =
         Note that this = parameter does not use units of cpbBrVclFactor and =

cpbBrNALFactor (see Table A-1 in = [1])= .

=  

OLD:=

=       max-dpb: The value of max-dpb is an = integer indicating the maximum

=          decoded picture buffer = size in units of 1024 bytes.  The max-

=          dpb parameter signals = that the receiver has more memory than

=          the minimum amount of = decoded picture buffer memory required by

=          the signaled highest = level conveyed in the value of the

=          profile-level-id = parameter or the max-recv-level parameter.

=          When max-dpb is = signaled, the receiver MUST be able to decode

=          NAL unit streams that = conform to the signaled highest level,

=          with the exception that = the MaxDPB value in Table A-1 of [1]

=          for the signaled = highest level is replaced with the value of

=          max-dpb.  = Consequently, a receiver that signals max-dpb MUST = be

=          capable of storing the = following number of decoded frames,

=          complementary field = pairs, and non-paired fields in its decoded

=          picture = buffer:

=  

=             = Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs = *

=             256 * = ChromaFormatFactor ), 16)

=  

=          PicWidthInMbs, = FrameHeightInMbs, and ChromaFormatFactor are

=          defined in = [1].

=  

=          The value of max-dpb = MUST be greater than or equal to the value

=          of MaxDPB given in = Table A-1 of [1] for the highest level.

=          Senders MAY use this = knowledge to construct coded video streams

=          with improved = compression.

=  

=             = Informative note: This parameter was added primarily = to

=           =   complement a similar codepoint in the ITU-T = Recommendation

=             = H.245, so as to facilitate signaling gateway designs.  = The

=             = decoded picture buffer stores reconstructed samples.  = There

=             is no = relationship between the size of the decoded = picture

=             = buffer and the buffers used in RTP, especially = de-interleaving
 and de-jitter buffers.

=  

NEW: (The nature of this change = as follows. If the semantics remain unchanged while the reference to = H.264 spec  is the 2010 version, then the semantics of max-dpb is = simply equivalent to unspecified, as MaxDPB and ChromaFormatFactor are = not found in the 2010 H.264 spec any more. Note that compared to RFC = 3984, the bits on the wire do not change hence there is no backward = compatibility issue.)

=       max-dpb: The value of max-dpb is an = integer indicating the maximum

=          decoded picture buffer = size in units of 8/3 = macroblocks.  The max-

=          dpb parameter signals = that the receiver has more memory than

=          the minimum amount of = decoded picture buffer memory required by

=          the signaled highest = level conveyed in the value of the

=          profile-level-id = parameter or the max-recv-level parameter.

=          When max-dpb is = signaled, the receiver MUST be able to decode

=          NAL unit streams that = conform to the signaled highest level,

=          with the exception that = the MaxDpbMbs = value in Table A-1 of [1]

     &nbs= p;   for the signaled highest level is replaced with the value = of

     &nbs= p;   max-dpb * 3 / 8= .  Consequently, a receiver that signals max-dpb MUST = be

=          capable of storing the = following number of decoded frames,

=          complementary field = pairs, and non-paired fields in its decoded

=          picture = buffer:

=  

=             Min(max-dpb * 3 / 8 / ( = PicWidthInMbs * FrameHeightInMbs), 16)

 

     &nbs= p;   Wherein PicWidthInMbs and FrameHeightInMbs are defined in = [1].=

=  

=          The value of max-dpb = MUST be greater than or equal to the value

=          of MaxDpbMbs * 3 / 8, = wherein the value of MaxDpbMbs is given in =

Table A-1 of [1] for the highest = level.=

=          Senders MAY use this = knowledge to construct coded video streams

=          with improved = compression.

=  

=             = Informative note: This parameter was added primarily = to

=           =   complement a similar codepoint in the ITU-T = Recommendation

=             = H.245, so as to facilitate signaling gateway designs.  = The

=             = decoded picture buffer stores reconstructed samples.  = There

=             is no = relationship between the size of the decoded = picture

=             = buffer and the buffers used in RTP, especially = de-interleaving
 and de-jitter buffers.

=  

=             Informative note: In = RFC 3984, which this document obsoletes,

     &nbs= p;      the unit of this parameter was 1024 = bytes.  The unit has been

     &nbs= p;      changed to 8/3 macroblocks in this = document.  This reason for

     &nbs= p;      this change was due to the changes from = the 2003 version of the

     &nbs= p;      H.264 specification referenced by RFC = 3984 to the 2010 version

     &nbs= p;      of the H.264 specification referenced = by this document, particularly

     &nbs= p;      the changes to Table A-1 in the H.264 = specification due to addition

     &nbs= p;      of color formats and bit depths not = supported earlier.  The

     &nbs= p;      changed semantics of this parameter = keeps backward

     &nbs= p;      compatibility to RFC 3984 and supports = all profiles defined in

     &nbs= p;      the 2010 version of the H.264 = specification.=

=  

OLD:= 

      =
max-br: The value of max-br is an integer indicating the =
maximum
      =
   video bitrate in units of 1000 bits per second for the VCL =
HRD
      =
   parameters (see A.3.1, item i of =
[1]) and in units of 1200 bits
      =
   per second for the NAL HRD parameters (see A.3.1, item j =
of
      =
   [1]).=

      =
   …

=          For example, if a = receiver signals capability for Level 1.2

=          with max-br equal to = 1550, this indicates a maximum video

=          bitrate of 1550 = kbits/sec for VCL HRD parameters, a maximum

=          video bitrate of 1860 = kbits/sec for NAL HRD parameters, and a

=          CPB size of 4036458 = bits (1550000 / 384000 * 1000 * 1000).

NEW: (note that the change here = is purely editorial) 

      =
max-br: The value of max-br is an integer indicating the =
maximum
      =
   video bitrate in units of 1000 bits per second for the VCL =
HRD
      =
   parameters and in units of 1200 bits per second for the NAL =
HRD parameters.

=          Note that this = parameter does not use units of cpbBrVclFactor and =

cpbBrNALFactor (see Table A-1 in = [1])= .

      =
   …

=          For example, if a = receiver signals capability for Main profile = Level 1.2

=          with max-br equal to = 1550, this indicates a maximum video

=          bitrate of 1550 = kbits/sec for VCL HRD parameters, a maximum

=          video bitrate of 1860 = kbits/sec for NAL HRD parameters, and a

=          CPB size of 4036458 = bits (1550000 / 384000 * 1000 * 1000).

 

------------------------------------= End of suggested changes = --------------------------------------

 

Best = Regards,

Ye-Kui = Wang

 

 

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On = Behalf Of Ye-Kui Wang
Sent: Monday, March 28, 2011 3:03 = PM
To: Roni Even; payload@ietf.org; avt@ietf.org
Cc: = 'Gary Sullivan'
Subject: Re: [AVTCORE] [payload] Some changes = to rfc3984bis, SVC, and RCDO payload = drafts

 

Hi = Roni,

 

Yes, we can add some = notes to clarify the reason for the changes and that the changes are = backward compatible to RFC 3984. If people feel that other notes would = be helpful too, please propose, I think we are open to all such = additions as long as they would be helpful for readers and implementers. =

 

BR, = YK

 

From: Roni Even [mailto:even.roni@huawei.com]
Sent: = Monday, March 28, 2011 11:21 AM
To: Ye-Kui Wang; = payload@ietf.org; avt@ietf.org
Cc: 'Gary Sullivan'; 'Roni = Even'; 'Mo Zanaty (mzanaty)'
Subject: RE: [AVTCORE] [payload] = Some changes to rfc3984bis, SVC, and RCDO payload = drafts

 

YK,

Maybe= it will be helpful to add the assumption about 4:2:0 8-bit support in = RFC3984 systems to the new 3984bis draft to clarify that you need to = support the new parameter if you are using other color = schemes

Roni<= o:p>

=  

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On = Behalf Of Roni Even
Sent: Sunday, March 27, 2011 7:24 = AM
To: 'Mo Zanaty (mzanaty)'; 'Ye-Kui Wang'; payload@ietf.org; = avt@ietf.org
Cc: 'Gary Sullivan'
Subject: Re: = [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload = drafts

 

HI = Mo,

When = the solution was discussed there are two = assumptions

1.       =  = ;Old implementations (RFC3984) expecting the maxdpb parameter in kbyes = only supported 4:2:0 8-bit and no other color because otherwise using = only Kbytes and not macro blocks will not work for them. New = implementation(RFC6184 – the assigned RFC number to 3984bis) = expects a value in macroblocks and will interpret the value in maxdpb as = macroblocks.

So = see my comments inline

Roni = Even

As = individual

=  

Further = discussions with the same group of persons led to a decision to stay = with the unscaled units for max-br and max-cpb, thus fewer changes are = needed to the three payload formats listed in the title and H.241. With = this, the changes needed are listed below (the originally suggested = changes are dropped from this email). This time I have highlighted the = changes, and I have also described the nature the changes below. Hope = these may help understand better what have been changed, and can lead to = a quicker decision by the group, including WG chairs, and our = AD.

 

BR, = YK

 

------------------------------------= Start of suggested changes = --------------------------------------

<= /div>
------_=_NextPart_001_01CBF00F.ECDFF27B--