Subject: Re: [payload] Errata report on RFC6184 - H.264 payload

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 May 2013 08:56:52 +0300

Hi,

is this erratum likely to cause interoperability problems? We need to
know that in order to properly handle the erratum. What is your view?

Note that the policy is to "verify" errata that are likely to cause
interoperability problems and to "hold for document update" errata that
are correct but are not likely to cause those types of problems.

Thanks,

Gonzalo

On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote:
> The errata looks correct. For further clarity, it may also help to add
> parenthesis
> 
> around (max-dpb*8/3).
> 
>  
> 
> NEW:
> 
> 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 * 8/3. 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 * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16)
> 
>  
> 
> Mo
> 
>  
> 
>  
> 
> *From:*Roni Even [mailto:[email-masked]]
> *Sent:* Friday, April 19, 2013 3:41 AM
> *To:* [email-masked]
> *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom
> Kristensen (tomkrist)
> *Subject:* Errata report on RFC6184 - H.264 payload
> 
>  
> 
> Hi,
> 
> An errata report was filed on RFC6184
> http://www.rfc-editor.org/errata_search.php?eid=3318  it is given bellow.
> 
> I would like to get some feedback about this errata, is it correct?
> 
> “Section 8.1 says:
> 
> On page 46 start from line 7:
> 
> "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)"
> 
> It should say:
> 
> 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 * 8 / 3. 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 * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs),
> 
>               ^^^^^
> 
> 16)
> 
> “
> 
>  
> 
>  
> 
>  
> 
> My personal view is that  since MaxDpbMbs= max-dpb * 8 / 3 the errata is
> correct.
> 
>  
> 
>  
> 
> Roni Even
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 May 2013 09:54:32 +0300

Hi,
In my view it will not cause any interoperability if the implementers are
looking at the ITU-H.264 reference. I assume they are looking at table A-1
in order to know the actual DPB size for the needed resolution and
calculating it
Roni

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 22 May, 2013 8:57 AM
> To: Mo Zanaty (mzanaty)
> Cc: Roni Even; [email-masked]; Wang, Ye-Kui; 'Botzko, Stephen'; Tom
> Kristensen (tomkrist)
> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload
> 
> Hi,
> 
> is this erratum likely to cause interoperability problems? We need to know
> that in order to properly handle the erratum. What is your view?
> 
are
> correct but are not likely to cause those types of problems.
> 
> Thanks,
> 
> Gonzalo
> 
> > "Section 8.1 says:
> > "
> > My personal view is that  since MaxDpbMbs= max-dpb * 8 / 3 the errata
> > is correct.
> >
> >
> >
> >
> >
> > Roni Even
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 May 2013 12:59:37 +0300

Hi Roni,

thanks for your response. I am actually leaning towards verifying the
erratum, given that the wrong figures could confuse someone.

Cheers,

Gonzalo

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 22 May 2013 06:48:49 -0400

Hi all

First of all, I believe the erratum is correct.  units of 8/3 means that
max-dpb=3  is the same as MaxDpbMbs=8.

-if max-dbp is signalled, then that indicates that a receiver can handle
more reference frames than profile/level requires.
-if the same mistake is made in both sender and receiver, then no harm is
done.
-however, if the mistake is not consistent, then the sender and receiver
will have different understandings of the number of reference frames.

-since the unit 8/3 was specifically chosen to match RFC 3984's original
values, then mismatched implementations are in fact likely.

If the encoder uses a larger number of reference frames than is in fact
available, the rendered video will be corrupted.
If the encoder uses a smaller number of reference frames, then the rendered
video will be ok, though perhaps lower in quality than it could be.

If the computed number of reference frames turns out to be less than what
is required in the level, then some implementations might get quite
confused (since this violates the MUST be greater than A-1).

Given the need to match RFC 3984 values (hence the odd units), I would
disagree with Roni's assessment that there is no interop issue that
results. Given the overall confusion on the unusual units, I would rather
see this fixed sooner than later.

BR
Stephen Botzko

On Wed, May 22, 2013 at 5:59 AM, Gonzalo Camarillo <
[email-masked]> wrote:

> know

---

From: "Roni Even" <[email-masked]>
Date: Wed, 22 May 2013 14:07:46 +0300

Hi Steve,

The fix is already there, if you go to RFC6184 you will see that it says
that the errata exists to fix it.

