Question around HLS Low latency behaviour

[luckygoyal-bitmovin]

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

• Is this expected behaviour of Exoplayer? If yes, then what is the rational behind this?
• Is there a configuration to change the behaviour to only download the active variant playlist from which the partial segments are picked for download?

[luckygoyal-bitmovin]

Dear Google Team, is there any feedback on this? Please do let me know if any more information is required.

[tianyif]

Hi @luckygoyal-bitmovin,

We're looking at this, will update this shortly.

[tianyif]

Hi @luckygoyal-bitmovin,

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.

[luckygoyal-bitmovin]

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.

[luckygoyal-bitmovin]

Hi @tianyif , hope you are doing well. Is there any further update about fix for this behaviour?

[mayankmediakind]

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.
cc: @rohitjoins

[tianyif]

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!

[luckygoyal-bitmovin]

Thanks for the update @tianyif . We will be eagerly waiting for the fix.

[tianyif]

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.

[luckygoyal-bitmovin]

Hi @tianyif , thanks a lot for the fix. I will test it today and will share my observations.

[luckygoyal-bitmovin]

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.

• For video playlist, I can see that some of the request are without the LL-HLS server control query params. It seems that with newly added onPlaylistRefreshRequired(lastMediaChunk.playlistUrl) call in case if CHUNK_PUBLICATION_STATE_PRELOAD simply passes the playlist URL and does not add the required query parameters as was done in the original logic loadPlaylistInternal(getMediaPlaylistUriForReload()). Without server control query parameters HLS-LL server will not be able to respect features like blocking playlist reload, delta updates etc.

• For audio playlists all the requests are without server control query parameters.

• Another difference in behaviour is that audio playlist is now refreshed/downloaded at much less frequency now. It seems audio playlist is requested only when the pre-load segment in the previous downloaded playlist is requested. Before this change, audio playlist was refreshed/downloaded after every part segment download. Not sure if this is intended behaviour but lower frequency of playlists download prevents player from knowing about the latest available parts as soon as these are available.