Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

From: Richard Barnes <[email-masked]>
Date: Thu, 10 Oct 2013 15:45:09 -0400

Do any PAYLOAD folks have a comment on this?  This seems like a pretty
major erratum, if correct.

Thanks,
--Richard

On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System <
[email-masked]> wrote:

> The following errata report has been submitted for RFC6190,
> "RTP Payload Format for Scalable Video Coding".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6190&eid=3711
>
> --------------------------------------
> Type: Technical
> Reported by: Xiaohui Wei (Joanne) <[email-masked]>
>
> Section: 1.1.3
>
> Original Text
> -------------
>    N:    1 bit
>          no_inter_layer_pred_flag.  This flag specifies, when present in
>          a coded slice NAL unit, whether inter-layer prediction may be
>          used for decoding the coded slice (when equal to 1) or not
>          (when equal to 0).
>
> Corrected Text
> --------------
>    N:    1 bit
>          no_inter_layer_pred_flag.  This flag specifies, when present in
>          a coded slice NAL unit, whether inter-layer prediction may be
>          used for decoding the coded slice (when equal to 0) or not
>                                                           ^
>          (when equal to 1).
>                         ^
>
> Notes
> -----
>
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6190 (draft-ietf-avt-rtp-svc-27)
> --------------------------------------
> Title               : RTP Payload Format for Scalable Video Coding
> Publication Date    : May 2011
> Author(s)           : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis
> Category            : PROPOSED STANDARD
> Source              : Audio/Video Transport Payloads
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG
>

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Fri, 11 Oct 2013 03:45:03 +0000

The erratum is correct, though to me it is obviously a (relatively minor) typo.

BR, YK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, October 10, 2013 12:45 PM
To: RFC Errata System
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

Do any PAYLOAD folks have a comment on this?  This seems like a pretty major erratum, if correct.

Thanks,
--Richard

On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System <[email-masked]<mailto:[email-masked]>> wrote:
The following errata report has been submitted for RFC6190,
"RTP Payload Format for Scalable Video Coding".

--------------------------------------
Type: Technical
Reported by: Xiaohui Wei (Joanne) <[email-masked]<mailto:[email-masked]>>

Section: 1.1.3

Original Text
-------------
   N:    1 bit

Corrected Text
--------------
   N:    1 bit

Notes
-----

Instructions:
-------------

---

From: Alex Eleftheriadis <[email-masked]>
Date: Fri, 11 Oct 2013 05:57:51 +0000

I agree; the intended interpretation of the flag is evident by its name. It should, however, be marked as an error.

--AE

On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" <[email-masked]<mailto:[email-masked]>> wrote:

BR, YK

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Thursday, October 10, 2013 12:45 PM
To: RFC Errata System
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

Thanks,
--Richard

Section: 1.1.3

Original Text
-------------
   N:    1 bit

Corrected Text
--------------
   N:    1 bit

Notes
-----

Instructions:
-------------

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

---

From: "Roni Even" <[email-masked]>
Date: Fri, 11 Oct 2013 09:49:56 +0300

Since I saw feedback from Alex and Ye-Kui,  I am wondering what the
implementation are currently doing.

Even though it make sense to change the current meaning I do not think it is
wrong to keep the current values if was implemented this way.

Thanks

Roni Even

Payload WG co-chair 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alex Eleftheriadis
Sent: 11 October, 2013 8:58 AM
To: Wang, Ye-Kui
Cc: [email-masked]; [email-masked]; RFC Errata System
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

I agree; the intended interpretation of the flag is evident by its name. It
should, however, be marked as an error. 

--AE

On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" <[email-masked]> wrote:

The erratum is correct, though to me it is obviously a (relatively minor)
typo.

BR, YK

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Barnes
Sent: Thursday, October 10, 2013 12:45 PM
To: RFC Errata System
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

Do any PAYLOAD folks have a comment on this?  This seems like a pretty major
erratum, if correct.

Thanks,

--Richard

On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System
<[email-masked]> wrote:

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6190
<http://www.rfc-editor.org/errata_search.php?rfc=6190&eid=3711> &eid=3711

Section: 1.1.3

Original Text
-------------
   N:    1 bit

Corrected Text
--------------
   N:    1 bit

