Exoplayer: Improve video start time when using lower buffer size in LoadControl

[arjun-redspace]

I'm upgrading from ExoPlayer r.1.5.9 to r.2.2.0 and wondering if I can use and suppy buffer size lower than default values.

LoadControl implementation (DefaultLoadControl) has a targetBufferSize which is calculated when a track is selected and it is equal to sum of default values of renderers present in the selected track. In a typical track, there would be four renderers, video (12.5 MB, DEFAULT_VIDEO_BUFFER_SIZE), audio (3.375 MB, DEFAULT_AUDIO_BUFFER_SIZE), text (128 KB, DEFAULT_TEXT_BUFFER_SIZE), meta data (128 KB, DEFAULT_METADATA_BUFFER_SIZE) and equal to 16.125 MB. In the earlier exoplayer version, buffer size can be supplied through HlsSampleSource and it was around 3 MB which is four or five times lesser than current target buffer size and android memory monitor showed that the app with ExoPlayer 2.2.0 uses an extra memory of 5 to 10 MB.

Objective:
Decrease the memory usage of the app and bring it closer to exo player r1.5.9.

Questions:

1. Is it recommended to create a custom LoadControl to address the higher memory usage?
2. If creating a custom LoadControl is recommended, then what could be a minimum buffer size that can be used that doesn't affect video start time (time required to see the first frame after clicking load button)?
3. Does reducing buffer size affects/increases video start time? If so, what part of the exo player r2.2.0 should I address to decrease video start time.
4. Does changing DefaultAllocator default buffer size from 64 KB to 256 KB has any affect on above scenario?

I have tried to address the memory usage by creating a custom LoadControl that takes targetBufferSize which is closer to old exo player buffer size but I have noticed some delay in seeing the first frame after hitting load button. Also, there was no significant drop in memory usage.

DefaultAllocator used is 256 KB
Please advice on recommended steps or documentation regarding targetBufferSize and LoadControl.

[ojw28]

Is it recommended to create a custom LoadControl to address the higher memory usage?

If you want non-default buffering policy, then yes this is the recommended way to do that. Note you can also configure DefaultLoadControl to some extent, by passing different values through one of its constructors.

If creating a custom LoadControl is recommended, then what could be a minimum buffer size that can be used that doesn't affect video start time (time required to see the first frame after clicking load button)?

The size of the buffer doesn't have any effect on start time, unless you make it so small that playback is essentially broken. The bare minimum size depends somewhat on the details of the media you're trying to play; I wouldn't recommend trying and push it too low.

Does reducing buffer size affects/increases video start time? If so, what part of the exo player r2.2.0 should I address to decrease video start time.

As above, the buffer size shouldn't have any effect on the video start time. LoadControl's shouldStartPlaying method can be tweaked to have playback start more aggressively. You can also tweak the parameters passed into DefaultLoadControl's constructor to do this (e.g. making bufferForPlaybackMs and bufferForPlaybackAfterRebufferMs smaller than the default values allows playback to start earlier).

Does changing DefaultAllocator default buffer size from 64 KB to 256 KB has any affect on above scenario?

No.

[kedrovski]

One interesting moment, video start time increased since r.2.1.0 (black screen in start about 0.5sec). I noticed that this can be avoided by use SurfaceView instead SimpleExoPlayerView in layout. And in code using player.setVideoSurfaceView(surfaceView); instead simpleExoPlayerView.setPlayer(player). Checked in r2.4.2.

[ojw28]

For what it's worth, I can't think of any technical reason why that would be the case (and I'm doubtful it is). What you're suggesting doing is basically what SimpleExoPlayerView does internally by itself anyway, so it's hard to see how one would be significantly slower or faster.

Closing this issue, since the original questions have been answered. Thanks!