-
Notifications
You must be signed in to change notification settings - Fork 314
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
Question around HLS Low latency behaviour #1240
Comments
Dear Google Team, is there any feedback on this? Please do let me know if any more information is required. |
We're looking at this, will update this shortly. |
Thanks for the reporting! This issue is reproducible from our end. In fact, the reloads of non-primary playlists are triggered from this piece of code, and the purpose of doing that is to check if the segments hinted for preload before have been actually published, otherwise we cancel the loading of it. However, keep reloading those playlists every time doesn't sound ideal to me. We will keep investigating and provide a solution to this. |
Thanks @tianyif for investigating this and sharing the update. One of our customers plan to start using HLS Low latency playback in production soon and is currently testing the same, so we are eager to have a solution for this as soon as possible. Kindly keep us updated with the progress on this investigation and if you have any solution suggestions in the interim, that will be really appreciated. Please do also let me know if I can help in anyway. Thanks. |
Hi @tianyif , hope you are doing well. Is there any further update about fix for this behaviour? |
hey @tianyif : Can you please help provide an update on this one, this behavior is adding to the latency on when trying to playback HLS low latency content. This is important for us to get fixed to get this into production, Can you please take a look at this one on priority. |
Hi @luckygoyal-bitmovin and @mayankmediakind, We're working on a fix for this issue, and we need to make sure that the comments in the internal review cycle are addressed until it is available on Github. Thanks! |
Thanks for the update @tianyif . We will be eagerly waiting for the fix. |
For LL-HLS, the non-primary playlists originally keep reloading even after the primary playlist has been changed to another one. The reason being this is to check if the hinted(#EXT-X-PRELOAD-HINT) resource has been published or removed. If removed, the loading of it should be canceled, per the suggestion in the HLS spec: "A Client SHOULD cancel a request for a hinted resource if it is not present in a subsequent Playlist update, such as in an EXT-X-PRELOAD-HINT tag or as part of another tag such as EXT-X-PART. The client SHOULD ignore the results of such requests." However, keeping the non-primary playlists reloading is not optimal. As a solution, we trigger the playlist reloading only when there is a preload chunk loading instead of every time after we have processed the playlist. Compared to the original implementation, this will save the requests of reloading non-primary playlist after we have taken action upon the preload chunk being published or removed. Issue: #1240 PiperOrigin-RevId: 626038032
Hello @luckygoyal-bitmovin, We just submitted the fix to the main branch, while we did the manual testing with Apple LL-HLS sample stream https://ll-hls-test.cdn-apple.com/llhls4/ll-hls-test-04/multi.m3u8, we encourage you to do more tests with different streams. Please let us know if this improves or causes any regression. |
Hi @tianyif , thanks a lot for the fix. I will test it today and will share my observations. |
Hi @tianyif , I did some initial testing. With the fix, the requests for non-primary video playlists is not sent so the main issue is fixed. But I observed following side effects as well.
|
Thanks @luckygoyal-bitmovin for the observation! The bullet points 1) and 2) are related. For now, in the implementation of And the bullet point 2) and 3) are related on another perspective. In fact, the audio playlist is also refreshed when the As before, I will update in the comment once the above two points are addressed. |
Hi @tianyif , thanks for the feedback. Will look forward to further updates. |
Hi @tianyif , hope you are well. Just checking in if there is any further update on the this issue? |
Hello @luckygoyal-bitmovin, We have a commit merged recently for above follow up issue 1) - e180e26 (looks like there is no tag in the commit linked this issue - sorry!), we're now working on the follow up issue 2). |
Thanks @tianyif for the update. Looking forward to fix for issue 2 as well. |
Hi @tianyif , hope you are well. Just checking in if there is any further update on the fix for follow up issue 2? |
Hi @tianyif , just checking in if there is any further update? As we are getting closer to using LL-HLS in production, this issue is becoming more critical for successful deployment. |
Sorry for the delay! Been working on the other stuffs earlier, but I just sent a fix for internal review. Will try to make it to the upcoming beta01 release. |
Hi @tianyif , thanks for the update and making progress on the fix. I will look forward to test the fix and share my feedback. |
Hi @luckygoyal-bitmovin, do you have a sample HLS live stream with multiple audio tracks that can be provided to us to test? |
Issue: #1240 PiperOrigin-RevId: 642927082
Hi @tianyif , the LL-HLS test stream I have at hand is having one audio track. I am checking around if I can find one with multiple audio tracks. Will update here latest by Monday if I found one. |
Hi @tianyif , I have sent an email to [email protected] containing a HLS-LL test stream URL with mulitple audio tracks. Kindly let me know if this is sufficient for your testing. |
Thanks for the stream URL - it is sufficient for testing! We recently pushed the fix to the development branch, and it should be available in the upcoming 1.4.0-beta01 release. |
I am testing Apple HLS-LL stream with media3/Exoplayer and have observed following behaviour which does not seem optimum. The player is requesting all video variants playlists between downloading video partial segments.
I used Apple HLS-LL reference stream https://ll-hls-test.cdn-apple.com/llhls4/ll-hls-test-04/multi.m3u8 for testing
It has 4 video variants. I captured network traffic of playlist and segment requests using Charles proxy and observed that player is making request for all 4 video variant playlists between downloading consecutive partial video segments. Charles file is attached as zip.
HLS_LL_Apple_multiple_variant_download.chls.zip
The behaviour seems sub-optimal as it will increase load on CDN and would may contribute to increased latency. This test stream has only 4 video variants but a production stream could have 6-8 video variants making the behaviour worse if all 8 video variants are downloaded between each consecutive partial segment download.
Sharing a screenshot of Charles capture showing all variant playlists downloaded between segment downloads
Questions
The text was updated successfully, but these errors were encountered: