Grey bars when playing HDR content on Bravia Android TV

Description

Grey bars appear above and below HDR content

Expected behavior

Black bars appear around content

Actual behavior

Grey bars appear around content

Steps to reproduce

1. Play HDR content

Screenshot / video

Context

App version

Android version

8.0.0

Device model

Sony Bravia X900F

App mode

TV

Do you have a screenshot or a photo of the issue?

Can you please disable OpenGL ES2 in the Advanced settings and see if you still encounter the issue?

I still encounter the issue even with OpenGL ES2 off.

Please share your logs.

added Needs more info VLC core labels

correct_playback_no_grey_bars.txt

grey_bars.log

The requested logs. E01 plays back correctly, but E02 have the grey bars.

Issue still present in latest version of VLC (3.2.6) on a Sony Bravia X90G.

The problem is (was) present in various players and apps on that TV platform.

E.g. see here: https://community.sony.co.uk/t5/android-tv/amazon-prime-4k-hdr-grey-letterbox/td-p/2278204/page/4

Tracked as an issue for the platform here: https://github.com/CiNcH83/bravia_atv2/issues/44

The suggested workaround is to change from black background to transparent: https://github.com/MrMC/mrmc/commit/e686c40a50c8474300571dc62b0a5a8c3b519604

I.e. the black declared in the application is not treated as the black of the HDR "canvas".

Please fix it or make it an option / switch in the app.

added Android TV label

We won't change the background of our app (which will lead to other problems) because a manufacturer renders the black background as grey.

This is a Bravia problem.

Closing.

closed

I also have the grey bar problem. I have a Sony 8AG

Appears to be an issue with VLC. Other media players do not have this issue, whether that be the built in video app/Kodi etc

Kodi seems to have the same issues when playing as HDR. In any case, the issue is already closed because it's an issue in the device surface implementation.

@Aza This has been solved in Jellyfin (the fork of Emby) without creating additional issues. https://github.com/jellyfin/jellyfin-androidtv/pull/369

reopened

Is the VideoLAN team willing to change their position on this? Jellyfin has managed to solve this issue with no ill effects.

Did you use 3.3.1?

I can confirm, that this still happening with the 3.3.1 build of VLC on a Sony Bravia X90G. Latest updates are applied to the TV (there were 2 updates for the past 9 months).

Adding transparent increases the overdraw. This is not acceptable.

Maybe transparent is not a good way to go due to overdraw and performance.

But could that be just a colorspace mismatch for the background color of the player? I mean, the black of the video is black on the screen, but the surrounding background of the player color is grey in the resulting composition.

Other players were simply using Color.BLACK to fill the background (I couldn't find the VLC code for that in the hurry). And avoided the situation by using transparent color. But there are several ColorSpaces in Android(not to mention OpenGL/Vulkan), some more exotic then simple [0..255]/[0..1] range, i.e. look here:

https://developer.android.com/reference/android/graphics/ColorSpace.Named https://developer.android.com/reference/kotlin/androidx/compose/ui/graphics/Color

Ranges are negative, like [-65504.0, 66504.0] for 16bit color space, but also they are mentioning [-2,2] and [-0.7999 .. 2.399] as well. The conversion from Color.BLACK is failing somewhere in the process.

The hypothesis would be that it can be fixed in the code: either the surface provided by the system is in a different colorspace (like 16 bit RGB), or we would create a surface of wider ColorSpace / bit range just for HDR video. Then we would do the necessary painting with ColorSpace.getMinValue to get the actual BLACK representation.

So my approach would be: a.) either the compisition of the surface is incorrect, i.e. bravia/android takes e.g. a RGB 8 bit surface and composites it incorrectly into a wider gamut/higher bit range surface - in that case we could change the surface color space to wider one, that will be composited correctly (as the HDR video is)

b.) the composition is OK, but the surface is a wider gamut/higher bit range surface to start with and the fill color is computed incorrectly from the named color, i.e. [#000000FF results to <0,0,0> not <-65504, -65504,-65504>]

If you could give it another thought, beyond my above obvious, that would be tremendously appreciated.

Just updated the TV to Android 9.0 with latest firmware. VLC build is 3.3.2. Issue is still present.

So this is definitely a bug in the compositing in Android, as the fullscreen content is composited by Android, and only the video area is done by the GL surface of VLC. Why not make this GL surface fullscreen? Just make sure that VLC renders it in the correct aspect ratio on this GL surface. This way, the letterbox is taken care of by VLC instead of Android.

By the way, why is the glClearColor for VLC transparent, and not solid black, for Android TV? https://code.videolan.org/videolan/vlc/-/blob/master/modules/video_output/android/display.c#L622

So if the composite is done fullscreen by VLC (instead of Android, like I propose), I believe the clear color indeed will need to be fixed to solid black to avoid weird undefined behaviour and be completly sure it behaves correctly on all devices.

I think this is the function responsible for the letterbox layout: https://code.videolan.org/videolan/vlc-android/-/blob/master/libvlc/src/org/videolan/libvlc/VideoHelper.java#L190

marked #1957 (closed) as a duplicate of this issue

marked this issue as related to #1957 (closed)

removed Needs more info label

removed VLC core label

The fix belongs in https://code.videolan.org/videolan/vlc-android/-/blob/master/libvlc/src/org/videolan/libvlc/VideoHelper.java