H264 YUV 4:4:4 and YUV 4:2:2 video displayed with VDPAU is glitched on MPlayer

I’m using MPlayer, driver 455.45.01 on GT 1030.
While software decoding is fine, but when running with VDPAU decoding, the video is glitchy displayed (the sceenshot taken on machine is just black despite the display is not).
mplayer -vo vdpau -vc ffh264vdpau mandelbrot-h264-444.mp4

nvidia-bug-report.log.gz (457.1 KB)
Sample video used (4:4:4)
Sample video used (4:2:2)
Screenshot taken on the machine


Picture taken from phone

Please check here if it’s even supported:

Thanks, but I can’t understand if it’s is supported or not from that documentation. But based on my vdpauinfo output, I think it’s supported.
vdpauinfo.txt (4.1 KB)
By the way, the problem also appears when playing H264 YUV 4:2:2 videos. I have edited the post to include that.

yeah, me neither ;)
I don’t have mplayer installed, but I tried your sample file with mpv.

mpv --vo=gpu --hwdec=vdpau

works just great. Could you try that? Maybe it’s a problem with mplayer.

Can you make sure that it’s really running with VDPAU? It seems that mpv doesn’t work with VDPAU on my machine. Try running a normal (4:2:0) video.

On my machine, when running with --hwdec=nvdec, the output has this line:
Using hardware decoding (nvdec)
But it doesn’t have that line when running with --hwdec=vdpau. It’s the same output with running with software decoding (default).

I don’t think it’s a problem with MPlayer, I have tested and it also happens with VLC (it just shows a black video).

I did some digging here.
running mpv with --vo=gpu --hwdec=vdpau and the --log-file option shows it’s falling back to software decoding.

running it with --vo=vdpau:
mpv --vo=vdpau --log-file=/tmp/mpv.log /tmp/mandelbrot-h264-444.mp4
(+) Video --vid=1 (*) (h264 1280x720 60.000fps)
[vo/vdpau] Warning: this compatibility VO is low quality and may have issues with OSD, scaling, screenshots and more.
[vo/vdpau] vo=gpu is the preferred choice in any case and includes VDPAU support via hwdec=vdpau or vdpau-copy.
[ffmpeg/video] h264: hardware accelerator failed to decode picture
Error while decoding frame (hardware decoding)!
[ffmpeg/video] h264: hardware accelerator failed to decode picture
Error while decoding frame (hardware decoding)!
[ffmpeg/video] h264: hardware accelerator failed to decode picture
Error while decoding frame (hardware decoding)!
[autoconvert] Converting yuv444p -> yuv420p
VO: [vdpau] 1280x720 yuv420p

The readme I pointed you to says:

VdpDecoder

In all cases, VdpDecoder objects solely support 8-bit 4:2:0 streams, and only support writing to VDP_CHROMA_TYPE_420 surfaces.

Found a driver release note for 418.30 that says:

* Updated the VDPAU driver to reject decoding to YUV 4:2:2 video
  surfaces.  The NVIDIA VDPAU driver always produces YUV 4:2:0
  content.  Previously, the VDPAU driver implicitly converted a YUV
  4:2:2 video surface to YUV 4:2:0 during decode.  Now, the VDPAU
  driver will fail the decode request.

says:

Hardware decoders will generate equivalent output to software decoders, but may use less power and CPU to do so. Feature support varies – for more complex codecs with many different profiles, hardware decoders rarely implement all of them (for example, hardware decoders tend not to implement anything beyond YUV 4:2:0 at 8-bit depth for H.264).

So… it looks to me very much… nope not supported.

Also in the documentation that you pointed, there is this line:

GPUs with VDPAU feature set J support all of the same VdpDecoderProfile values and other features as VDPAU feature set H. Feature set J adds:
VDP_DECODER_PROFILE_HEVC_MAIN_444:

So I don’t think 4:4:4 is unsupported.

thats for HEVC

Yes, so HEVC 4:4:4 is supported on some cards. Then this line doesn’t prove that H264 4:4:4 (or 4:4:4 in a whole) is unsupported:

VdpDecoder

In all cases, VdpDecoder objects solely support 8-bit 4:2:0 streams, and only support writing to VDP_CHROMA_TYPE_420 surfaces.

If you think so… keep trying.
I’ve spent enough time on this.
Good luck.

Well, I opened this topic with the intention of making NVIDIA developers aware of this bug. Anyways, thanks for your efforts for trying to help me.

I have filed a bug 200684718 for tracking purpose.
We were able to recreate issue locally, will keep posted with further updates.