The question is what are the implications, do you think or know (Polycom
systems) if existing implementations used the wrong value (3/8) in which
case there will be interoperability problem.  

Roni

From: Stephen Botzko [mailto:[email-masked]] 
Sent: 22 May, 2013 1:49 PM
To: Gonzalo Camarillo
Cc: Roni Even; Wang, Ye-Kui; Botzko, Stephen; [email-masked]; Tom
Kristensen (tomkrist)
Subject: Re: [payload] Errata report on RFC6184 - H.264 payload

Hi all

If the computed number of reference frames turns out to be less than what is
required in the level, then some implementations might get quite confused
(since this violates the MUST be greater than A-1).  

Given the need to match RFC 3984 values (hence the odd units), I would
disagree with Roni's assessment that there is no interop issue that results.
Given the overall confusion on the unusual units, I would rather see this
fixed sooner than later.

BR
Stephen Botzko

On Wed, May 22, 2013 at 5:59 AM, Gonzalo Camarillo
<[email-masked]> wrote:

Hi Roni,

Cheers,

Gonzalo

know

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 22 May 2013 14:25:25 +0300

Hi,

let me clarify what we are doing here. This is the page where you can
see all the errata related to RFC 6184:

http://www.rfc-editor.org/errata_search.php?rfc=6184

As you can see, there is only one erratum and its state is "reported".
Given that the erratum is correct, as we have already discussed, we have
to move it to one of the following two states: verified or held for
document update.

The first state means that the erratum is correct and that implementers
should look at it carefully. The second state means that the erratum is
correct but that implementers do not need to pay too much attention to
it because it is not likely to confuse them (e.g., a typo in a document
or an error in an example).

So, this is important for all implementers, old and new.

Based on the discussions so far, I am going to "verify" this erratum.

Cheers,

Gonzalo

On 22/05/2013 2:07 PM, Roni Even wrote:
> *From:*Stephen Botzko [mailto:[email-masked]]
> *Sent:* 22 May, 2013 1:49 PM
> *To:* Gonzalo Camarillo
> *Cc:* Roni Even; Wang, Ye-Kui; Botzko, Stephen; [email-masked]; Tom
> Kristensen (tomkrist)
> *Subject:* Re: [payload] Errata report on RFC6184 - H.264 payload
> 
>  
> 
> Hi all
> 
> -if the same mistake is made in both sender and receiver, then no harm
> is done.
> If the encoder uses a smaller number of reference frames, then the
> rendered video will be ok, though perhaps lower in quality than it could be.
> 
> If the computed number of reference frames turns out to be less than
> what is required in the level, then some implementations might get quite
> results. Given the overall confusion on the unusual units, I would
> rather see this fixed sooner than later.
> 
> BR
> Stephen Botzko
> 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> Hi Roni,
> 
>>> From: Gonzalo Camarillo [mailto:[email-masked]
> <mailto:[email-masked]>]
>>> Cc: Roni Even; [email-masked] <mailto:[email-masked]>; Wang,
> Ye-Kui; 'Botzko, Stephen'; Tom
>>> Kristensen (tomkrist)
>>>> *From:*Roni Even [mailto:[email-masked]
> <mailto:[email-masked]>]
>>>> *To:* [email-masked] <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 22 May 2013 15:12:41 +0000

Agree to "verify" this. It can possibly (although unlikely) cause interoperability problems due to confusion about the conversion between max-dpb and MaxDpbMbs. I say "although unlikely" because max-dpb is rarely used, since the default number of reference frames (4+) in any H.264 level typically exceeds the number used in conferencing. At recent interoperability events (SIPit30, IMTC SuperOp 2013), only a single vendor was using max-dpb (and correctly). And those using it would likely be knowledgeable about its intended semantics.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
Sent: Wednesday, May 22, 2013 7:25 AM
To: Roni Even
Cc: 'Wang, Ye-Kui'; 'Botzko, Stephen'; [email-masked]; Tom Kristensen (tomkrist)
Subject: Re: [payload] Errata report on RFC6184 - H.264 payload

Hi,

Cheers,

Gonzalo

---

From: "Botzko, Stephen" <[email-masked]>
Date: Wed, 22 May 2013 09:09:07 -0700

I agree that "verify" is the appropriate state.

Stephen Botzko

Sent from my iPad

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 May 2013 08:35:55 +0300

Done!

Gonzalo