VLC 3.20.0 cannot hardware accelerate video decoding for 10 bit HEVC.

changed the description

AV_PIX_FMT_YUV420P10LE is a decoded raw video format. Accelerating it does not make sense.
AMD VDPAU drivers are notoriously terrible.
VLC VDPAU support is codec-agnostic anyhow, so if it doesn't work it's down to either VDPAU being disabled in the build, or a problem with FFmpeg or the drivers.

With no further substantial info that would point to a VLC issue, I have to close this, sorry.

P.S.: While it is codec-agnostic, VLC 3.0 is not pixel format-agnostic. Only VLC 4.0 is since !1860 (merged)

closed

added Component::Decoders Hw Platform::GNU/Linux Status::not VLC labels

VLC 3.20.0 offers me the following hardware-accelerated decoding options:

Automatic
VDPAU video decoder
Disabled

So it's not that VDPAU is a good option, just that it is the only option. As of right now, this HEVC video file is falling back to software decoding on my PC, which drops too many frames to be usable.

AV_PIX_FMT_YUV420P10LE is a decoded raw video format. Accelerating it does not make sense.

I am not a graphics programmer, but since VLC demonstrably isn't using VDPAU to decode my example file, you're just making a semantic complaint about my description of the problem rather than addressing its substance.

AMD VDPAU drivers are notoriously terrible.

The VDPAU driver in my current installation of Mesa 24.1.0-devel is good enough for mpv:

$ mpv --vo=gpu-next --hwdec=vdpau <HEVC-File> 
 (+) Video --vid=1 (*) (hevc 3840x2160 24.000fps)
 (+) Audio --aid=1 (*) (aac 6ch 48000Hz)
Using hardware decoding (vdpau).
[ffmpeg/audio] aac: This stream seems to incorrectly report its last channel as LFE[3], mapping to LFE[0]
AO: [pipewire] 48000Hz 5.1 6ch floatp
VO: [gpu-next] 3840x2160 vdpau[yuv420p10]
AV: 00:00:47 / 00:00:47 (100%) A-V:  0.000

Exiting... (End of file)

The mpv playback here drops only 2 frames at most, and is perfectly watchable.

VLC VDPAU support is codec-agnostic anyhow, so if it doesn't work it's down to either VDPAU being disabled in the build, or a problem with FFmpeg or the drivers.

I actually spent a considerable amount of time last night debugging why VLC doesn't select VDPAU, and I observed that in ffmpeg_OpenVa():

p_dec->fmt_out.video.i_chroma = vlc_va_GetChroma(hwfmt, swfmt);

This sets i_chroma = 0 when

hwmt = AV_PIX_FMT_VDPAU
swfmt = AV_PIX_FMT_YUV420P10LE

This causes VLC to follow this branch:

if (p_dec->fmt_out.video.i_chroma == 0)
    return VLC_EGENERIC; /* Unknown brand of hardware acceleration */

My plan for today was therefore to test this patch locally:

diff --git a/modules/codec/avcodec/va.c b/modules/codec/avcodec/va.c
index 0feb03b974..11ec24843f 100644
--- a/modules/codec/avcodec/va.c
+++ b/modules/codec/avcodec/va.c
@@ -79,6 +79,7 @@ vlc_fourcc_t vlc_va_GetChroma(enum PixelFormat hwfmt, enum PixelFormat swfmt)
                 case AV_PIX_FMT_YUVJ422P:
                 case AV_PIX_FMT_YUV422P:
                     return VLC_CODEC_VDPAU_VIDEO_422;
+                case AV_PIX_FMT_YUV420P10LE:
                 case AV_PIX_FMT_YUVJ420P:
                 case AV_PIX_FMT_YUV420P:
                     return VLC_CODEC_VDPAU_VIDEO_420;

My theory is that this could be VLC's equivalent to

$ mpv --vo=gpu-next --hwdec=vdpau --hwdec-image-format=yuv420p <HEVC-File>
 (+) Video --vid=1 (*) (hevc 3840x2160 24.000fps)
 (+) Audio --aid=1 (*) (aac 6ch 48000Hz)
Using hardware decoding (vdpau).
[ffmpeg/audio] aac: This stream seems to incorrectly report its last channel as LFE[3], mapping to LFE[0]
AO: [pipewire] 48000Hz 5.1 6ch floatp
VO: [gpu-next] 3840x2160 vdpau[yuv420p]
AV: 00:00:47 / 00:00:47 (100%) A-V:  0.000

Exiting... (End of file)

which also works fine.

For the record: I have tried applying my experimental patch to VLC 3.20.0, and while I now see this extra message logged to the console:

[00007fb824c12f80] avcodec decoder: Using G3DVL VDPAU Driver Shared Library version 1.0 for hardware decoding

and frames are no longer dropped, the colours are clearly wrong as well. (They have a "washed out" quality.)

It would be interesting to know how VLC 3.20.0 plays this example stream using an NVIDIA card (and VDPAU hardware decoding, of course).

reopened

changed title from VLC 3.20.0 cannot hardware accelerate video decoding for AV_PIX_FMT_YUV420P10LE. to VLC 3.20.0 cannot hardware accelerate video decoding for 10 bit HEVC.

VLC 3.20.0 offers me the following hardware-accelerated decoding options

Upstream VLC supports VDPAU (for NV) and VA-API (for Intel, AMD and Nouveau). If there is a problem with your VLC build rather than upstream, please take if with your packager. Upstream here can do nothing about packaging problems.

According to this Fedora bug report:

Since Fedora 39, VLC is in Fedora main repositories. However, the current VLC version 3.0 requires an old FFmpeg (version 4) in order for VA-API support to work. Fedora 39 contains FFmpeg version 6. For this reason, VLC 3.0 is unable to leverage VA-API support.

This problem should be resolved once VLC 4.0 is released.

This effectively makes VDPAU the only game in town for VLC.

This effectively makes VDPAU the only game in town for VLC.

And that's obviously a Fedora, not upstream, problem.

VLC 3.0 works fine with VA-API and that's the recommended and only supported setup for non-NVIDIA cards as we upstream are concerned. Besides, VLC 3.0 does not support HDR with VDPAU at all, regardless of the avcodec situation.

Besides, VLC 3.0 does not support HDR with VDPAU at all, ...

This is probably my main concern, since I have no way of knowing when VLC 4.0 will be released. But if VLC 3.0 could at least do something reasonable with VDPAU for NVIDIA cards then I could investigate any extra AMD / Mesa problems myself.

you're just making a semantic complaint about my description of the problem rather than addressing its substance.

You are being abusive and I will be ignoring you going forward.

The VDPAU driver in my current installation of Mesa 24.1.0-devel is good enough for mpv

And yet that same driver is notorious for failing under VLC, if not crashing the GPU or the whole system, in cases where the reference API-conforming NVIDIA driver works fine.

You are being abusive and I will be ignoring you going forward.

No, you are just reacting badly to valid criticism, exactly like you did on #27163 (closed) last year.

And yet that same driver is notorious for failing under VLC, if not crashing the GPU or the whole system, in cases where the reference API-conforming NVIDIA driver works fine.

Oh, I agree. But I've been working with the Mesa developers to address those problems before coming here. As I said, mpv is now decoding this exact same HEVC file correctly using VDPAU.

I also notice that you have suddenly raised #4959 to fix a bug that you have just realised exists...

You're welcome!

Since you are insisting on your abuse, you have been reported to admins. You are welcome.

I have no problem discussing anything said here with the admins.

Good day to you.

!4959 (merged) only potentially fixes the problem in 4.0. On 3.0, you're going to have to use VA-API anyway.

closed

mentioned in merge request !4959 (merged)

mentioned in merge request !4960 (merged)

added Status::duplicate label and removed Status::not VLC label

#26903 (closed)

VLC 3.20.0 cannot hardware accelerate video decoding for 10 bit HEVC.

Child items 0

Activity