Re: [payload] [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload drafts
"Allison, Art" <AAllison@nab.org> Wed, 23 March 2011 14:35 UTC
Return-Path: <aallison@nab.org>
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 <aallison@nab.org>); 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: <B99DECD58A94E143BA6F1508CC688351051CAE50@dfweml503-mbx.china.huawei.com>
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: <B99DECD58A94E143BA6F1508CC688351B445DE@dfweml504-mbx.china.huawei.com> <E1CBF4C7095A3D4CAAAEAD09FBB8E08C03CE39AD@xmb-sjc-234.amer.cisco.com> <71C9EC0544D1F64D8B7D91EDCC62202006890479@NABSREX027324.NAB.ORG> <B99DECD58A94E143BA6F1508CC688351051CAE50@dfweml503-mbx.china.huawei.com>
From: "Allison, Art" <AAllison@nab.org>
To: Ye-Kui Wang <yekui.wang@huawei.com>, payload@ietf.org, avt@ietf.org
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <aallison@nab.org>
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 <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: Wed, 23 Mar 2011 14:35:59 -0000
I admit significant ignorance of the technical details. 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. 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 <process managers> can make better decisions when more information is provided. I commented to so assist. Art Allison Senior Director Advanced Engineering, Science and Technology National Association of Broadcasters 1771 N Street NW Washington, DC 20036 Phone 202 429 5418 Fax 202 775 4981 www.nab.org Advocacy Education Innovation -----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 The units of the values of 1000 and 1200 are clearly specified. Where is not clear, could you clarify? 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. 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 202 429 5418 Fax 202 775 4981 www.nab.org Advocacy Education 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 > > 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 > > _______________________________________________ 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] Some changes to rfc3984bis, SVC, and RC… Ye-Kui Wang
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Roni Even
- Re: [payload] Some changes to rfc3984bis, SVC, an… Ye-Kui Wang
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Glen Zorn
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Stephan Wenger
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… DRAGE, Keith (Keith)
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Stephen Botzko
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Glen Zorn
- Re: [payload] Some changes to rfc3984bis, SVC, an… Ye-Kui Wang
- Re: [payload] Some changes to rfc3984bis, SVC, an… Charles Eckel (eckelcu)
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Allison, Art
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Ye-Kui Wang
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Ye-Kui Wang
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Roni Even
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Mo Zanaty (mzanaty)
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Roni Even
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Ye-Kui Wang
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Allison, Art
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Mo Zanaty (mzanaty)
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Roni Even
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Ye-Kui Wang
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Ye-Kui Wang
- Re: [payload] [AVTCORE] Some changes to rfc3984bi… Mo Zanaty (mzanaty)