Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Mon, 21 March 2011 17:50 UTC
Return-Path: <eckelcu@cisco.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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: <E1CBF4C7095A3D4CAAAEAD09FBB8E08C03CE39AD@xmb-sjc-234.amer.cisco.com>
In-Reply-To: <B99DECD58A94E143BA6F1508CC688351B445DE@dfweml504-mbx.china.huawei.com>
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: <B99DECD58A94E143BA6F1508CC688351B417FB@dfweml504-mbx.china.huawei.com> <B99DECD58A94E143BA6F1508CC688351B445DE@dfweml504-mbx.china.huawei.com>
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Ye-Kui Wang <yekui.wang@huawei.com>, payload@ietf.org, avt@ietf.org
X-OriginalArrivalTime: 21 Mar 2011 17:51:45.0267 (UTC) FILETIME=[A4C40C30:01CBE7F0]
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
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 > > 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 > >
- [AVTCORE] Some changes to rfc3984bis, SVC, and RC… Ye-Kui Wang
- Re: [AVTCORE] Some changes to rfc3984bis, SVC, an… Ye-Kui Wang
- Re: [AVTCORE] Some changes to rfc3984bis, SVC, an… Glen Zorn
- Re: [AVTCORE] Some changes to rfc3984bis, SVC, an… Roni Even
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Stephan Wenger
- Re: [AVTCORE] Some changes to rfc3984bis, SVC, an… Glen Zorn
- Re: [AVTCORE] Some changes to rfc3984bis, SVC, an… Ye-Kui Wang
- Re: [AVTCORE] Some changes to rfc3984bis, SVC, an… DRAGE, Keith (Keith)
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Stephen Botzko
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Charles Eckel (eckelcu)
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Allison, Art
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Ye-Kui Wang
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Allison, Art
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Ye-Kui Wang
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Roni Even
- Re: [AVTCORE] Some changes to rfc3984bis, SVC, an… Mo Zanaty (mzanaty)
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Roni Even
- Re: [AVTCORE] Some changes to rfc3984bis, SVC, an… Ye-Kui Wang
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Roni Even
- Re: [AVTCORE] [payload] Some changes to rfc3984bi… Ye-Kui Wang