Open peddisri opened 6 years ago
Related issue: https://github.com/amzn/exoplayer-amazon-port/issues/42
@ojw28, would you mind taking a look?
Gen 3 FireTV is out of stock until August 25th in the UK. We've ordered one, so will take a look at this when it arrives. Alternatively, if you fancy sending one our way a little bit faster, feel free to get in touch ;).
Can you send your address to pii-ExoPlayer-core@amazon.com ? We'll check internally if we have spare devices to share.
BTW, I wound't tag it as a device specific issue. Any device can choose to support a large buffering at input port of video decoder (as the memory capacity of devices increase)
Email sent; thanks!
Is this issue fixed @ojw28. Was facing something similar was playing 4k content on Firestick AFTMM using HEVC decoder @peddisri Did you get any solution to this?
I am experiencing a similar problem with Chromecast with Google TV which uses Amlogic S905D3. I need to play a live TS stream with a sub-second latency, and trying to achieve that by regulating the average value of getTotalBufferedDuration() to 300 ms slowly adjusting the playback speed. This works fine with Qualcomm and Mediatek SOCs but not with Amlogic which keeps switching between BUFFERING and READY states once getTotalBufferedDuration() crosses around 1500-2000 ms.
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