[payload] WGLC on Some changes to rfc3984bis, SVC, and RCDO payload drafts

[Roni Even <[e-mail]>]

Hi,

Sorry for the double posting.

We found some issues with the text in RFC3984bis which affect also H264RCDO
and SVC. The issues were discovered by the RFC editor so we can fix it by
doing the changes marked bellow. I would like to start a two weeks WGLC on
the text in this email in order to allow enough time for people to review. 

Please send any comments till April 15th. If there will have no more issues
we will submit this changes to the RFC editor as part of the AUTH48.

Thanks

Roni Even

 

This is the text from YK:

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. 

 

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