Notes
-----

Instructions:
-------------

[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 11 Oct 2013 15:40:41 +0000

This error is in section 1.1.3 of RFC 6190, which explicitly states that it is an summary of field definitions specified by the H.264 spec.

Thus, I would hope (and expect) that most implementations are following the H.264 definition of this bit, not the RFC 6190 definition.

On Oct 11, 2013, at 2:49 AM, Roni Even <[email-masked]<mailto:[email-masked]>>
 wrote:

Since I saw feedback from Alex and Ye-Kui,  I am wondering what the  implementation are currently doing.
Even though it make sense to change the current meaning I do not think it is wrong to keep the current values if was implemented this way.
Thanks
Roni Even
Payload WG co-chair

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alex Eleftheriadis
Sent: 11 October, 2013 8:58 AM
To: Wang, Ye-Kui
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; RFC Errata System
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

--AE

BR, YK

Thanks,
--Richard

Section: 1.1.3

Original Text
-------------
   N:    1 bit

Corrected Text
--------------
   N:    1 bit

Notes
-----

Instructions:
-------------

---

From: "Wang, Ye-Kui" <[email-masked]>
Date: Fri, 11 Oct 2013 15:47:15 +0000

Exactly - as it is just a summary of the field specified in the SVC spec, it is basically non-normative.

Also, the fields in the 4-byte NAL unit header has been carefully designed at JVT when SVC was developed, to avoid the possibility of certain bit patterns that are used as start codes in some systems.

Considering all these factors, the errata should be approved (or whatever the right process is).

BR, YK

From: Jonathan Lennox [mailto:[email-masked]]
Sent: Friday, October 11, 2013 8:41 AM
To: Roni Even
Cc: Alex Eleftheriadis; Wang, Ye-Kui; <[email-masked]>; <[email-masked]>; RFC Errata System
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

--AE

BR, YK

Thanks,
--Richard

Section: 1.1.3

Original Text
-------------
   N:    1 bit

Corrected Text
--------------
   N:    1 bit

Notes
-----

Instructions:
-------------

---

From: "Roni Even" <[email-masked]>
Date: Sat, 12 Oct 2013 18:49:02 +0300

OK with me

Roni Even

From: Wang, Ye-Kui [mailto:[email-masked]] 
Sent: 11 October, 2013 6:47 PM
To: Jonathan Lennox; Roni Even
Cc: Alex Eleftheriadis; <[email-masked]>; <[email-masked]>; RFC
Errata System
Subject: RE: [payload] [Technical Errata Reported] RFC6190 (3711)

Exactly - as it is just a summary of the field specified in the SVC spec, it
is basically non-normative.

Also, the fields in the 4-byte NAL unit header has been carefully designed
at JVT when SVC was developed, to avoid the possibility of certain bit
patterns that are used as start codes in some systems.

Considering all these factors, the errata should be approved (or whatever
the right process is).

BR, YK

From: Jonathan Lennox [mailto:[email-masked]] 
Sent: Friday, October 11, 2013 8:41 AM
To: Roni Even
Cc: Alex Eleftheriadis; Wang, Ye-Kui; <[email-masked]>;
<[email-masked]>; RFC Errata System
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

This error is in section 1.1.3 of RFC 6190, which explicitly states that it
is an summary of field definitions specified by the H.264 spec.

Thus, I would hope (and expect) that most implementations are following the
H.264 definition of this bit, not the RFC 6190 definition.

On Oct 11, 2013, at 2:49 AM, Roni Even <[email-masked]>

 wrote:

Thanks

Roni Even

Payload WG co-chair

From:  <mailto:[email-masked]> [email-masked]
[mailto:payload- <mailto:[email-masked]> [email-masked]] On Behalf Of
Alex Eleftheriadis
Sent: 11 October, 2013 8:58 AM
To: Wang, Ye-Kui
Cc:  <mailto:[email-masked]> [email-masked]; [email-masked];
RFC Errata System
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

--AE

On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" <
<mailto:[email-masked]> [email-masked]> wrote:

BR, YK

From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf
Of Richard Barnes
Sent: Thursday, October 10, 2013 12:45 PM
To: RFC Errata System
Cc:  <mailto:[email-masked]> [email-masked];
<mailto:[email-masked]> [email-masked];  <mailto:[email-masked]>
[email-masked]
Subject: Re: [payload] [Technical Errata Reported] RFC6190 (3711)

Thanks,

--Richard

On Mon, Aug 26, 2013 at 12:26 PM, RFC Errata System <
<mailto:[email-masked]> [email-masked]> wrote:

--------------------------------------
You may review the report below and at:
 <http://www.rfc-editor.org/errata_search.php?rfc=6190&eid=3711>
http://www.rfc-editor.org/errata_search.php?rfc=6190&eid=3711

--------------------------------------
Type: Technical
Reported by: Xiaohui Wei (Joanne) < <mailto:[email-masked]> [email-masked]>

Section: 1.1.3

Original Text
-------------
   N:    1 bit

Corrected Text
--------------
   N:    1 bit

Notes
-----

Instructions:
-------------

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

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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 28 Oct 2013 18:04:41 -0400

Thanks, all.  I have marked this as "Verified".

On Sat, Oct 12, 2013 at 11:49 AM, Roni Even <[email-masked]> wrote:

> OK with me****
>
> Roni Even****
>
> ** **
>
> *From:* Wang, Ye-Kui [mailto:[email-masked]]
> *Sent:* 11 October, 2013 6:47 PM
> *To:* Jonathan Lennox; Roni Even
> *Cc:* Alex Eleftheriadis; <[email-masked]>; <[email-masked]>; RFC
> Errata System
> *Subject:* RE: [payload] [Technical Errata Reported] RFC6190 (3711)****
>
> ** **
>
> Exactly – as it is just a summary of the field specified in the SVC spec,
> it is basically non-normative.****
>
> ** **
>
> patterns that are used as start codes in some systems.****
>
> ** **
>
> the right process is).****
>
> ** **
>
> BR, YK****
>
> ** **
>
> *From:* Jonathan Lennox [mailto:[email-masked] <[email-masked]>]
> *Sent:* Friday, October 11, 2013 8:41 AM
> *To:* Roni Even
> *Cc:* Alex Eleftheriadis; Wang, Ye-Kui; <[email-masked]>; <
> [email-masked]>; RFC Errata System
> *Subject:* Re: [payload] [Technical Errata Reported] RFC6190 (3711)****
>
> ** **
>
> This error is in section 1.1.3 of RFC 6190, which explicitly states that
> it is an summary of field definitions specified by the H.264 spec.****
>
> ** **
>
> Thus, I would hope (and expect) that most implementations are following
> the H.264 definition of this bit, not the RFC 6190 definition.****
>
> ** **
>
> On Oct 11, 2013, at 2:49 AM, Roni Even <[email-masked]>****
>
>  wrote:****
>
> ** **
>
>  implementation are currently doing.****
>
> Even though it make sense to change the current meaning I do not think it
> is wrong to keep the current values if was implemented this way.****
>
> Thanks****
>
> Roni Even****
>
> Payload WG co-chair****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Alex Eleftheriadis
> *Sent:* 11 October, 2013 8:58 AM
> *To:* Wang, Ye-Kui
> *Cc:* [email-masked]; [email-masked]; RFC Errata System
> *Subject:* Re: [payload] [Technical Errata Reported] RFC6190 (3711)****
>
>  ****
>
> I agree; the intended interpretation of the flag is evident by its name.
> It should, however, be marked as an error.
>
> --AE****
>
>
> On Oct 11, 2013, at 4:45 AM, "Wang, Ye-Kui" <[email-masked]>
> wrote:****
>
> typo.****
>  ****
> BR, YK****
>  ****
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>
> ] *On Behalf Of *Richard Barnes
> *Sent:* Thursday, October 10, 2013 12:45 PM
> *To:* RFC Errata System
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [payload] [Technical Errata Reported] RFC6190 (3711)****
>
>  ****
>
> major erratum, if correct.****
>
>  ****
>
> Thanks,****
>
> --Richard****
>
>  ****
>
> [email-masked]> wrote:****
>
> Verifying Party     : IESG****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/payload****
>
> https://www.ietf.org/mailman/listinfo/payload****
>
> ** **
>