Re: [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

Ye-Kui Wang <yekui.wang@huawei.com> Sun, 20 March 2011 08:22 UTC

Return-Path: <yekui.wang@huawei.com>
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 <yekui.wang@huawei.com>
X-Originating-IP: [10.47.82.122]
To: "payload@ietf.org" <payload@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Message-id: <B99DECD58A94E143BA6F1508CC688351B41818@dfweml504-mbx.china.huawei.com>
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 <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/payload>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Mar 2011 08:22:56 -0000

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 --------------------------------------