Lack of "STATE_ENDED" when playing video in tunneling mode (Exoplayer 2.11.*)

[AGasztold]

Issue description

There is no STATE_ENDED while playing video in tunneling mode. I have checked on Exoplayer Demo app with DASH/HLS materials, but all of them did not stopped at the end of the stream (timestamp was still increaasing). We need to call stop() to end the playback, but in this case, STATE_IDLE is only received.

Version of ExoPlayer:

Exoplayer 2.11.7 but checked also with Exoplayer 2.11.0

Device:

Sagemcom STB

[krocard]

Since 2.11.0 (see 5579cc8), end of stream in tunneling is detected with MediaCodec.OnFrameRenderedListener magic value callback

Presumed root cause

If your device decoder does not send that callback, ExoPlayer will never detect the end of stream.

Validating the root cause

Could you please add a log line just before
https://github.com/google/ExoPlayer/blob/r2.11.7/library/core/src/main/java/com/google/android/exoplayer2/video/MediaCodecVideoRenderer.java#L1866
logging the presentationTimeUs received.
If you do not see the EOS timestamp, which is Long.MAX_VALUE (18,446,744,073,709,551,615) logged after the stream ended, it validates the analysis.

Workaround

If the missing EOS timestamp is indeed the issue, please edit codecNeedsEosPropagationWorkaround to return true for the tunneling decoder the issue was observed with.

(The decoder name can be found in the logcat or you can add log it in codecNeedsEosPropagationWorkaround first).

Upstreaming the workaround

Could you please post here the name of the tunneling decoder, we will merge the workaround in the next release.

[AGasztold]

Hi,

Thank you for your answer. You were right.

1. There was no EOS timestamp after stream was ended.
2. I have added condition with codec name: ("OMX.broadcom.video_decoder.tunnel").equals(name) to codecNeedsEosPropagationWorkaround and it worked (processEndOfStream() was called and STATE_ENDED was set properly).
   Best Regards!!

Agnieszka

[andrewlewis]

@jyee-brcm FYI: it looks like this Broadcom decoder is not producing the expected end-of-stream buffer in tunneled mode. I think we are planning to start verifying this behavior in an upcoming CTS release (@krocard can confirm).

[AGasztold]

Hello, we have also seen this codec: "OMX.broadcom.video_decoder.tunnel.secure" on different Sagemcom STB with EOS issue. For my purposes I finally put following condition: Build.MANUFACTURER.equals("Sagemcom"), but checking if codec's name contains: "OMX.broadcom.video_decoder.tunnel" might be enough.

[krocard]

I think we are planning to start verifying this behavior in an upcoming CTS release (@krocard can confirm).

That is correct, starting with Android 11, CTS will fails if a tunneling codecs does not report EOS (timestamps are also tested):

https://android-review.googlesource.com/c/platform/cts/+/1225935
https://cs.android.com/android/platform/superproject/+/master:cts/tests/tests/media/src/android/media/cts/CodecState.java;l=385?q=onFrameRendered%5C(

[krocard]

I'll merge a change to add OMX.broadcom.video_decoder.tunnel.secure to codecNeedsEosPropagationWorkaround. It should be available in the next release.

[krocard]

The fix will be available in 2.12. Thanks for reporting the issue and validating the workaround.

[AGasztold]

Please remember about both codecs: OMX.broadcom.video_decoder.tunnel.secure and OMX.broadcom.video_decoder.tunnel (checked on different Sagemcom STB).
Thank you for your help!

[krocard]

Thanks, I had indeed missed the difference, thankfully @ojw28 caught it in review. Both OMX.broadcom.video_decoder.tunnel.secure and OMX.broadcom.video_decoder.tunnel have been added to codecNeedsEosPropagationWorkaround.