Skip to content
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

Re-evaluate + refine ExoPlayer's default buffer policy #2083

Closed
WeiChungChang opened this issue Nov 18, 2016 · 12 comments

Comments

@WeiChungChang
Copy link
Contributor

commented Nov 18, 2016

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

This comment has been minimized.

Copy link

commented Nov 18, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Nov 18, 2016

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 ojw28 changed the title shouldContinueLoading's buffering policy Re-evaluate + refine ExoPlayer's default buffer policy Nov 18, 2016
@ojw28 ojw28 removed the question label May 2, 2017
@ojw28 ojw28 assigned tonihei and unassigned ojw28 Nov 23, 2018
@ojw28

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

Reassigning as this is likely to need a performance experiment.

@tonihei

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

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.

@jemshit

This comment was marked as off-topic.

Copy link

commented Dec 24, 2018

Is it make sense if we just simply do download once the buffering data is less than 30 seconds?

minBufferMs=30000L
maxBufferMs=30000L

@whyvas

This comment was marked as off-topic.

Copy link

commented Feb 5, 2019

I can throw my name in the hat for testing on wifi.
I am basically trying to play MPEG-TS multicast UDP video with the least amount of latency possible. I am going from a camera to an encoder to a Samsung Galaxy Tab S3 tablet.
Here is what I've come up with so far, it works but there's still a few seconds of lag regardless of what I set in the loadControl.

BandwidthMeter bandwidthMeter = new DefaultBandwidthMeter(); TrackSelection.Factory videoTrackSelectionFactory = new AdaptiveTrackSelection.Factory(bandwidthMeter); TrackSelector trackSelector = new DefaultTrackSelector(videoTrackSelectionFactory); DefaultLoadControl loadControl = new DefaultLoadControl.Builder().setBufferDurationsMs(100, 400, 100, 100).setTargetBufferBytes(C.LENGTH_UNSET).createDefaultLoadControl(); ExtractorMediaSource mediaSource = new ExtractorMediaSource .Factory(buildDataSourceFactory()) .setExtractorsFactory(new DefaultExtractorsFactory()) .createMediaSource(Uri.parse("udp://@239.255.0.1:1234")); player = ExoPlayerFactory.newSimpleInstance(this.getContext(),trackSelector,loadControl); playerV.setPlayer(player); player.prepare(mediaSource); player.setPlayWhenReady(true);

In this situation, I don't care about old data, I just want to be playing the latest live edge available (smoothly). I do have access to the encoder settings so I can tweak them. I expect it to be adding at least 100ms for encoding. Ideally I can get to 150ms glass to glass.

@NayaneshGupte

This comment has been minimized.

Copy link

commented Mar 19, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2019

@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

This comment has been minimized.

Copy link

commented Mar 27, 2019

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

Thank you!

@tonihei

This comment has been minimized.

Copy link
Contributor

commented Mar 28, 2019

@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

This comment has been minimized.

Copy link

commented Mar 28, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 23, 2019

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.

@tonihei tonihei closed this Apr 23, 2019
ojw28 added a commit that referenced this issue Apr 26, 2019
…ation.

Experiments show this is beneficial for rebuffers with only minor impact
on battery usage.

Configurations which explicitly set a minimum buffer duration are unaffected.

Issue:#2083
PiperOrigin-RevId: 244823642
ojw28 added a commit that referenced this issue Apr 26, 2019
…ation.

Experiments show this is beneficial for rebuffers with only minor impact
on battery usage.

Configurations which explicitly set a minimum buffer duration are unaffected.

Issue:#2083
PiperOrigin-RevId: 244823642
@google google locked and limited conversation to collaborators Aug 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
8 participants
You can’t perform that action at this time.