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

From: Glen Zorn <[email-masked]>
Date: Sun, 20 Mar 2011 16:16:42 +0700

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: Ye-Kui Wang <[email-masked]>
Date: Sun, 20 Mar 2011 08:20:45 +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 --------------------------------------

---

From: Roni Even <[email-masked]>
Date: Sun, 20 Mar 2011 14:25:10 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Glen Zorn
> Sent: Sunday, March 20, 2011 11:17 AM
> To: Ye-Kui Wang
> Cc: [email-masked]; [email-masked]
> Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO
> payload drafts
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 20 Mar 2011 15:20:41 +0100

+1
Stephan (also in Geneve)

Sent from my iPhone

On Mar 20, 2011, at 13:25, Roni Even <[email-masked]> wrote:

> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 21 Mar 2011 11:29:54 +0100

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen
> Zorn
> Sent: 21 March 2011 06:11
> To: Roni Even
> Cc: [email-masked]; [email-masked]
> Subject: Re: [AVTCORE] Some changes to rfc3984bis, SVC, and RCDO payload
> drafts
> 
> On 3/20/2011 7:25 PM, Roni Even wrote:
> 
> > Hi Glen,
> 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.
> 
> >

---

From: Stephen Botzko <[email-masked]>
Date: Mon, 21 Mar 2011 11:46:05 +0100

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) <
[email-masked]> 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
>
> Glen
> > > This change involves also an update to H.241 that has the same issue
> and
> > the

---

From: Glen Zorn <[email-masked]>
Date: Mon, 21 Mar 2011 13:11:21 +0700

---

From: Ye-Kui Wang <[email-masked]>
Date: Mon, 21 Mar 2011 08:11:23 +0000

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

Section 8.1:
OLD:

      profile-level-id:

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

OLD:

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

OLD:

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

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:

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

OLD:

         [1]).

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

         parameters and in units of 1200 bits

         per second for the NAL HRD parameters.

         ...

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

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

Folks,

BR, YK

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 21 Mar 2011 10:51:43 -0700

Hi YK,

Thank you for providing this clear description of the proposed changes.
The changes look good to me.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ye-Kui Wang
> Sent: Monday, March 21, 2011 1:11 AM
> 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
> 
> 
> 
> 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.)
> 
Ye-Kui Wang
> 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).
> 
> 
> 
> 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.
> 
> 
> 
Monday, March 21, if any. Many
> thanks!

---

From: "Allison, Art" <[email-masked]>
Date: Mon, 21 Mar 2011 16:47:20 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Monday, March 21, 2011 1:52 PM
To: Ye-Kui Wang; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC,and RCDO payload drafts

Hi YK,

Cheers,
Charles

Behalf Of Ye-Kui Wang
payload drafts
Ye-Kui Wang
stage.

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 23 Mar 2011 08:54:17 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Allison, Art
Sent: Monday, March 21, 2011 4:47 PM
To: [email-masked]; [email-masked]
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

Art

Art Allison

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Monday, March 21, 2011 1:52 PM
To: Ye-Kui Wang; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC,and RCDO payload drafts

Hi YK,

Cheers,
Charles

Behalf Of Ye-Kui Wang
payload drafts
Ye-Kui Wang
stage.

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 23 Mar 2011 14:55:46 +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.264/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 different (which you call inconsistency). Many times you have to be inconsistent to be correct :-)

The changes are now sent to the (two) lists for review, and we authors welcome any comments, and particularly those that point out concrete further changes that are needed.

BR, YK

-----Original Message-----
From: Allison, Art [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 10:37 AM
To: Ye-Kui Wang; [email-masked]; [email-masked]
Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

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

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 4:54 AM
To: Allison, Art; [email-masked]; [email-masked]
Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

BR, YK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Allison, Art
Sent: Monday, March 21, 2011 4:47 PM
To: [email-masked]; [email-masked]
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

Art

Art Allison

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Monday, March 21, 2011 1:52 PM
To: Ye-Kui Wang; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC,and RCDO payload drafts

Hi YK,

Cheers,
Charles

Behalf Of Ye-Kui Wang
payload drafts
Ye-Kui Wang
stage.

---

From: Roni Even <[email-masked]>
Date: Wed, 23 Mar 2011 20:19:20 +0200

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

> Allison, Art
> Sent: Wednesday, March 23, 2011 4:37 PM
> 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
> 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
> 
> Allison, Art
> 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?
> 
> Charles Eckel (eckelcu)
> >          decode bitstreams conforming to other profiles.  For
> example,
> a
> >          decoded picture buffer size in units of 8/3 macroblocks.
> The
> max-
> >
> >             Min(max-dpb * 3 / 8 / ( PicWidthInMbs *
> FrameHeightInMbs),
> 16)
> >
> >
> >
> >          of MaxDpbMbs * 3 / 8, wherein the value of MaxDpbMbs is
> given
> in
> >

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 23 Mar 2011 10:37:26 -0400

Art Allison

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 4:54 AM
To: Allison, Art; [email-masked]; [email-masked]
Subject: RE: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

BR, YK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Allison, Art
Sent: Monday, March 21, 2011 4:47 PM
To: [email-masked]; [email-masked]
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC, and RCDO payload drafts

Art

Art Allison

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Monday, March 21, 2011 1:52 PM
To: Ye-Kui Wang; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] [payload] Some changes to rfc3984bis, SVC,and RCDO payload drafts

Hi YK,

Cheers,
Charles

Behalf Of Ye-Kui Wang
payload drafts
Ye-Kui Wang
stage.