-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix default EXT-X-BYTERANGE offset to start after the previous segment #98
Merged
gesinger
merged 1 commit into
videojs:master
from
gesinger:fix/byterange-default-offset
Feb 11, 2020
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -20,7 +20,7 @@ | |
{ | ||
"byterange": { | ||
"length": 713084, | ||
"offset": 0 | ||
"offset": 1110328 | ||
}, | ||
"duration": 10, | ||
"timeline": 0, | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.This seems to imply that the subrange begins following the direct previous segment
but then the next sentence
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
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 segmenturi
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 specificuri
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think @mjneil is on point here in his interpretation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's ask Safari
https://d2zihajmogu5jn.cloudfront.net/bipbop-advanced/gear2/byterange_test.m3u8
https://d2zihajmogu5jn.cloudfront.net/bipbop-advanced/gear2/byterange_test_b.m3u8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I still think my interpretation is correct, but I concede)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.