Issue description
Amazon's 4K Fire TV Gen3 has a 2 second buffering at the input of video decoder. (HEVC and AVC). This results into substantial amount of frames being queued up at the input of decoder. This 2 second of data in the video decoder pipeline is not accounted for when exoplayer decides it needs to rebuffer and falsely enters into buffering mode. But almost immediately, the check for ready state passes it it comes out from buffering to ready.
This is because decision of buffering to ready uses shouldTransitionToReadyState function that uses current playback position, buffering posstion in loadingperiod and loadcontrol to decide if it has sufficient buffering to come out of buffering state into ready state. This essentially accounts for the buffers queued up at the input port of decoder. However, the decision to enter from ready state to buffering state only checks if renderers are ready or not. This is a problem because when video decoders have large buffering duration, the sources may be emptied faster and renderer will be flaged as not ready. However, the fact that 2 sec worth of data is still queued up at the decoder and ready to be processed is not accounted in this decision. Our proposal is to use similar function as shouldTransitionToReadyState , like shouldTransitionToBufferingState, that makes use of the difference between current playback position and buffering position and load control to decide if it should get into buffering or not, and not just depend on renderReadyOrEnded.
Reproduction steps
Just play any content on this device. However, the repro depends on bandwidth too cause we need to simulate a scenario where decoder consumed 2 sec worth data faster than network could fill it. So its not so easy to repro.
Link to test content
Content agnostic.
Version of ExoPlayer being used
2.8.2
Device(s) and version(s) of Android being used
4K Fire TV Gen3
A full bug report captured from the device
Issue description
Amazon's 4K Fire TV Gen3 has a 2 second buffering at the input of video decoder. (HEVC and AVC). This results into substantial amount of frames being queued up at the input of decoder. This 2 second of data in the video decoder pipeline is not accounted for when exoplayer decides it needs to rebuffer and falsely enters into buffering mode. But almost immediately, the check for ready state passes it it comes out from buffering to ready.
This is because decision of buffering to ready uses shouldTransitionToReadyState function that uses current playback position, buffering posstion in loadingperiod and loadcontrol to decide if it has sufficient buffering to come out of buffering state into ready state. This essentially accounts for the buffers queued up at the input port of decoder. However, the decision to enter from ready state to buffering state only checks if renderers are ready or not. This is a problem because when video decoders have large buffering duration, the sources may be emptied faster and renderer will be flaged as not ready. However, the fact that 2 sec worth of data is still queued up at the decoder and ready to be processed is not accounted in this decision. Our proposal is to use similar function as shouldTransitionToReadyState , like shouldTransitionToBufferingState, that makes use of the difference between current playback position and buffering position and load control to decide if it should get into buffering or not, and not just depend on renderReadyOrEnded.
Reproduction steps
Just play any content on this device. However, the repro depends on bandwidth too cause we need to simulate a scenario where decoder consumed 2 sec worth data faster than network could fill it. So its not so easy to repro.
Link to test content
Content agnostic.
Version of ExoPlayer being used
2.8.2
Device(s) and version(s) of Android being used
4K Fire TV Gen3
A full bug report captured from the device