-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
feat(HLS): Lazy-load HLS media playlists #4511
Conversation
Incremental code coverage: 99.12% |
@theodab it seems that there are some conflict with the main branch, can you rebase? Thanks! |
This changes the HLS parser so that the media playlists are only downloaded when the createSegmentIndex function for the associated stream is called. Because there is some important information about HLS streams that is stored inside the media playlist, this also changes the player to call createSegmentIndex on the initial variant earlier in the load process, to make sure that information is available in time. Closes shaka-project#1936
This reverts the HLS parser to using per-stream mediaSequenceToStartTime values for VOD, which will allow us to play unaligned HLS streams on that sort of content. Issue shaka-project#4308
6bcab8f
to
1c2a7f7
Compare
Ok, I've merged with main. Just a small merge conflict in the tests, luckily, it wasn't anything of substance. |
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 have tested the change and it works fine.
The only thing that would still make sense for VOD, once a media playlist has been requested, do not request it again, right now if you load a stream and the ABR goes through all the qualities, if it goes through one that has already happened before asking for the playlist again, maybe this information could be stored in memory (maybe a config? for slow devices), what do you think?
It's a trade-off between memory and latency. Perhaps a config to keep VOD streams in memory might make sense for some applications, but I tend to think it's best by default to free up the memory. Shaka could be much better about memory usage in general. |
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.
Only quick comment while I'm still reading hls_parser.js.
} | ||
} | ||
if (createSegmentIndexPromises.length > 0) { |
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 is fine, but JFYI, await Promise.all([])
(empty array) is equivalent to await Promise.resolve()
. It will schedule a microtask and return control back to the interpreter loop, but it won't hurt anything.
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 was worried that it might change the results of some test to have another await in the middle, so I put that in preemptively.
It's almost definitely unnecessary, I agree.
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.
Nicely done!
This changes the HLS parser so that the media playlists are only downloaded when the createSegmentIndex function for the associated stream is called.
Because there is some important information about HLS streams that is stored inside the media playlist, this also changes the player to call createSegmentIndex on the initial variant earlier in the load process, to make sure that information is available in time.
As of this change, we will now require HLS streams to be aligned (see #4308) for livestreams. VOD content can still
be unaligned.
Closes #1936