Exoplayer fails to initialize after multiple release timeouts

Background: We heavily use exoplayer in our app - we have 10+ various screens that play a video inside. We do not use shared instance of exoplayer, so each screen may init its own player for the playback thus we very often release them (as well as underlying MediaCodecs). To catch any missed player.release and avoid perf regressions (e.g. playing a video in invisible fragment), we have a global debug check that no more than 2 players are in prepared state, and no more than 1 player is in playing state at the same time.

We’re on a custom hardware (android 6). This device has mediatek’s AVC/HEVC codecs (we have mixed content, but moving forward with hevc)

Recently we started seeing increased amount of such playback erros (we use custom 2s timeout comparing to 500ms in the library)

com.google.android.exoplayer2.ExoTimeoutException: Player release timed out.
    at com.google.android.exoplayer2.ExoPlayerImpl.lambda$release$5
    at com.google.android.exoplayer2.-$$Lambda$ExoPlayerImpl$eZVQ1P4AuRBXX3IBVzj-JmjEs8k.invoke(_:0)
    at com.google.android.exoplayer2.util.ListenerSet$ListenerHolder.invoke
    at com.google.android.exoplayer2.util.ListenerSet.lambda$queueEvent$0
    at com.google.android.exoplayer2.util.-$$Lambda$ListenerSet$NbKDn9xtItiyMgYZmjIx_Sv1FFQ.run(_:0)
    at com.google.android.exoplayer2.util.ListenerSet.flushEvents(_:191)
    at com.google.android.exoplayer2.util.ListenerSet.sendEvent
    at com.google.android.exoplayer2.ExoPlayerImpl.release(_:854)
    at com.google.android.exoplayer2.SimpleExoPlayer.release(_:1674)

Sometimes it fails with timeout during detaching a surface. Probably it's related to upgrade from 2.13 to 2.15.1 (Probably, because we continue release new features related to videos, so it could be related to increased amount of `prepare` -> `release` cycles), but I didn't find anything relayted to it in the changelog / sourcecode

To reproduce it I built a screen containing 9 PlayerViews (3x3 grid) and repeatedly playback a video in these views. Each 10-120s (randomly) I restart the playback (release all the players, and recreat them again). Sometimes issue start to happen quickly, sometimes it may take a time (like 30 minutes+) to start happening. After a few first timeouts it simply can’t init a new player (with no error, but sometimes it seems it can thow smth like MediaCodecVideoRenderer error, index=0, format=Format), but if attempts to start a playback continues (in user case they navigate to and from the screen with player) device may enter into non-recoverable ANR (touches won’t help, ANR dialog doesn’t appear, only power-off may help). I tried to minimize this reproducer and move it to exo’s demo app and end up with https://github.com/denis-bezrukov/ExoPlayer/commit/cc6fb7f65e865e1a994b1f3a62aa0065797e5968 (To ensure .release() is called for every player this sample has counter that incremented each time player created, and decremented each time .release() is called. Also don’t care onStop is not handled and coroutine is not cancelled - steps do not include closing this activity)

I will also submit a anr trace example to the [e-mail]

I searched through the issues, but all I found is related to DRM or Dummy Surface workaroun. Our codecs don’t work nicely with Dummy surface, but overriding codecNeedsSetOutputSurfaceWorkaround (since it’s custom device, it is not blacklisted in the library) to true didn’t seem to help in this case and the issue is still reproducible.

I don’t want to put a lot of random info here, so please let me know if I can collect any useful info that may help to track down the issue.

[christosts]

@adamvernier can you please file a separate issue, considering adding the information requested in the issue template? So far, this issue seems to be related to a custom device with Android 6 and running ExoPlayer 2.15.1 whereas your setup is likely to be different, and I’d like to not mix the conversations* otherwise it will be confusing.

Thanks

• at least not until we can verify the issue has the same root cause 😃

[denis-bezrukov]

@christosts

We knew already it was a flush but my first guess was that the MediaCodec instance for video would block rather than the audio one.

I updated my previous reply and it seems to be a general “codec” issue, since I see the same pattern (there is a pre flush but no post flush) for both audio and video codecs.

It might be worth trying forcing this behavior on your device too, e.g. you can override MediaCodecAudioRenderer.flushOrReleaseCodec() to always release the codec. Note that I have not tried this.

Just tried it (for both audio and video) and it does seem to work, on the other hand release process became too long:

2022-02-24 05:43:19.153 15394-17694 Codec [19308084] video/avc pre release
2022-02-24 05:43:22.193 15394-17694 Codec [19308084] video/avc post release
2022-02-24 05:43:22.303 15394-17694 Codec [19308084] audio/mp4a-latm pre release
2022-02-24 05:43:25.310 15394-17694 Codec [19308084] audio/mp4a-latm post release

As you can see the full release process took ~6s

I am also concerned that I will do that for position reset (seek) so it will look worse. According to our tracking system, the issue happens for ~2-3% of devices so I am not sure we’re ok with that tradeoff. So I would be interested to continue investigating the issue.