fix: Fix VTT cue timing in HLS #4217
Merged
Conversation
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
Since the transition to sequence mode for HLS in v4.0.0, VTT cue timings were broken. This is mainly because VTT cue timing in HLS is meant to be based on an offset from the media timestamps, and we generally don't know those now that we use sequence mode. To fix it, this change uses MediaSource segment mode for the very first video segment as a way to extract the timestamp, then clears the buffer, switches to sequence mode, and appends it again. This lets us get the timing data we need, while avoiding major drawbacks of the previous HLS implementation: - We don't need to fetch segments upfront (which is high latency) - We don't need to fetch segments twice (once for timestamps, and once again to buffer) - We don't need to maintain parsers (which were complex and limited the formats we could support) Closes shaka-project#4191
joeyparrish
added
type: bug
theodab
requested changes
May 11, 2022
theodab
approved these changes
May 11, 2022
joeyparrish
added a commit
that referenced
this pull request
May 17, 2022
Since the transition to sequence mode for HLS in v4.0.0, VTT cue timings were broken. This is mainly because VTT cue timing in HLS is meant to be based on an offset from the media timestamps, and we generally don't know those now that we use sequence mode. To fix it, this change uses MediaSource segment mode for the very first video segment as a way to extract the timestamp, then clears the buffer, switches to sequence mode, and appends it again. This lets us get the timing data we need, while avoiding major drawbacks of the previous HLS implementation: - We don't need to fetch segments upfront (which is high latency) - We don't need to fetch segments twice (once for timestamps, and once again to buffer) - We don't need to maintain parsers (which were complex and limited the formats we could support) Closes #4191
nyanmisaka
added a commit
to nyanmisaka/shaka-player
that referenced
this pull request
Oct 6, 2022
This reverts commit 69d1c14.
avelad
pushed a commit
that referenced
this pull request
Mar 16, 2023
…eam (#5079) The VTT cue timing fix in #4217 seems to have caused a regression for videos without VTT streams, where the first segment would sometimes not play smoothly. It also appears to fix the gap jumping seen in the "Art of Motion (HLS, TS)" demo. This was partially fixed for fMP4 in #4553 but didn't fix the issue for MPEG-2 TS. Fixes #4975.
github-actions
bot
added
the
status: archived
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Since the transition to sequence mode for HLS in v4.0.0, VTT cue
timings were broken. This is mainly because VTT cue timing in HLS is
meant to be based on an offset from the media timestamps, and we
generally don't know those now that we use sequence mode.
To fix it, this change uses MediaSource segment mode for the very
first video segment as a way to extract the timestamp, then clears the
buffer, switches to sequence mode, and appends it again. This lets us
get the timing data we need, while avoiding major drawbacks of the
previous HLS implementation:
once again to buffer)
the formats we could support)
Closes #4191