search

google / ExoPlayer

This project is deprecated and stale. The latest ExoPlayer code is available in https://github.com/androidx/media
https://developer.android.com/media/media3/exoplayer
Apache License 2.0
21.7k stars 6.02k forks source link

Updating the master HLS playlist to only contain a single variant shows significant performance improvements #7817

Open greyski opened 4 years ago

greyski commented 4 years ago

[REQUIRED] Searched documentation and issues

I was reading this blog post, but it doesn't directly assess the implications of having only one variant on the HLS playlist.

[REQUIRED] Question

We recently experimented limiting the number of variants in the master HLS playlist and found perf (loading time) improvements. We would typically have 4-7 variants per video (360, 240, 480, 640, 720, 960, 1280), and when we started limiting the list to just one (either 360, 480, 640) we saw a huge (100s of ms) improvement in time between prepare-ing the video URI, to the first frame rendered/played.

Why does supplying a single variant instead of the whole master HLS playlist improve load times? I imagine there's a lot of work being done under-the-hood of Exoplayer in how it chooses a variant to play from the HLS playlist, but am having trouble pin-pointing where in the Exoplayer source this overhead exists. I would greatly appreciate any link to the source or a description of what's going on under-the-hood that could cause this overhead.

A full bug report captured from the device

N/A

Link to test content

N/A

marcbaechinger commented 4 years ago

Which variant does the player choose when you have 7 variants? Can it be that it takes a much higher quality than when you use just one variant?

Can you measure the latency from prepare to first frame rendered when you are only using the 1280 variant for example?

greyski commented 4 years ago

It should pick the first one variant to start with, and ramp up after a little bit.

It'd be difficult to measure that for an individual variant.

Perhaps the player ramps up to 1280 very quickly, and then stays at 1280.

marcbaechinger commented 4 years ago

I think the default bandwidth meter might start with a higher variant when eg. on WIFI.

Interesting would be to do the same experiment with a single variant ("either 360, 480, 640") and that variant is the 1280 variant. Agreed that this is a totally uneducated guess from my side, sorry about that. But when measuring first frame latency the quality of the variant looks like a significant factor at first sight.

Can you please run both streams in the demo anpp and then do a bug report and upload it here? The demo app has the EvenLogger configured which should give us all the information we need to see the behaviour.

mrstux commented 1 year ago

Exoplayer loads the first variant in the manifest, then selects an initial variant based on the bandwidth meter, then loads that variant (if it hasn't already been loaded), before loading segments from the initial variant.

When there is only one variant, they are the same, and thus there is no wasted load.

8826 goes into more detail.

And yes, it would be good if this was improved, as loading a variant can easily take 100+ms.