Found 3 records.

Status: Verified (1)

RFC 6184, "RTP Payload Format for H.264 Video", May 2011

Errata ID: 3318
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Xiaohui Wei (Joanne)
Date Reported: 2012-08-14
Verifier Name: Gonzalo Camarillo
Date Verified: 2013-05-22

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)

Status: Rejected (2)

RFC 6184, "RTP Payload Format for H.264 Video", May 2011

Errata ID: 4713
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2016-06-17
Rejected by: Francesca Palombini
Date Rejected: 2023-11-07

Section 8.1 says:

profile-level-id:
         A base16 [7] (hexadecimal) representation of the following
         three bytes in the sequence parameter

It should say:

profile-level-id:
         A base16 [7] (hexadecimal) representation of the following
         six bytes in the sequence parameter

Notes:

profile-level-id is composed of three 2-byte length fields.
--VERIFIER NOTES--
The original text is correct; 3 bytes in the binary representation become 6 text characters in base16.

Errata ID: 4714
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Iñaki Baz Castillo
Date Reported: 2016-06-17
Rejected by: Ben Campbell
Date Rejected: 2016-06-21

Section 8.2.2 says:

To simplify the handling and matching of these configurations, the
same RTP payload type number used in the offer SHOULD also be used
in the answer, as specified in [8]

[8] points to RFC 3264 "An Offer/Answer Model with the Session
Description Protocol (SDP)"

Notes:

The above statement is wrong. RFC 3264 does not mandate the same payload
type in both the offer and the answer. In fact, RFC 3264 section 5.1 states:

For sendonly RTP streams, the payload type
numbers indicate the value of the payload type field in RTP packets
the offerer is planning to send for that codec. For sendrecv RTP
streams, the payload type numbers indicate the value of the payload
type field the offerer expects to receive, and would prefer to send.

However, for sendonly and sendrecv streams, the answer might indicate
different payload type numbers for the same codecs, in which case,
the offerer MUST send with the payload type numbers from the answer.
--VERIFIER NOTES--
Rejected based on discussion on avtcore and payload lists. (3264 does in fact include the SHOULD).

Report New Errata