Vulkan Video Arrives For New Industry-Standard Video Encode/Decode

[xpris]

So thanks to this, we can see soon AMD AMF support on AMDVLK or even on RADV.
Developers of AMF supporting Windows drivers and on Linux only AMDGPU-PRO, but they are open to adding support for AMDVLK or RADV as soon as these implement the Vulkan extension with decode / encode support.

[loganj]

will this make pi4 able to play av1 1080p?

[useless]

H264 is a necessary evil (patents expire soon)

Do you have any source on that? Last time I read about it, people were talking 2027 as the expiration year of the last patent.

[jntesteves]

Does this expose the hardware video codec decode API from the driver directly to the Vulkan spec? Or is this just decoding on regular GPU computing units? If latter, I don't see it replacing VAAPI yet. The first option would be cool.

This implementation detail shouldn't be covered by the API. Each driver can implement this in any way they want, even a software fallback would be conformant. Obviously, in practice, most implementations will use specialized hardware where possible, and fallbacks are not to be expected outside of CI-testing use cases. (Until the first buggy software requiring these extensions start popping out, that is. As we know from history, it will happen. It's only a matter of time. Then fallbacks might make it into consumer drivers)

[MadeUpName]

Wow, that's great !
Hopefully they add support for high quality features like 4K - 8K resolution, 10-12 bit, 60-120 FPS, HDR
Sending HDR metadata to the TV would be also very nice to have.

When I first read that I was reminded of the old slogan "Your dreaming in Technicolor". But then I realized your dreaming far beyond Technicolor. Good dream though.

[M@yeulC]

So thanks to this, we can see soon AMD AMF support on AMDVLK or even on RADV.
Developers of AMF supporting Windows drivers and on Linux only AMDGPU-PRO, but they are open to adding support for AMDVLK or RADV as soon as these implement the Vulkan extension with decode / encode support.

But why would you actually want AMF instead of VA-API or directly using this vulkan API?

Going forward, I expect there will be a VAAPI<->Vulkan bridge pretty soon.

[kiffmet]

I don't know whether proposing another API for video acceleration is a good idea, when many products on the market (mostly SBCs) don't even support all the ones we have now (angrily looking at Pi4's lack of VAAPI). Like seriously - why do some applications have to use VAAPI, while others only support OpenMAX, and another few happily take a V4L2 m2m device? FML, I hate that fragmentation so much.

[ms178]

I don't know whether proposing another API for video acceleration is a good idea, when many products on the market (mostly SBCs) don't even support all the ones we have now (angrily looking at Pi4's lack of VAAPI). Like seriously - why do some applications have to use VAAPI, while others only support OpenMAX, and another few happily take a V4L2 m2m device? FML, I hate that fragmentation so much.

I hope this new Vulkan approach unifies the API landscape for modern hardware, app developers should invest into the Vulkan ecosystem, it gets them multi-OS and multi-platform support. That is a big advantage in my eyes in contrast to VAAPI, OpenMAX, VDPAU etc.

[piotrj3]

I hope this new Vulkan approach unifies the API landscape for modern hardware, app developers should invest into the Vulkan ecosystem, it gets them multi-OS and multi-platform support. That is a big advantage in my eyes in contrast to VAAPI, OpenMAX, VDPAU etc.

This is think the strongest point of it, especially considering a lot of programs might become more portable. Here I believe problem "Video decode hardware accelerated on windows but not on linux" could be solved.

[dc_coder_84]

And VAAPI is using OpenGL for now?