RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

RFC 8216, "HTTP Live Streaming", August 2017

See Also: RFC 8216 w/ inline errata

Errata ID: 7283
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexander Batischev
Date Reported: 2022-12-22
Verifier Name: Eliot Lear (ISE)
Date Verified: 2023-01-04

Section 8.10 says:


   ... Media Segment declarations for 60s worth of media


It should say:


   ... Media Segment declarations for 60s worth of media



Both examples contain the same two mistakes. Let's look at the first example and find the first mistake:

1. 12 bits at offset 12 are section_length, and they equal 0x02F. This indicates that the rest of the section should take up 47 bytes, but actually there is only 46 bytes;
2. 12 bits at offset 92 are splice_command_length, and they equal 0x405. This indicates that there should be 1029 bytes after splice_command_type, which is clearly wrong since there are only 20 bytes there;
3. 8 bits at offset 104 are splice_command_type, and they equal 0x6F. This is not a valid command type. Since this is an SCTE35-IN tag, it's a splice_insert() event and we expect to see 0x05 in those bits. This conjecture is supported by the fact that 0x6F appears to be the first byte of the splice_event_id field.

It looks like a byte is missing somewhere between bit positions 24 and 92. In the corrected text, I took the liberty of inserting 0x00 at bit offset 24. This changes the section length to the declared 47 bytes; splice_command_length becomes 0x14 which is the expected 20 bytes; and splice_command_type becomes 0x05 which is the expected splice_insert() type. Accidentally this also changes pts_adjustment from 0xFF to 0x00; this shouldn't hurt because we don't know what PTSes the HLS segments contain, anyway.

With this fix applied, we can see the second mistake: the bit at offset 168 is time_specified_flag of the splice_time() contained within splice_insert(), and it's zero. This implies that there is no PTS inside splice_time(), which is clearly wrong, since the #EXT-X-DATERANGE displays the START-DATE. In the corrected text, I flipped this bit to 1. Again, without knowing the PTSes inside the segments, I can't tell if this gives us a correct pts_time, but at least the break_duration() now gives expected duration of 59.993 seconds.

The second example contains the same two mistakes, and the corrected text contains the same two fixes:

1. at bit offset 24, a new 0x00 byte is inserted;
2. at bit offset 168, zero bit is flipped to one.

Report New Errata

Advanced Search