NVIDIA SHIELD flicker green screen, when changeing two players between two views when playing Rec._709 color profile

[fgl27]

Issue description

This issue is similar to my other https://github.com/google/ExoPlayer/issues/7996

I have a Picture Picture mode on my player, one full screen player one small over the full.

I allow to change with is the full or small on one click...

On the NVIDIA SHIELD I have a issue, that if I use PlayerView.setPlayer(SimpleExoPlayer); to change the players between the two views there is flicker green when the video is using Rec._709 color profile

From vlc I can get this information of the media file

Here is a video playing the Link to test content

https://www.youtube.com/watch?v=F1jRCm99sQc&feature=youtu.be

On the above one of the players is using the color profile Rec._709 after a few changes we have the issue only on that one

Unfortunately as we can see the problem is random and may also happen on another case...

This problem may also happen randomly after the player automatic changes the resolution/bitrate (do to a internet slowdown) when playing a master HLS playlist in adaptive bitrate mode.

Reproduction steps

Use the bellow or similar function to do the change

    private int pos = 1;

    private void SwitchPlayer() {
        Log.d(TAG, "SwitchPlayer");

        for (int i = 0; i < 2; i++) {

            PlayerView[i].setPlayer(player[i ^ pos]);

        }

        pos = pos ^ 1;
    }

Link to test content

https://github.com/fgl27/SmartTwitchTV/raw/master/release/githubio/temp/shield_test_clip.mp4

A full bug report captured from the device

bugreport-darcy-PPR1.180610.011-2020-09-28-17-59-39.zip

On the above I have added a log before the change

STTV_PlayerActivity: SwitchPlayer

When the problem happens we have on the log some device specific logs spam as the bellow:

09-27 14:44:19.298  3496  9437 D NvOsDebugPrintf: NvRmPrivFlush: NvRmChannelSubmit failed (err = 196623, SyncPointIdx = 38, SyncPointValue = 0)
09-27 14:44:19.298  3496  9437 I chatty  : uid=1046(mediacodec) omx@1.0-service identical 1 line

There is no Exo specific error on the logs after the problem happens, so is not possible to detect from the player that this has happens, ideally if was possible to detected the player could be restarted to fix the problem, as a release and restart of the player will fix it.

Version of ExoPlayer being used

dev-v2

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

NVIDIA SHIELD 2017 model Android 9

[krocard]

On the above one of the players is using the color profile Rec._709 after a few changes we have the issue only on that one

Unfortunately as we can see the problem is random and may also happen on another case...

This problem may also happen randomly after the player automatic changes the resolution/bitrate (do to a internet slowdown) when playing a master HLS playlist in adaptive bitrate mode.

If I understand correctly, the issue has been seen occuring after a surface change (especially if the color profile is Rec._709) but also on player resolution change.

Implementing the workaround suggested in https://github.com/google/ExoPlayer/issues/7996#issuecomment-702011122 should get rid PlayerView.setPlayer(SimpleExoPlayer). It should solve this issue too.

@andrewlewis have you ever seen this green flickering: https://www.youtube.com/watch?v=F1jRCm99sQc

[fgl27]

On the above one of the players is using the color profile Rec._709 after a few changes we have the issue only on that one Unfortunately as we can see the problem is random and may also happen on another case... This problem may also happen randomly after the player automatic changes the resolution/bitrate (do to a internet slowdown) when playing a master HLS playlist in adaptive bitrate mode.

If I understand correctly, the issue has been seen occuring after a surface change (especially if the color profile is Rec._709) but also on player resolution change.

Implementing the workaround suggested in #7996 (comment) should get rid PlayerView.setPlayer(SimpleExoPlayer). It should solve this issue too.

@andrewlewis have you ever seen this green flickering: https://www.youtube.com/watch?v=F1jRCm99sQc

Please see https://github.com/google/ExoPlayer/issues/7996#issuecomment-702018776, same test I did there changing the size using setLayoutParams was done here and the issue also happens.

Regarding the "especially if the color profile is Rec._709' no only if.

In vlc the streams that don't cause this issue don't display any info on the color used I assume is just basic avc format (don't know the type) see a none Rec._709 streams show like this in vlc, if need I can share a file of the below content.

[andrewlewis]

@andrewlewis have you ever seen this green flickering: https://www.youtube.com/watch?v=F1jRCm99sQc

I don't recall seeing this before. It looks like a device-specific issue that Nvidia would need to investigate. @sureshcnvidia may be able to help.

The repeated logging about E HWComposer: getLayerReleaseFence failed for display -1: Invalid display looks suspicious too.

If you have two players each outputting to a SurfaceView, lock them to the highest bitrate to prevent adaptation and then handle full-screen by a z-order + layout change to swap the position/depth of the two views (no interaction with the players) does the issue still reproduce?

[fgl27]

If I use just setLayoutParams to the two playerViews changing the layout of one with the other, then after parent.bringChildToFront(playerView_nowSmall);...

After a few tries the player that has Rec._709 will have the issue, same as using setPlayer

[fgl27]

After better understanding the issue https://github.com/google/ExoPlayer/issues/7996 I discover that what was causing the flicker green screen when just changing the layout was the way I was fixing the z order like this

playerView_parent.bringChildToFront(playerView);
playerView.setVisibility(View.GONE);
playerView.setVisibility(View.VISIBLE);

By not doing that, using the bellow the problem will not happen.

SurfaceView_Small.setZOrderMediaOverlay(true);
SurfaceView_Full.setZOrderMediaOverlay(false);

SurfaceView_Small is the SurfaceView of the small player that must stay on top, the SurfaceView_Full is the background full screen player, as I allow to dynamically change with will be the full/small I have to do that all the time not just once...

This problem only happens very randomly when the adaptive mode changes the playlist do to bitrate/internet slowdowns (as I explain on first post), the adaptive mode changes is very rare and hard to test, then the issue happens when using the playerView.setPlayer(player); during playback to reuse a player from one view to another when the video be played uses using Rec._709 color profile.

[fgl27]

I made an app based on the demo app for testing this issue

Here is the apk

https://drive.google.com/file/d/1iEoN_ZxEyPvsbai5Tz9JFnEJ73RRibXM/view?usp=sharing

The source repo

https://github.com/fgl27/ExoPlayer/commits/dev-v2_nvidia_test

The source zip

https://drive.google.com/file/d/1rgXtNX39WUxh3xtxT6p4r8k6NMOBVhDN/view?usp=sharing

The change

https://github.com/fgl27/ExoPlayer/commit/67847959e566f6211ee41e8877ad03e835289dea

This was the head of ExoPlayer dev-v2 branch on the day of the above change

https://github.com/google/ExoPlayer/commits/9753c3fcfb2e2e7fd878666c3f8aa11cbee9728f

Here is the result on the device

https://www.youtube.com/watch?v=WpF9Zr0pods

Basically what that app does is change the playerView visibility to GONE and back to VISIBLE after 1 second of Player.STATE_READY then keeps doing again and again it 1 seconds, that is the simple way to reproduce the error if NVIDIA can fix that problem all other cases will be gone, I can properly retest all the cases the day the device OS gets an update.

So please share the issue with NVIDIA.

[fgl27]

The problem persist, there will be any update on this?

I have made the APK share all that was asked, but didn't received any feedback.

[fgl27]

The problem persist, there will be any update on this?

I have made the APK share all that was asked, but didn't received any feedback.

Noting? :confused:

[andrewlewis]

Sorry for the delay. I will try to look at this again soon.

[andrewlewis]

I can reproduce this and have filed a bug to ask Nvidia to take a look [Internal: b/180278815]. I will let you know if/when we hear an update.