Lazy-load HLS media playlists on adaptation #1936
Comments
|
This is working as intended right now. It's part of our architecture that we need metadata for all streams upfront. We may be able to fix this limitation in a future release. The earliest release we might be able to accomplish this in is v2.7. |
joeyparrish
changed the title
joeyparrish
added
type: enhancement
|
I'm rephrasing this as an enhancement to lazy-load the media playlists when we adapt. |
joeyparrish
added
the
priority: P1
|
@joeyparrish I saw the item above is in progress. Do you know if there is an ETA to rollout the release on Shaka player to general user? thanks! |
|
We ran into issues with this that caused us to pause the work and switch focus to containerless formats (HLS packed audio) instead. The team's resources are very limited right now, and we have no ETA at this time. |
|
Hello @joeyparrish, Do we have any update on this bug because we are also facing the same problem. We have 13 audio files and 3 Media streams and every time it downloads all 13 + 3 which is bad for our CDN gives 508 on some request. The behavior expected is it should only download the media and the currently using audio from the playlist. can you please respond on the ETA for this bug? |
|
@hiren3897 I have seen that @joeyparrish has a commit in his backup with this: joeyparrish@1f31570 I think if you need this functionality fast, the best thing is that you create a PR for it. |
|
That's a backup of a work-in-progress from a member of the team at Google. We're shutting down an internal git repo, and that work needed to be moved to GitHub so that it could be continued at a later date. The author is currently on leave, and the work isn't complete. If someone else wants to continue the work, that's great. But you can't just put that commit into a PR and expect it to be merged. |
|
hello @joeyparrish Can you please tell me when this joeyparrish@1f31570 will be completed and released because we are in hurry and we have a lot of problems when not having this feature Reason: The behavior expected is it should only download the media and the currently using audio from the playlist. can you please respond on the ETA for this bug? Is there any way where we can handle this for the moment because we have a live event on 22 Feb and we need to fix and have this feature ready to handle Live HLS streams? Please anticipate a response!! |
|
Nobody is working on that right now. The person who began that work is currently on leave. If somebody else wants to resume the work, they may, but there's currently nobody assigned to it at Google. We only have two engineers (myself included) working on Shaka Player at Google at this moment, and we have other priorities to address, including improving the infrastructure for community contributions. We don't want to be the bottleneck, and we know that for now, we still are. We apologize! The good news is that the work we just merged for #2337 will simplify the changes needed to resolve this issue. The bad news is that there are very likely to be merge-conflicts when someone rebases that work in-progress you referenced. If you have an event on Feb 22, I think it is highly unlikely that we will have the implementation complete and tested and released by then. We haven't even closed #2337 yet, as we are still testing and verifying that we haven't broken things like A/V sync edge cases for live HLS. In the meantime, you could always choose to stream DASH, which has sufficient metadata in the manifest to play efficiently without fetching timestamps or init segments from each stream in advance. We apologize for the inconvenience. |
|
Any updates @michellezhuogg on this? |
|
Apologies, but @michellezhuogg has recently left the team. We are grateful to her for the many years she worked with us on Shaka Player! With Michelle moving on, there is nobody working on this at the moment. We will likely release v4.0 without this feature unless someone in the community outside Google takes over the work. If that happens, we still consider this a priority, and would likely resume work on it next for a v4.1 release. |
Now that shaka-project#2337 has been implemented, the error code HLS_INTERNAL_SKIP_STREAM is no longer used anywhere in the code. This retires that error, and also cleans up the code that previously was responsible for handling that error being fired. Pre-work for shaka-project#1936
|
Just a quick update: Now that HLS AES-128 is out in v4.2, this is our next priority for HLS. Our goal is to have the HLS improvement projects cleared by the end of this year, though the work could be completed much sooner. Thanks, everyone, for your patience! If you'd like to pitch in and help get things done faster, feel free to respond to any issue and ask to have it assigned to you. Contributions are always welcome! |
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 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 #1936
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
The changes to implement lazy-loading broke the previous functionality to load media playlists directly, as they are not lazy loaded. This fixes that case, so that lazy-loaded media playlists will correctly set their duration and presentation type. Issue shaka-project#1936 Issue shaka-project#3536
Now that shaka-project#2337 has been implemented, the error code HLS_INTERNAL_SKIP_STREAM is no longer used anywhere in the code. This retires that error, and also cleans up the code that previously was responsible for handling that error being fired. Pre-work for shaka-project#1936
github-actions
bot
added
the
status: archived
Have you read the FAQ and checked for duplicate open issues?
Yes
What version of Shaka Player are you using?
Master
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from
master?Yes
Are you using the demo app or your own custom app?
Demo app
If custom app, can you reproduce the issue using our demo app?
Yes
What browser and OS are you using?
chrome 74.0.3729.131 on windows 10
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A
What are the manifest and license server URIs?
I can't share my media playlist but the two example live HLS of the shaka demo page have the same issue.
What did you do?
Play a hls live stream with multiple profile audio and video.
What did you expect to happen?
That only the two media playlist audio and video of the profile actually display is download
What actually happened?
The media playlist of each video and audio profile is download, 8 media playlist in my case.
The text was updated successfully, but these errors were encountered: