Transparent/invisible image with 30-bit color Linux

OS: Debian Linux 10.8

VLC versions: git master and 3.0.12-1-0-gd147bb5e packaged with Debian

Reproducibility: Occurs every time, on every file tested.

Steps:

• Change X11 to use 30-bit (10-bit per color component) color:

        $ cat /etc/X11/xorg.conf.d/30-screensetup.conf
        Section "Screen"
          Identifier    "Default Screen"
          Monitor        "Configured Monitor"
          Device         "Configured Video Device"
          DefaultDepth    30
        EndSection

• Restart computer so that changes take effect
• Play any video file in VLC. The image will be transparent and barely discernible.

The pattern you can see in the bottom half is the default Debian desktop background, leaking through the semi-transparent video - the video should not have transparency

Added attachment:

• Screenshot from 2021-02-07 22-10-20.png

added Component::Video: X11 label

Need VLC logs. Also xdpyinfo output would be nice...

Terminal output with -vvv

Added attachment:

• 30bit_err.log

Output of 'xdpyinfo' with no arguments

Added attachment:

• xdpyinfo.txt

Does it work w/o hardware decoding acceleration and/or w/ another output that OpenGL?

This might be a bug in the VA-to-GL converter. Otherwise, I don't see at which point VLC would be involved.

I did:

Tools > Preferences > Input / Codecs > Hardware-accelerated decoding: changed from "Automatic" to "Disable"

Tools > Preferences > Video > Output: changed from "Automatic" to "X11 video output (XCB)"

I have the same results (transparency and hard-to-see output) but now I see this repeated in the logs:

[00007f500402e750] blend blend error: no matching alpha blending routine (chroma: RGBA -> ARGB)         
[00007f500402e750] main blend error: blending RGBA to ARGB failed

It's also possible that the colors - as much as they are visible - are more messed up than before. Will attach another image.

I also notice that after switching to X11 output, the black bands past the edge of the video are now opaque instead of transparent. The video is still partially transparent, though.

Video output X11

Added attachment:

• Screenshot from 2021-02-15 13-58-50.png

Video output Automatic (notice green vs. pink, and transparent instead of opaque band on the side)

Added attachment:

• Screenshot from 2021-02-15 13-58-23.png

Results are very similar or the same whether hardware-accelerated decoding is set to "Automatic" or "Disable"

Replying to [comment:4 ami-ndfv]:

I have the same results (transparency and hard-to-see output) but now I see this repeated in the logs:

[00007f500402e750] blend blend error: no matching alpha blending routine (chroma: RGBA -> ARGB)         
[00007f500402e750] main blend error: blending RGBA to ARGB failed

That means 2 things:

• VLC cannot blend RGBA SPU (in software) onto ARGB, and
• the X11 window pixel format is recognized as ARGB. Looking at the depth and masks in xdpyinfo, this is in fact correct, so it sounds like a bug in swscale or the swscale plugin or whatever is doing the chroma conversion.

Not that I'd know without logs.

mentioned in issue #25526

On the latest git master (d5836cb3, 2021-04-09), changing Video > Output from "Automatic" to "X11 video output (XCB)" causes it to immediately crash with an assertion failure. Here's the full log: x11out.txt

On d5836cb3 (2021-04-09), I now see visual results very similar to the bug in #25526 , with or without Input / Codecs > Hardware-accelerated decoding: changed from "Automatic" to "Disable":

Here's what it should look like (grabbed with ffplay): And here's what it actually looks like:

Here's the full -vvv output for:

Input / Codecs > Hardware-accelerated decoding: "Automatic": auto_decoding.txt

Input / Codecs > Hardware-accelerated decoding: "Disable": sw_decoding.txt