CodecException: Error 0xffffffff

[KostyaLyapochkin]

Hi. A strange issue has come about in a project.

com.google.android.exoplayer2.ExoPlaybackException: Unexpected runtime error
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:586)
        at android.os.Handler.dispatchMessage(Handler.java:98)
        at android.os.Looper.loop(Looper.java:154)
        at android.os.HandlerThread.run(HandlerThread.java:61)
     Caused by: android.media.MediaCodec$CodecException: Error 0xffffffff
        at android.media.MediaCodec.native_setSurface(Native Method)
        at android.media.MediaCodec.setOutputSurface(MediaCodec.java:1901)
        at com.google.android.exoplayer2.mediacodec.SynchronousMediaCodecAdapter.setOutputSurface(SynchronousMediaCodecAdapter.java:165)
        at com.google.android.exoplayer2.video.MediaCodecVideoRenderer.setOutputSurfaceV23(MediaCodecVideoRenderer.java:1253)
        at com.google.android.exoplayer2.video.MediaCodecVideoRenderer.setSurface(MediaCodecVideoRenderer.java:556)
        at com.google.android.exoplayer2.video.MediaCodecVideoRenderer.handleMessage(MediaCodecVideoRenderer.java:507)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.deliverMessage(ExoPlayerImplInternal.java:1502)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.sendMessageToTarget(ExoPlayerImplInternal.java:1466)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.sendMessageInternal(ExoPlayerImplInternal.java:1441)
        at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:508)
        at android.os.Handler.dispatchMessage(Handler.java:98) 
        at android.os.Looper.loop(Looper.java:154) 
        at android.os.HandlerThread.run(HandlerThread.java:61) 

As I said before this bug arises in the strange way. What happens? I had to add supporting of ad to the project so I used ExoPlayer’s ima extensions. The application supports rotation and I keep the player inside of a retain fragment.

It happens When the first ad is playing and I change the orientation of the device at the same time.
But when the main content is playing after rotation and the ad was in progress and then I try to change orientation again I will catch this exception moreover if I wait for a while and get the next ad and then I change orientation I will not catch this error. In other words I have this bug when rotation was changed when the ad was playing then it ended and then I change orientation again.

However, “codecNeedsSetOutputSurfaceWorkaround” helps to escape this error but I have a little delay therefore It’s not suitable for me.

Finally, Only emulators can work fine. I have this problem on almost all physical devices.
Honestly speaking, I have not been able to repeat this issue in a demo project.

Maybe the problem is that the retain fragment re-creates views... It means that a Surface is not ready to handle the player... Can It happen? I use Widevine DASH

[lcf87]

@andrewlewis Can you take a look? Basically MediaCodec.setOutputSurface errored out when rotating the device while an ad is playing.

[andrewlewis]

Are you handling the SurfaceView surface callbacks in your code? If so, please make sure you are using blocking calls to set/clear the output surface (like SimpleExoPlayer.setVideoSurface/clearVideoSurface), to make sure it can't be destroyed while the player is trying to use it.

There may be informative errors just before the stack trace from setOutputSurface is output, so it would be helpful if you could provide a snippet of logcat just before the error.

If that doesn't shed any light on it then we'd probably need a minimal sample project to reproduce the issue here.

[KostyaLyapochkin]

@andrewlewis Hi, I've decided to explain the error more exactly and how to replay this one:

1. The ad is playing
2. I change the orientation
3. Wait for the ad to end/finish
4. The main content starts playing
5. I change orientation again
6. The error appears

Also I am attaching a list of logs, please, take a look.
logs_exo_player.txt

[KostyaLyapochkin]

@andrewlewis Are there any updates?

[andrewlewis]

This logging just before the first error looks suspicious:

2021-03-31 15:22:48.073 3640-4549 E/SurfaceUtils: native window cannot handle protected buffers: the consumer should either be a hardware composer or support hardware protection

If you play a stream that doesn't require a secure decoder (like the sample streams with ad tags in the demo app) do you see the same behavior?

