SimpleExoPlayerView: Set shutter background color method not working on couple Samsung devices

[hare989]

Hello,

Issue description

SimpleExoPlayerView.setShutterBackgroundColor(Color.TRANSPARENT) seems that doesn't work on couple Samsung devices. I found that on Samsung Galaxy S7 Edge (SM-G935F) Android 7, Samsung Galaxy J5 (Android 6) when preparing player (changing source) shutter is black although should be transparent and make last viewing frame visible. It's working fine on other Android 4.4, 6, 7, 8 devices/emulators:
Samsung Galaxy S3 ( Android 4.4), Huawei P9 Lite (Android 6), Xiaomi mi 4 (Android 7.1)

Reproduction steps

I tried programmatically setShutterBackgroundColor(Color.TRANSPARENT) and in XML layout of activity:

<com.google.android.exoplayer2.ui.SimpleExoPlayerView android:id="@+id/player_view" android:layout_width="match_parent" android:layout_height="match_parent" android:focusable="true" app:shutter_background_color="@android:color/transparent"/>

but both doesn't work. I tried also customizing ui components which I found on #3172 but with no luck to customize.

Version of ExoPlayer being used

2.6.0

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

Samsung Galaxy S7 Edge (SM-G935F) Android 7, Samsung Galaxy J5 (Android 6)

[hussanhijazi]

Same problem here with ExoPlayer: 2.6.1 in Motorola XT1563/Android 6 and emulator: Android 7

[ojw28]

What's the use case for the shutter being transparent? If you don't want a shutter wouldn't it be better to remove the view, which would presumably avoid this problem?

[hussanhijazi]

Hi, thanks for your answer. I have a player inside a circular progressbar, and this background player need to be transparent.

My SimpleExoPlayerView
<com.google.android.exoplayer2.ui.SimpleExoPlayerView android:id="@+id/playerView" android:layout_width="108dp" android:layout_height="108dp" android:layout_marginBottom="26dp" app:controller_layout_id="@layout/player_playback_control" app:player_layout_id="@layout/player_view" />
I try use app:shutter_background_color="@android:color/transparent" but is not work.

My player_view.xml

<?xml version="1.0" encoding="utf-8"?> <merge xmlns:android="http://schemas.android.com/apk/res/android"> <com.google.android.exoplayer2.ui.AspectRatioFrameLayout android:id="@id/exo_content_frame" android:layout_width="match_parent" android:layout_height="match_parent" android:layout_gravity="center"> <View android:id="@id/exo_shutter" android:layout_width="match_parent" android:layout_height="match_parent" /> <ImageView android:id="@id/exo_artwork" android:layout_width="match_parent" android:layout_height="match_parent" android:scaleType="fitXY" /> <com.google.android.exoplayer2.ui.SubtitleView android:id="@id/exo_subtitles" android:layout_width="match_parent" android:layout_height="match_parent" /> </com.google.android.exoplayer2.ui.AspectRatioFrameLayout> <FrameLayout android:id="@id/exo_overlay" android:layout_width="match_parent" android:layout_height="match_parent" /> <View android:id="@id/exo_controller_placeholder" android:layout_width="match_parent" android:layout_height="match_parent" /> </merge>

I dont need this player_view.xml ? What view i need remove to do it transparent?

thanks

[hussanhijazi]

Hi, i put this example in https://github.com/hussanhijazi/exoplayerExample .If setting app:shutter_background_color="@android:color/transparent" then the background are black.

thanks

[ojw28]

To clarify: The shutter is something that's put on top of the video surface. The video surface will be either black if no frame has been rendered, or contain the last frame of video. So setting the shutter to be transparent is not expected to ever make the player transparent. All it will do is let you see the video surface underneath, which will either be black or contain the last frame of video.

@hare989's original report is consistent with this (they expect to see the last frame of video because video has been rendered to the surface, but instead see black). I'm not sure what you're describing is really the same issue, since it sounds like you're expecting the player to be transparent, which is not what's supposed to happen.

[hussanhijazi]

Hi, Thanks for your answer. I am using it to play audio.

if i put app:shutter_background_color="@android:color/transparent": Black background

but if i put app:shutter_background_color="@android:color/holo_red_dark" work as expected (red background):

I need this black/red background color to be transparent.

Thanks

[ojw28]

That is expected as per the description above. If you make the shutter red, it will be red. If you make the shutter transparent, it will be transparent and you'll see what's underneath, which is the video surface. Since no video has been rendered, the video surface will be black.

If you're use case is audio only you should consider using PlaybackControlView directly. You don't really need a full SimpleExoPlayerView (which is basically PlaybackControlView plus stuff related to video).

[hussanhijazi]

Thanks, @ojw28 👍

[ojw28]

No worries.

@hare989 - regarding your initial report, can you clarify why you'd want the shutter to be transparent, rather than just removing it entirely? The latter seems a lot less error prone.

[hare989]

Hi, thanks for your answers and sorry for my late response.

One of our clients just liked to see last frame being visible after switching channels or using other apps player features which causes player to change source.

I tried with my custom layout for SimpleExoPlayerView but removing shutter view from it and test this on mentioned devices. (Samsung Galaxy S7 Edge and Samsung Galaxy J5)

And last frame is visible but only with VoD content being source of player. Black screen is still happening when switching player source to Live. Is it possible that preparing player for Live content is somehow producing that black screen?

[ojw28]

It's difficult to see how VoD vs Live would make any difference. At the layers we're talking about (i.e. the codec and the surface), there's no representation of whether something is live or not; it's just a sequence of frames.

• Are you certain the last frame of the previous video isn't all black, for cases in which you're still seeing the issue?
• Do you have any content protection on your streams? Its possible the surface might get cleared to black if the previous video is DRM protected and using the secure output path.

[hare989]

• I'm really uncertain about last frame of previous video. How could I get and see really last frame? Maybe setting simpleExoPlayerView.getVideoSurfaceView().setVisibility(View.GONE); would help as someone suggested on Widevine Modular with HDCP playback fails with CryptoException #2776.
  But wouldn't that means, if the last frame is black, that it should occur on every device? Again, this issue is specific only for some devices.

But all of those above might be irrelevant because there is WV DRM protection on our streams. Is it possible to workaround clearing surface to black to make visible last frame of DRM-ized content?

[ojw28]

Do your license policies require secure output path? If so then I don't think there's an easy workaround. As far as I've been able to work out, the surface is cleared when the codec is released if the secure output path is in use. I've never investigated why this is the case, but I suspect there's a sane reason, or else is a limitation of the secure output path on some architectures. The only way I can think of avoiding the surface being cleared would be to implement #2826, which would be a really good optimization for us to make regardless, but isn't particularly easy to do.

If your license policies don't require secure output path then the workaround would just be to not use a secure codec even if one is available (I'm pretty ExoPlayer will use one by default if it's available for protected content, so you'd need to override to use the non-secure variant, but that's pretty straightforward to do).

[ojw28]

Closing this because it transpired the issue was DRM related rather than being an issue with SimpleExoPlayerView. As above, the only way I can think of fixing it is for us to resolve #2826.