-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
HLS issues with dynamic -> static manifest #4431
Comments
Yes, it appears that maxSegmentEndTime_ is the value that's breaking the seek range. But it doesn't appear to get broken in the transition from dynamic to static. Instead, it seems it is not being updated at all. |
It appears that the behavior of maxSegmentEndTime_ changed in releases 3.2.2, 3.1.4, and 3.0.15, in commit 9220c1f. Even before that change, the seek range was not "sane", though, so there may be more than one layer to this problem. |
I think I've found three changes needed to fix this:
I have this working locally with your test content (thank you for sending that!) but I still need to clean up the change, update tests, and write a few new ones. |
There's one caveat so far. The test content you sent us privately does something odd, and this results in an odd UI. With the parameters I'm giving for start and end times (now - 30s, now + 30s), when the ENDLIST tags are appended to the playlists, there is one more video segment than audio segment. This results in a weird UI. For example, the duration may be 1:01 (the max of what was appended), but playback stops at 0:57 (the min of what was appended, the max of what can be played). The state and the rest of the UI is still correct (ended state, replay button showing). It also seems like a quirk of the content simulator rather than a realistic issue, so unless someone objects, I'm going to call that good enough. |
@joeyparrish thanks for looking into this. We're aware of this bug and it's being worked on by the provider, we have it on some of our content and it causes the issues you describe. I don't think it should affect the maxSegmentEndTime_ issue, though? (sidenote: it would be great if Shaka threw when that type of a/v segment mismatch causes a stall, it took us quite some time to discover it) |
With the fixes I'm polishing up right now, there is no stall. I just wanted to point out that I'm aware of the weird UI, and that I believe it's caused by the off-by-one issue in the content itself, so I'm not putting any extra effort into that. |
- Keep maxSegmentEndTime_ updated in PresentationTimeline by calling notifySegments on each HLS playlist update, so that the seek range doesn't revert to the original playlist size when it becomes static. - Wait to change the presentation type to VOD until after _all_ active playlists have an ENDLIST tag, to avoid missing the final segments in one type or the other. - Stop updating the playlists after transition to VOD. - Update the MSE duration at exactly the same time as we transition to VOD, to avoid a loophole where the UI knows it's VOD, but doesn't have any way to get the correct duration. Previously, this state would persist until the final segments were appended. Closes shaka-project#4431
fix: Fix HLS dynamic to static transition - Keep maxSegmentEndTime_ updated in PresentationTimeline by calling notifySegments on each HLS playlist update, so that the seek range doesn't revert to the original playlist size when it becomes static. - Wait to change the presentation type to VOD until after _all_ active playlists have an ENDLIST tag, to avoid missing the final segments in one type or the other. - Stop updating the playlists after transition to VOD. - Update the MSE duration at exactly the same time as we transition to VOD, to avoid a loophole where the UI knows it's VOD, but doesn't have any way to get the correct duration. Previously, this state would persist until the final segments were appended. Closes #4431
I'm having issues when testing from
The buffer drops to zero and playback stalls. edit: I'll do some more tests and see if I can get more debug logging debug log that didn't get an error, but playback just stalls
Another log, same issue, buffer drops to zero and playback stalls
Another log with V2-logging
I can verify that the |
@joeyparrish can you review it? Thanks! |
Interestingly enough this only happens in Safari, not in Chrome. player.getConfiguration() output (taken from Chrome)
player.getConfiguration() (taken from Safari)
|
This is also reproducible in the shaka demo app, running locally from Generating a fresh url using const updateUrl = (url) => {
const start = Math.floor((Date.now() / 1000) - 120);
const stop = Math.floor((Date.now() / 1000) + 60);
return `${url}?start=${start}&stop=${stop}`
} and playing in Safari with |
fix: Fix HLS dynamic to static transition - Keep maxSegmentEndTime_ updated in PresentationTimeline by calling notifySegments on each HLS playlist update, so that the seek range doesn't revert to the original playlist size when it becomes static. - Wait to change the presentation type to VOD until after _all_ active playlists have an ENDLIST tag, to avoid missing the final segments in one type or the other. - Stop updating the playlists after transition to VOD. - Update the MSE duration at exactly the same time as we transition to VOD, to avoid a loophole where the UI knows it's VOD, but doesn't have any way to get the correct duration. Previously, this state would persist until the final segments were appended. Closes #4431
fix: Fix HLS dynamic to static transition - Keep maxSegmentEndTime_ updated in PresentationTimeline by calling notifySegments on each HLS playlist update, so that the seek range doesn't revert to the original playlist size when it becomes static. - Wait to change the presentation type to VOD until after _all_ active playlists have an ENDLIST tag, to avoid missing the final segments in one type or the other. - Stop updating the playlists after transition to VOD. - Update the MSE duration at exactly the same time as we transition to VOD, to avoid a loophole where the UI knows it's VOD, but doesn't have any way to get the correct duration. Previously, this state would persist until the final segments were appended. Closes #4431
🤖 I have created a release *beep* *boop* --- ## [4.1.5](v4.1.4...v4.1.5) (2022-10-07) ### Bug Fixes * allow build without text ([#4506](#4506)) ([1db6265](1db6265)) * allow the playback on platforms when low latency APIs are not supported ([#4485](#4485)) ([55d1390](55d1390)) * check for negative rows before moving ([#4510](#4510)) ([31abae3](31abae3)), closes [#4508](#4508) * Filter unsupported H.264 streams in Xbox ([#4493](#4493)) ([1ecede6](1ecede6)) * Fix choppy HLS startup ([#4553](#4553)) ([1675bff](1675bff)), closes [#4516](#4516) * Fix errors with TS segments on Chromecast ([#4543](#4543)) ([15a1c60](15a1c60)) * Fix hang when seeking to the last segment ([#4537](#4537)) ([72a119d](72a119d)) * Fix HLS dynamic to static transition ([932d37c](932d37c)) * Fix HLS dynamic to static transition ([#4483](#4483)) ([932d37c](932d37c)), closes [#4431](#4431) * Fix in-band key rotation on Xbox One ([#4478](#4478)) ([5a8f09c](5a8f09c)), closes [#4401](#4401) * Respect existing app usage of Cast SDK ([#4523](#4523)) ([9c3a494](9c3a494)), closes [#4521](#4521) * **ttml:** Default TTML background color to transparent if unspecified ([#4496](#4496)) ([16da1e7](16da1e7)), closes [#4468](#4468) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
🤖 I have created a release *beep* *boop* --- ## [4.2.2](v4.2.1...v4.2.2) (2022-10-07) ### Bug Fixes * allow build without text ([#4506](#4506)) ([7e93720](7e93720)) * allow the playback on platforms when low latency APIs are not supported ([#4485](#4485)) ([cf8c857](cf8c857)) * check for negative rows before moving ([#4510](#4510)) ([23f39d7](23f39d7)), closes [#4508](#4508) * Filter unsupported H.264 streams in Xbox ([#4493](#4493)) ([914a08a](914a08a)) * Fix choppy HLS startup ([#4553](#4553)) ([950ce69](950ce69)), closes [#4516](#4516) * Fix errors with TS segments on Chromecast ([#4543](#4543)) ([8204db6](8204db6)) * Fix hang when seeking to the last segment ([#4537](#4537)) ([3d6c768](3d6c768)) * Fix HLS dynamic to static transition ([d9ecbf3](d9ecbf3)) * Fix HLS dynamic to static transition ([#4483](#4483)) ([d9ecbf3](d9ecbf3)), closes [#4431](#4431) * Fix in-band key rotation on Xbox One ([#4478](#4478)) ([bc0a588](bc0a588)), closes [#4401](#4401) * Missing AES-128 key of last HLS segment ([#4519](#4519)) ([2c2677f](2c2677f)), closes [#4517](#4517) * Respect existing app usage of Cast SDK ([#4523](#4523)) ([3db2568](3db2568)), closes [#4521](#4521) * **ttml:** Default TTML background color to transparent if unspecified ([#4496](#4496)) ([0b5c985](0b5c985)), closes [#4468](#4468) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
4.2.0
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from
main
?Yes
Are you using the demo app or your own custom app?
Both
If custom app, can you reproduce the issue using our demo app?
Yes
What browser and OS are you using?
Chrome, macOS
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
n/a
What are the manifest and license server URIs?
Will provide manifest link in separate email
What configuration are you using? What is the output of
player.getConfiguration()
?player config
What did you do?
Play a manifest that is dynamic, but will turn static in the future (this is accomplished by using
start
andstop
query parameters )I use
setInterval(() => console.log( player.seekRange()), 1000)
to see the values of seekRange().end updateWhat did you expect to happen?
The content should play all the way to the end.
seekRange().end should increment until the content turns static, and then stay at the max value
What actually happened?
When the content turns static, seekRange.end() will revert back to what it was when the stream started, this could be observed by using
setInterval(() => console.log( player.seekRange()), 1000)
in the console.Here's an example scenario:
Program A starts at 10:00 and ends at 11:00
I start the program from the beginning at wall clock time 10:40, the live point in the progress bar is now at 40 minutes, seekRange().end is at 40 minutes.
I'm watching the program, and the live point (
seekRange().end
) increases as expected.At 11:00 the recording ends, and the manifest goes static, the playhead is at 20 minutes. The live point will now "snap back" to what it was when I started playing, so back to 40 minutes.
When the playhead later on reaches this point, the buffer will drop to 0 and the stream will stall.
In trying to understand this problem, I've changed the
Math.min...
ingetSegmentAvailabilityEnd()
inpresentation_timeline.js
to be aMath.max...
and that will allow me to play the content all the way through.Maybe this means that
this.maxSegmentEndTime_
is not updated correctly when HLS manifests go from dynamic to static?The text was updated successfully, but these errors were encountered: