frame buffer cycling when switching between surfaces on certain devices

[stetro]

Issue description

Along with #6294 we discovered frame renderings on previous defined surfaces when changing the surface during playback. This happens on two of our test devices (Honor 10 and Huawei P20)

Reproduction steps

Just run the test application https://github.com/stetro/exoplayer-test on one of the devices (maybe its also happending on mate 10 pro). And press the switch button to switch surfaces during the playback. Activating the Surface workaround in MainActivity resolves the issue.

Link to test content

https://github.com/stetro/exoplayer-test

A full bug report captured from the device

Example Video is send by mail.

Version of ExoPlayer being used

2.10.4

Device(s) and version(s) of Android being used

Honor 10 Android 8
Huawei P20 Android 9

[marcbaechinger]

Can you please capture a full bug report (adb bugreport) just after this happens so we can look into the full logs?

[stetro]

Sure, I provided one by mail 👍

[marcbaechinger]

Thanks! Seems like the hardware codec produces a problem. I'm not going to post contents publicly here from what you sent by email. But you can find the native exception of the hardware codec in your bug report at 08-28 11:25:50.535. This explains why the workaround of your app works, as with this you are using the software codec renderer.

Seems like a candidate for the deviceNeedsSetOutputSurfaceWorkaround workaround.

For the device of the bug report you sent I get this line from ExoPlayerImpl when it's created:
ExoPlayerImpl: Init eac897f [ExoPlayerLib/2.10.4] [HWCOL, COL-L29, HUAWEI, 27]

So the device name to add to the workaround list would be

case "HWCOL":

Can you add this to the source code of MediaCodecVideoRenderer yourself? Just for testing if it helps (and to get you a quick solution in case it helps). I can do this myself but I need to get such a device first for testing. If you confirm that it works with the workaround I'll add the device to the list myself, so it will be in future releases.

[stetro]

Yes I could solve the issue by activating the workaround on this device. Same applies to P20 HWCLT. We currently have the following additional workaround list in an upcoming release to try if this solves customers issues:

            case "HWBLA":           // Mate 10 Pro (HWBLA) - 103 - 27,3 %
            case "HWCLT":           // P20 Pro (HWCLT) - 69 - 18,3 %
            case "HWEML":           // P20 (HWEML) - 66 - 17,5 %
            case "HWSNE":           // Mate 20 lite (HWSNE) - 43 - 11,4 %
            case "HWMAR":           // HUAWEI P30 lite (HWMAR) - 20 - 5,3 %
            case "HWVOG":           // P30 Pro (HWVOG) - 18 - 4,8 %
            case "HWELE":           // HUAWEI P30 (HWELE) - 13 - 3,4 %
            case "HWLYA":           // Mate 20 Pro (HWLYA) - 10 - 2,7 %
            case "HWHMA":           // Mate 20 (HWHMA) - 9 - 2,4 %
            case "HWPOT-H":         // HUAWEI P smart 2019 (HWPOT-H) - 5 - 1,3 %
            case "HWCOL":           // Honor 10 (HWCOL) - 5 - 1,3 %
            case "HWJSN-H":         // Honor 8X (HWJSN-H) - 5 - 1,3 %

Do you need a p20 bugreport as well to add it to the workaround list?

[marcbaechinger]

Ok, cool. Did you physically test with all of these devices and did you find that these are not working without the workaround?

I'd be great if, once you released your app, you could update this issue an confirm success for these devices, so we can see what devices to put in the list on our side.

[stetro]

We, unfortunately, only could test physically on Honor 10 and P20. Sure! I will let you know.

[ojw28]

Note that just adding HWCOL to the big list in codecNeedsSetOutputSurfaceWorkaround isn't going to do anything for the device for which you sent the bug report. The device has SDK_INT == 27, and the code block that contains the big list is only for SDK_INT < 27. You'll need to do it further up around where dangal and HWEML are handled for your change to be effective.

[stetro]

Sure, I have just inherited the Renderer and my setup now looks like this:

 @Override
    protected boolean codecNeedsSetOutputSurfaceWorkaround(String name) {
        Timber.d("codecNeedsSetOutputSurfaceWorkaround() called with: name = [" + name + "]");
        boolean needsSetOutputSurfaceWorkaround = super.codecNeedsSetOutputSurfaceWorkaround(name);

        switch (Util.DEVICE) {
            case "HWBLA":           // Mate 10 Pro (HWBLA) - 103 - 27,3 %
            case "HWCLT":           // P20 Pro (HWCLT) - 69 - 18,3 %
            case "HWEML":           // P20 (HWEML) - 66 - 17,5 %
            case "HWSNE":           // Mate 20 lite (HWSNE) - 43 - 11,4 %
            case "HWMAR":           // HUAWEI P30 lite (HWMAR) - 20 - 5,3 %
            case "HWVOG":           // P30 Pro (HWVOG) - 18 - 4,8 %
            case "HWELE":           // HUAWEI P30 (HWELE) - 13 - 3,4 %
            case "HWLYA":           // Mate 20 Pro (HWLYA) - 10 - 2,7 %
            case "HWHMA":           // Mate 20 (HWHMA) - 9 - 2,4 %
            case "HWPOT-H":         // HUAWEI P smart 2019 (HWPOT-H) - 5 - 1,3 %
            case "HWCOL":           // Honor 10 (HWCOL) - 5 - 1,3 %
            case "HWJSN-H":         // Honor 8X (HWJSN-H) - 5 - 1,3 %
                needsSetOutputSurfaceWorkaround = true;
        }
        return needsSetOutputSurfaceWorkaround;
    }

[stetro]

As described in #6294 (comment) this issue does not belong to #6294 and should be handled separately. It actually does not effect our product and it was just a finding during the ANR investigration. We could reproduce this cycling issue on HWCLT and HWCOL with https://github.com/stetro/exoplayer-test - (the only Huawai devices we currently have on hand)