Fix default EXT-X-BYTERANGE offset to start after the previous segment #98
Conversation
The default value for EXT-X-BYTERANGE is defined by the spec as the first byte after the previous segment. Prior to this change, the default set by m3u8-parser was 0.
| { length: 15, offset: 100 }, | ||
| 'fifth segment has correct byterange' | ||
| ); | ||
| // not tested is a segment with no offset coming after a segment that isn't a sub range, |
There was a problem hiding this comment.
This has me curious on what some valid use-cases may be as the wording in the spec is a bit ambiguous and whether we should add some protections/warnings when we detect that the MUST has been broken.
If o is not present, the sub-range begins at the next byte following the sub-range of the previous Media Segment.
This seems to imply that the subrange begins following the direct previous segment
but then the next sentence
If o is not present, a previous Media Segment MUST appear in the Playlist file and MUST be a sub-range of the same media resource
A previous MediaSeqment, implies that there just needs to be a previous sub-range of the same media resource (segment uri) somewhere in the playlist.
The second sentence makes me think this is a valid playlist
(reduced text for clarity
BYTERANGE:10@5
segment.ts
BYTERANGE:20
segment.ts
DISCO
BYTERANGE:20@100
ad.ts
BYTERANGE:15
ad.ts
DISCO
BYTERANGE:30
segment.ts
The idea with this playlist would be SSAI being injected into an otherwise continuous playlist, and the expectation is that the last segment would have a range of 30@35
We could track the lastByterangeEnd per segment uri to support this use case (if its even a valid one). If we wanted some protections in place, we could default to 0 for when we encounter a byterange without an offset for a specific uri for the first time and trigger a warning, or outright reject like the spec recommends, or do nothing and let things potentially break since its breaking the spec regardless.
There was a problem hiding this comment.
Interesting point, and I'm not sure what the spec is implying. The way I read it is that when they use the term "previous" they are referring to the segment immediately preceding, if only because the first sentence says "the previous Media Segment" instead of "a previous Media Segment" like it does in the following. If "previous" could mean any prior segment, then those two statements conflict (unless "the previous Media Segment" is a defined as the segment determined to be the previous one).
So I guess it depends on the definition of "previous." I'm inclined to be strict here, if only because it reduces complexity of the code (no need to manage extra state), and it is easier to relax restrictions in the future than to add on new ones once the spec's definition is clarified.
There was a problem hiding this comment.
I think @mjneil is on point here in his interpretation.
There was a problem hiding this comment.
There was a problem hiding this comment.
(I still think my interpretation is correct, but I concede)
There was a problem hiding this comment.
Thanks for checking. One other thing retaining prior segment info might lead to would be possible corner cases. Dealing with them may be going overboard, but comparing two URIs might involve checking for things like relative paths versus absolute paths, and different forms of the two (for instance, if a 24/7 live stream changes its URI format after an insert/ad break). Again, that might be overboard, but we can always add support for the any prior segment interpretation in the future if the spec's definition becomes clearer.
…egment (videojs#98) The default value for EXT-X-BYTERANGE is defined by the spec as the first byte after the previous segment. Prior to this change, the default set by m3u8-parser was 0.
The default value for EXT-X-BYTERANGE is defined by the spec as the first byte
after the previous segment. Prior to this change, the default set by m3u8-parser
was 0.