Switching between AC3 tracks causing playback to pause in buffering state

[IanDBird]

I have a sample which includes multiple AC3 audio tracks (2 x 5.1 and 2 x 2.0) for which i've found that when switching between the tracks, the player reports it is buffering to never restart/continue playback. As a user, if I pause the player then resume, playback begins as normal.

Steps to reproduce (i'll send a sample file separately):

• Play the sample
• While it's playing, attempt to select a different AC3 track via setSelectedTrack

I'm using an Nvidia Shield ATV connected to a Yamaha RX-V377 to test this. I've found that switching between AAC to AC3 (and vice versa) works fine. The player reports it's in a state of ExoPlayer.STATE_BUFFERING but attempting to look through things I see:

• ExoPlayerImplInternal has rebuffering set to true
• ExoPlayerImplInternal returns false for all calls to rendererReadyOrEnded
  • This is because the rendererBufferedPositionUs is not larger than positionUs + minBufferDuration. However, I never see it increasing in size and therefore is "stuck".

The sample file also includes a True HD audio track which is one of the reasons I reported #770.

[andrewlewis]

What buffer size are you using to construct the ExtractorSampleSource? The buffer has to store (by default) five seconds' worth of audio and video to transition from re-buffering back to ready.

This particular stream has an average bit rate of 21 Mbit/s, so five seconds occupies 13 megabytes on average. But in practice you will need a larger size to consume spikes in bit rate and deal with coarse interleaving in the container. I found it was possible to play back this particular file and switch between tracks reliably using a 32 megabyte buffer.

[ojw28]

Agreed that the fix is probably to use a larger buffer. A few other points:

• An alternative to making the buffer larger is to pass smaller values for the amount that you require to be buffered for playback to start/resume. These values are passed when creating the player (through the three argument ExoPlayer.newInstance method). You can set them to 0 if you really want to. The downside of this is that the player will constantly flip between buffering and playing in the case where bandwidth is insufficient, which can be jarring. If you're pretty sure bandwidth will be sufficient (e.g. streaming from a device on a local network) then setting them to 0 may well be a good choice, and will allow you to use a significantly smaller buffer size.
• We have Silent failure with too small of a sample buffer #583 tracking a better failure mode for the buffer-too-small case. Current behaviour definitely isn't ideal, however fixing it is non-trivial.
• You'd be much better off not trying to play 21Mbit/s streams, in general.