AMD Aims For AMF Decode In FFmpeg, Questioned Over Vulkan Video Commitment

[lu_tze]

Last AMF release allow to use it via RADV, so proprietary driver is no longer needed.

Also AMF in encoding (which is already merged in ffmpeg) just kick ass vaapi in case of performance and quality (tested by myself many times).

That's not really true: the experimental part is that you don't have to use amdvlk when using vulkan, but radv would also work. The sad part is, that you still need the AMF runtime, which is shipped in libamfrt64.so / libamdenc64.so, which are part of the -- drumroll -- proprietary driver.

sadly thats just not true. if you want high quality gpu acceleration (surveilance systems) AMF is what you go for, a lot of us were really happy when AMD announecd that amdvlk would be supported by amf (and possibly radv) when vulkan video lands.

For surveilance systems, the same thing applies as elsewhere. You get more bang for your buck: intel qsv > nvidia nvenc > amd amf. Even in enterprise, you must be a big amd fan to invest into the worst solution with the dead-end API on top.

Individual Linux users are worth nothing. Every enterprise customer is using AMF, that's good enough for AMD.

I doubt that AMD would formulate this so directly. Sadly, the attitude is here, which means zero community involvement, no real long term support and you can milk support contracts only for so long. In the next refresh cycle, your customers are going to jump ship, if they can.

[Quackdoc]

For surveilance systems, the same thing applies as elsewhere. You get more bang for your buck: intel qsv > nvidia nvenc > amd amf. Even in enterprise, you must be a big amd fan to invest into the worst solution with the dead-end API on top.

Intel is no where near good enough. maybe if you only handle a couple of streams. AMD is a great investment because it offers actually expanding unlike in the past intel, and unlike nvidia, you arent tied to specific kernel versions if you want support. which has been a major issue in the past for me.

[piotrj3]

Intel is no where near good enough. maybe if you only handle a couple of streams. AMD is a great investment because it offers actually expanding unlike in the past intel, and unlike nvidia, you arent tied to specific kernel versions if you want support. which has been a major issue in the past for me.

Intel encoding in quality far exceeds AMD. It is in fact on par with Nvidia, depends on settings Intel or Nvidia are better. But what is most important is Intel offers full AV1 encoding in just A380 card that is cheap and in fact that card has 2 hardware encoders and it matches Nvidia's encoders performance characteristics. If you purely care about video encoder for smallest buck, Intel is by far best choice. Intel doesn't even have number of streams limit.

Currently mostly at low bitrates Intel wins vs Nvidia, but at higher bitrates Nvidia beats intel at least for Av1 encoding. Meanwhile AMD is always below and Rigaya comparisons doesn't even show 10 bit AV1 encoding for AMD.

Also if you want thousand of AMD issues like this one https://trac.ffmpeg.org/ticket/10266 sure go for AMD. Btw it is hardware issue, not fixable in software.

[Quackdoc]

Intel encoding in quality far exceeds AMD. It is in fact on par with Nvidia, depends on settings Intel or Nvidia are better. But what is most important is Intel offers full AV1 encoding in just A380 card that is cheap and in fact that card has 2 hardware encoders and it matches Nvidia's encoders performance characteristics. If you purely care about video encoder for smallest buck, Intel is by far best choice. Intel doesn't even have number of streams limit.

Currently mostly at low bitrates Intel wins vs Nvidia, but at higher bitrates Nvidia beats intel at least for Av1 encoding. Meanwhile AMD is always below and Rigaya comparisons doesn't even show 10 bit AV1 encoding for AMD.

Also if you want thousand of AMD issues like this one https://trac.ffmpeg.org/ticket/10266 sure go for AMD. Btw it is hardware issue, not fixable in software.

before the a380 came out you had no other options for expanding. you are also limited to relatively new kernels with it. It's not a bad option if you are doing something new, but if you are expanding capabilities of old systems, AMD is necessary.

I am aware of how good intel is. I've personally done tests with it. this image is from some testing I did in january. and like I said, great for new setups, and will for sure be my goto, but for old systems, not usable. https://files.catbox.moe/ts371c.png

[X_m7]

Meanwhile on the other end Handbrake is completely against supporting VAAPI and only supports AMF for AMD GPUs: https://github.com/HandBrake/HandBrake/issues/1083

[arteast]

Well, they've got a dozen of different hwaccels already with plenty of hwaccel-specific filters and codecs so why stop now? What's one more to boot; surely it won't be the feather to break camel's back (they - core developers I mean - do great job destroying ffmpeg community over trivial matters and hurt feelings though)?.. They already strive to support everything and its uncle, so just keep on going with that... Vulkan would be great as a single all-encompassing thing, but it is not yet here to superset all and every one of the others. If/when it is there then superseded hwaccels can be deprecated and gotten rid of (also when vulkan is adopted as a proper all-platforms choice by the related projects like opencv and vlc so interop is not hurt)

[dec05eba]

I hate that amd is slowing down adoption of vulkan video encoding. I have waited for lynne to add support for vulkan video encoding in ffmpeg for a while. Vaapi works fine so I dont really care if it works on amd but on nvidia vulkan video encoding has a huge benefit over nvenc, which is that is avoids the issue of cuda gpu downclocking which decreases system performance (by 10-14% on my gpu).

[Quackdoc]

I hate that amd is slowing down adoption of vulkan video encoding. I have waited for lynne to add support for vulkan video encoding in ffmpeg for a while. Vaapi works fine so I dont really care if it works on amd but on nvidia vulkan video encoding has a huge benefit over nvenc, which is that is avoids the issue of cuda gpu downclocking which decreases system performance (by 10-14% on my gpu).

is there any evidence that AMD is slowing down adoption of it?

[Artim]

Meanwhile on the other end Handbrake is completely against supporting VAAPI and only supports AMF for AMD GPUs: https://github.com/HandBrake/HandBrake/issues/1083

Which is just dumb as pretty much nobody can use AMF. Handbreake is really going downhill. Even its SVT-AV1 encoder is much slower than ffmpeg CLI encoder. So you can't even forgo the lack of usable hardware acceleration support by using a competent software encoder.

[Artim]

[...](also when vulkan is adopted as a proper all-platforms choice by the related projects like opencv and vlc so interop is not hurt)

How should Vulkan be used for OpenCV? There isn't any overlap between what they do. Also, VLC 4.0 has been in development for so many years, yet still far from being ready to be launched - not that I would mind, the UI they showed off was just unusable - while 3.x is rotting away. Maybe the likes of mpv and others may implement it, but I don't see any future for VLC. They would just need to do way too much catching up. The whole videolan team seems to only focus on their open source decoders.