[KostyaLyapochkin]

@andrewlewis I've checked this case, so If I use HLS or Dash without encryption it will be work well. Actually this error appearance when the app uses DASH with encryption.

[andrewlewis]

Does calling setDrmSessionForClearPeriods(true) when building the content MediaItem make any difference to the behavior you see? I'm not sure about the underlying cause, but I'm guessing it could be related to how the surface is configured by the codec after rotation depending on whether clear/encrypted content is being played. @icbaker may have some ideas.

[icbaker]

I saw that same error message in #8668 - I don't know if the discussion there is any help.

Otherwise I agree with Andrew that the easiest way for us to help would be a minimal reproducible example that demonstrates the problem in a way that we can build locally.

This could be an Android Studio project on GitHub, or zipped up and sent to dev.exoplayer@gmail.com using a subject in the format "Issue #1234", where "#1234" should be replaced with your issue number. Please also update this issue to indicate you’ve done this.

[KostyaLyapochkin]

@andrewlewis @icbaker Hi, I have replied this issue in a little project. I've taken sources from ExoPlayer-Demo and I would like to highlight that the error arise when I use H264. Please, take a look:

https://github.com/KostyaLyapochkin/ExoPlayerErrorExample

I am attaching a video too:

2021-05-19-10-28-51.mp4

[andrewlewis]

Had a quick look at the linked project and I spot any likely causes for this. Did you try setDrmSessionForClearPeriods(true) as I suggested above?

[KostyaLyapochkin]

@andrewlewis Yes, I did. But It has not helped at all.

[icbaker]

I'm unable to reproduce the problem using the linked project and repeating the orientation changes shown in the attached video. I tried on a real Pixel 3a XL and an emulated Pixel 4. In both cases playback continued after the second orientation change.

Do you see this error 100% of the time?

Do you see it on all devices?

[KostyaLyapochkin]

@icbaker

1. Yes, I do. It is really the stable error.
2. Yes, I do. When I do this steps.

For instance, All Android Emulators work without this error and I can't say something about Pixel 3a XL but Pixel 4/4A work as well.

What doesn't work? Galaxy S8 (Android 9), Galaxy S6 Edge (Android 7.1), Galaxy Note 8 (Android 9), Samsung SM T810 (Android 7.1), Galaxy A50 2016 (Android 7.1), Pixel 2XL, Xiaomi Note 7 Pro (Android 10), Xiaomi Redmi Note 8 Pro (Android 9), Huawei Honor 10 (Android 9)

[ojw28]

This is a bug in ExoPlayer, rather than in the underlying platform. Which is good news, since it means we can easily fix it!

The problem occurs when MediaCodecVideoRenderer tries to reuse a previously instantiated non-secure DummySurface with a secure decoder. MediaCodecVideoRenderer should throw away a DummySurface when switching from a non-secure decoder to a secure decoder, and vice-versa.

[ojw28]

This should be fixed by the commit referenced above. We'll get it into 2.14.1.

[saurabharora90]

Hi @ojw28 . I spotted this issue in the changelog for 2.14.1 and realised that we have this issue as well (albeit not the top and hence not something I was actively looking into). Even we weren't using the setDrmSessionForClearPeriods flag but now I have enabled it. Looking at the fix and your comments, it seems like this flag should resolve the issue. Do you have any insights on why it didn't? Would appreciate the insights.

We aren't able to update to 2.14.x right now so I am hoping to resolve the issue with this flag.

[ojw28]

@saurabharora90 - This issue was tracking a specific bug that would cause a ​CodecException: Error 0xffffffff to occur. However, CodecException: Error 0xffffffff is a generic failure reported from the underlying platform, and so it's not the case that all such errors would be caused by the bug that this issue was tracking. There are likely other causes of the same generic failure, some of which are likely in the platform itself. If you have reliable reproduction steps for causing such a failure, please file a new issue containing all of the information requested in the issue template.