RFC 8216, "HTTP Live Streaming", August 2017Source of RFC: INDEPENDENT
See Also: RFC 8216 w/ inline errata
Errata ID: 7283
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:
#EXTM3U ... #EXT-X-DATERANGE:ID="splice-6FFFFFF0",START-DATE="2014-03-05T11: 15:00Z",PLANNED-DURATION=59.993,SCTE35-OUT=0xFC002F0000000000FF0 00014056FFFFFF000E011622DCAFF000052636200000000000A0008029896F50 000008700000000 ... Media Segment declarations for 60s worth of media #EXT-X-DATERANGE:ID="splice-6FFFFFF0",DURATION=59.993,SCTE35-IN= 0xFC002A0000000000FF00000F056FFFFFF000401162802E6100000000000A00 08029896F50000008700000000 ...
It should say:
#EXTM3U ... #EXT-X-DATERANGE:ID="splice-6FFFFFF0",START-DATE="2014-03-05T11: 15:00Z",PLANNED-DURATION=59.993,SCTE35-OUT=0xFC002F000000000000F F000014056FFFFFF000E081622DCAFF000052636200000000000A0008029896F 50000008700000000 ... Media Segment declarations for 60s worth of media #EXT-X-DATERANGE:ID="splice-6FFFFFF0",DURATION=59.993,SCTE35-IN= 0xFC002A000000000000FF00000F056FFFFFF000408162802E6100000000000A 0008029896F50000008700000000 ...
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.