Mesa 23.1 RADV Driver Lands Vulkan Video Decoding For H.264/H.265

[RejectModernity]

What apps support decoding via vulkan video?

[mbriar]

What apps support decoding via vulkan video?

Right now? Nothing, but ffmpeg might get support for it soon, and then more apps might follow (but not automagically work with vulkan decode if they use ffmpeg)

[mbriar]

This Vulkan based x264 / x265 decoding will also be gutted from mesa on distros like Manjaro? (I refer the recent licensing issue about x264/265 usage)

I don't see why it would be any different from vaapi/vdpau. (Also x264 and x265 are specific software implementations of the h264 and h265 codecs)

[edxposed]

On Linux, vaapi is good enough, but Windows' d3d11va only supports NV12 and P010, which makes Intel GPUs useless. Although the Intel driver supports d3d11va 12bit/422/444, ffmpeg still does not support it. As for the QSV decoder, it is also based on d3d11va on Windows. And the NVIDIA driver doesn't support d3d11va 12bit/444 at all. Vulkan Video is the only opportunity for Windows users to implement zero-copy decoding of all video formats supported by the GPU. Also, if you want to do hardware encoding on Windows, your only option is the vendor API, Write three encoding implementations for NVIDIA, Intel, and AMD graphics cards. As for media foundation and d3d12va, no one is willing to support them. Fortunately, Vulkan Video provides a general encoding API, and ffmpeg actively supports it

[kiffmet]

I hope that in the long run this will resolve the issue with the fragmentation of video decoding and encoding interfaces used by applications on different Linux platforms. I'm specifically referring to the situation with ARM SBCs vs x64 desktops. Having one application use VAAPI, another VDPAU or V4L2 (which itself has variations), OpenMAX, etc. is frustrating, since it's virtually impossible to use accelerated video playback throughout the whole application stack on SBCs.

Many applications are utilizing ffmpeg, while at the same time not being able to access the platform native method of video acceleration through it is kinda silly too. Welp, we'll see. Let's just hope that this won't end as another competing, underutilized standard.

[edxposed]

On Android, mediacodec does not pass Dolby Vision metadata back to the app, so you cannot use mpv-android hardware to decode Dolby Vision, and Vulkan Video is the only chance to change this. However, Android CDD requires that the Vulkan driver must not Enumerate VK_KHR_video_queue, VK_KHR_video_decode_queue, or VK_KHR_video_encode_queue extensions, considering that Vulkan Video is still in Beta state when Android 13 is released, it is understandable

[edxposed]

Chrome Media Team doesn't seem to have plans to support Vulkan Video, they think Windows d3d11va/Linux vaapi/v4l2 (coming soon) are good enough

[geearf]

Any performance difference to expect with this?

[RejectModernity]

Chrome Media Team doesn't seem to have plans to support Vulkan Video, they think Windows d3d11va/Linux vaapi/v4l2 (coming soon) are good enough

Oh wow, it's just like IE all over again!

[theriddick]

I wonder if this will help discord work better.