Re-evaluate + refine ExoPlayer's default buffer policy

[WeiChungChang]

Hi all:

I am testing the streaming and find the buffering mechanism is interesting.

By default, the maxBufferUs & minBufferUs are 30 & 15 seconds respectively.

accordingly,
isBuffering = bufferTimeState == BELOW_LOW_WATERMARK || (bufferTimeState == BETWEEN_WATERMARKS && isBuffering && !targetBufferSizeReached);
Typically we will continue buffering until the amount of buffering data is over 30 seconds.
Then it stops buffering to wait until the amount of buffering data is less than 15 seconds and re-fetch again when.

I am wondering what is the purpose it is designed for?
I can not figure out a scenario when it has gains from this policy...
Is it make sense if we just simply do download once the buffering data is less than 30 seconds?
Instead of current policy which waits to the buffering data is less than 15 seconds

Does someone know the intention for it?
Thanks.

[rlatapy-gpsw]

Hi
Same problem/question..
And there is also a constant which limit the buffer size, if I well understand.

What is the proper way to get an "unlimited" buffer in order to buffer the whole video ?

[ojw28]

There are arguments that mobile carriers prefer this kind of traffic pattern over their networks (i.e. bursts rather than drip-feeding). Which is an important consideration given ExoPlayer is used by some very popular services. It may also be more battery efficient.

Whether these arguments are still valid is something we should probably take another look at fairly soon, since the information we used when making this decision is 3-4 years old now. We should also figure out whether we should adjust the policy dynamically based on network type (e.g. even if the arguments are still valid, they may only hold for mobile networks and not for WiFi).

Let's use this issue to track taking another look.

@rlatapy-gpsw - You can't have "unlimited" buffer. Devices are fundamentally constrained. If you want this kind of functionality you probably need to implement media downloading. ExoPlayer doesn't implement download functionality (at least for now), but will happily play downloaded media once you've downloaded it. In any case, your question is different, let's not use this issue for it.

[ojw28]

Reassigning as this is likely to need a performance experiment.

[tonihei]

It's already on the list of potential experiments. Although no experiment with Exoplayer can detect if such a setting makes network operators unhappy :). But the influence on buffer rate and battery usage would be interesting to see.

[NayaneshGupte]

@ojw28 , @tonihei isn't this approach same as keeping minBufferUs and maxBufferUs difference minimum ? or is there any difference ?
Then instead of overriding shouldContinueLoading I can just set 15s and 20s in min and max through builder something like this

new DefaultLoadControl.Builder()
                .setBufferDurationsMs(playerConfig.getMinPlaybackBufferTime(), //15000 ms
                        playerConfig.getMaxPlaybackBufferTime(), //20000 ms
                        playerConfig.getStartupBufferTime(), // 2500 ms
                        playerConfig.getBufferPlaybackAfterRebuffer()) // 5000 ms
                .setTargetBufferBytes(playerConfig.getTargetBuffer())
                .createDefaultLoadControl();

[tonihei]

@NayaneshGupte Yes, that's the same as keeping minBufferUs and maxBufferUs at the same value.

We are likely to change our defaults to that soon as the potential benefit seems to outweigh the extra battery usage.

[thedomi]

@tonihei do you have an update regarding the experiment? Has it been planned, executed, discarded?

Thank you!

[tonihei]

@thedomi As pointed out in the previous post, we are likely to change our defaults. Not done in code yet though. We'll keep this issue posted with updates as soon as we have them.

[thedomi]

Thanks @tonihei for the prompt reply.

I'm also curious whether you've done any experiments, what are the results, how did you reach to the new default values.

[tonihei]

We'll update our default for playbacks with video* to have the same min and max buffer value. That means it will follow the drip-feeding pattern described above. Our experiments showed that rebuffers and the number of format changes went down significantly. At the same time, battery usage increased only very slightly.

(*) We didn't enable this change for audio-only playbacks as the increased battery usage is likely to be more important and we expect less improvement in rebuffers. The actual effect for audio-only playbacks is still to be determined.