google / ExoPlayer

This project is deprecated and stale. The latest ExoPlayer code is available in https://github.com/androidx/media
https://developer.android.com/media/media3/exoplayer
Apache License 2.0
21.7k stars 6.02k forks source link

2 second buffering at video decoder causes frequent re-buffering #4571

Open peddisri opened 6 years ago

peddisri commented 6 years ago

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


peddisri commented 6 years ago

Related issue: https://github.com/amzn/exoplayer-amazon-port/issues/42

AquilesCanta commented 6 years ago

@ojw28, would you mind taking a look?

ojw28 commented 6 years ago

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 ;).

peddisri commented 6 years ago

Can you send your address to pii-ExoPlayer-core@amazon.com ? We'll check internally if we have spare devices to share.

peddisri commented 6 years ago

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)

ojw28 commented 6 years ago

Email sent; thanks!

PratimMallick commented 4 years ago

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?

setmind commented 2 years ago

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.