FFmpeg 4.3 Released With AMD AMF Encoding, Vulkan Support, AV1 Encode

[intelfx]

I might be wrong, but I think they really just want to watch 240p videos at 30fps in their browsers and somehow believe their expensive Nvidia cards should do this in hardware. They don't understand what hardware they really have and what it's capable of, because they only got it for playing games. They're like kids trying to find a parking spot at the local super market with an 18-wheel truck and then get upset when faced with reality. You don't see Chrome or Firefox using the hardware decoder by default, nor does MPV or VLC recommend it either. Any CPU these days has enough power to decode a simple video. The hardware decoders in these cards aren't meant for just watching videos any more. They're used to decode up to several thousands of frames per second, meaning, they're used to decode H.264/H.265 video streams from multiple cameras and stored files, process these with tools such as FFmpeg and encode them again. So now they're thinking that their expensive card should decode their cartoons in hardware at the lowest power state or else drama. Best is to ignore them.

Yes, you are wrong.

Do you even know what "power consumption" or "power efficiency" is?

If you personally don't care about it, it doesn't mean that no one else does.

[sdack]

Do you even know what "power consumption" or "power efficiency" is?

I do, but you're asking the question, because you're still busy figuring it out. I'll give you your answer. Any PC CPU these days is powerful enough to decode a simple video in software and without having to clock up. No matter how much extra hardware you add it won't save you power. You have instead reached the point where you need to pull out hardware to save power.

Any modern PC GPU is over-qualified for the task. A 5W Arm SBC can do it in software and they pack GPUs that for an extra 2W decode 4K videos.

So why would you add a GPU to your PC that draws 10W in idle alone for watching videos? The answer is, you don't.

Yet, you somehow expect Nvidia to build GPUs with a PCIe 3.0 bus, 8GB of memory and a solar panel to recover some of the lost power for the interface alone and just for your silly use case to be power efficient.

You want to decode videos in hardware? Just think of your CPU as hardware. You want it to be power efficient, too? Use an Arm-based device instead of an AMD/Intel PC. But don't ask to put bike pedals on cars so you can compete with bikes.

[TemplarGR]

I do, but you're asking the question, because you're still busy figuring it out. I'll give you your answer. Any PC CPU these days is powerful enough to decode a simple video in software and without having to clock up. No matter how much extra hardware you add it won't save you power. You have instead reached the point where you need to pull out hardware to save power.

Any modern PC GPU is over-qualified for the task. A 5W Arm SBC can do it in software and they pack GPUs that for an extra 2W decode 4K videos.

So why would you add a GPU to your PC that draws 10W in idle alone for watching videos? The answer is, you don't.

Yet, you somehow expect Nvidia to build GPUs with a PICe 4.0 bus, 8GB of memory and a solar panel to recover some of the lost power for the interface alone and just for your silly use case to be power efficient.

You are clearly wrong and clearly an Nvidia fanboy. Hardware video acceleration is VERY important, no matter the hardware, because simply put is more efficient than software video playback. Even if you have a 64 core cpu, it will still be preferrable to have VAAPI decoding because that will mean that your cpu cycles can be spent elsewhere.

What you are essentially saying is : "I don't care about optimized solutions because Nvidia doesn't care and i only buy/promote/shill for Nvidia so any attempt at optimizing video on Linux can suck dick. Cause it won't be better for me, since i only buy Nvidia. Others should never have VAAPI and other goodies that have been available on Windows since FOREVER because that will make Nvidia look bad, so here i am shilling for Nvidia."

[intelfx]

I do, but you're asking the question, because you're still busy figuring it out. I'll give you your answer. Any PC CPU these days is powerful enough to decode a simple video in software and without having to clock up. No matter how much extra hardware you add it won't save you power. You have instead reached the point where you need to pull out hardware to save power.

Any modern PC GPU is over-qualified for the task. A 5W Arm SBC can do it in software and they pack GPUs that for an extra 2W decode 4K videos.

So why would you add a GPU to your PC that draws 10W in idle alone for watching videos? The answer is, you don't.

Yet, you somehow expect Nvidia to build GPUs with a PICe 4.0 bus, 8GB of memory and a solar panel to recover some of the lost power for the interface alone and just for your silly use case to be power efficient.

I'm asking the question, because I have figured it out, and you didn't. Every single clock where the CPU is not in its deepest sleep state is a wasted clock. Clock up or not, 400 MHz, 800 MHz or 3000 MHz — irrelevant. The CPU is not sleeping == the CPU is wasting power, full stop.

And why would I add a GPU? Because I already have the GPU, because it draws the picture, you moron.

Also, I don't expect NVIDIA to build anything. The world doesn't revolve around your 64-core workstation with PCIe 4.0 and RTX 9999 that eats kilowatts for breakfast, people have laptops, big surprise.

[johnp117]

I'm not interested in wayland and its compositors.

So what? There's more people traversing this forum than just you and you apparently didn't know why hw video decoding in browsers was not widespread already, so I gave you the main reason.

I also explicitly mentioned that X11 support follows close by, but I suppose you're also not interested in that?

[sdack]

Hardware video acceleration is VERY important ...

Yes and no. People once thought hardware FPUs, MMUs and Northbridge were important. Now they're just another part of CPUs.

Hardware video decoding for end-consumers is important on the little GPUs. So is hardware video decoding for broadcasters important on the big GPUs. But the technology moves on and while the importance remains, does it just not get implemented the way you think it should.

You then want high-end hardware to be all end-consumer friendly, but that's just as naive as trying to put pedals on a car or finding a parking spot for an 18-wheeler at your local super market - it's just not sensible. High-end cards have large amounts of fast memory. That memory cannot simply be turned off but needs to be refreshed, which puts a lower limit on the power draw. High-end GPUs themselves have tens of billions of transistors and you simply cannot turn them all off, but this, too, puts a lower limit on the power draw. And if Nvidia were to produce high-end cards with 8GB of LPDDR4 instead of GDDR6 would hardly anyone want to buy it and it wouldn't be high-end, would it now?

So, no, you don't get the power-efficiency you seek on your PC for just watching a simple video. That train has past a while ago on the high-end cards. Of course it doesn't stop Nvidia from making their GPUs more power-friendly, and so they turn the decoder off in their lowest power state, but then what happens? You get people complaining how this wasn't a feature, but that watching videos now consumes more power, because all they compare it to is the lowest power state, and they believe that they should be able to watch videos in that state. They don't see that the lowest power state is meant for when you don't decode videos.

If your graphics card now clocks significantly higher than it should, then this is not a fault of the hardware, but in most cases is it a bad combination of choices on the end-user as well as software developer side. GPUs do have hardware video scalers built-in, but hardly anyone wants to use them. Instead, it has to be a spline filter or lanczos3 filter, and because nobody is quite sure which one looks better. And they implement them as an OpenGL or Vulkan shader, while on top you may also have an OpenGL compositor running. Of course this causes your GPU to clock up higher. That's the price for the bliss you've ordered.

Every single clock where the CPU is not in its deepest sleep state is a wasted clock.

On your PC it surely is.

[Toggleton]

Still no built-in Intel SVT support.

Also, there is something I do not understand with rav1e. People say being written in Rust makes it safer than C code and still fast but when I look at their Git, I see 62.1% of the code is Assembly. So, how is it safe if it is mostly written in the most unsafe (and performant) language ever? And how does that prove Rust's performance if this thing is written mostly in Assembly?
Maybe there is some deep difference I do not know with SVT-AV1 that justify this but when I look at SVT-AV1's Git, I see 91.8% C, 6.7% C++ and only 0.9% Assembly (SVT-AV1 is 5x bigger than rav1e, but that's still much less Assembly (~12x less), even in absolute numbers). So massive Assembly usage is definitely not required to get a performant encoder, at least when this encoder is written in C. This makes me think that rav1e people wanted to write their thing in Rust to prove that Rust could do what C can safer and still performant but then had to face reality; Rust is not as performant as C, and they had to use Assembly to get acceptable performance without having to rely on C, still loosing Rust's safety in the process.

First of all rav1e has assembly from dav1d(the av1 decoder) so it gets tested on that side before it gets added to Rav1e and you need to take into account that rav1e has ASM for arm32 and 64bit too while i have seen so far that svt-av1 has only stuff for x86.

TBH not even sure if that calculation of github is useful.
https://github.com/OpenVisualCloud/S...l=assembly&p=1 it shows only SSE2 and SSSE3 as assembly(i guess it just counts the .asm files), while https://github.com/OpenVisualCloud/S...ce/Lib/Encoder and https://github.com/OpenVisualCloud/S...rce/Lib/Common has a lot stuff in it but could be that they use intrinsics and thats why it will not be counted as assembly.


That question comes up every time Rav1e is in a Changelog or has a release https://news.ycombinator.com/item?id=23512706 this thread could be interesting to read for you.

[sdack]

If I remember well, browsers use the video card for decondig supported videos while browsing under Windows since ever.

This has historic reasons as well as Microsoft offering only a few APIs and these find support by practically every hardware manufacturer. So it's easier to implement. With Open Source comes freedom and of course the freedom to mess things up a bit more and not to support everything.

Just as a test did I measure the power output on the wall for Windows 10 vs. Linux using VLC with hardware-decoding on a 720p video. No matter the hardware-decoding method I used for Windows 10 did it use 30W more than Linux.

Chromium on Linux without hardware-decoding then uses only 5W more than VLC on Linux with hardware-decoding, but it's also the beefier application with a lot more threads, which likely explains the difference. So I don't expect to see a power-saving gain for when hardware-decoding becomes available with Chromium. It just doesn't make a difference for simple videos. What matters is using Linux over Windows 10.

[sdack]

I don't know where you have found those data.
Windows manages the clock speed, I know.

I used a GPU manager and set the card into "silent mode" to disable over-clocking and to enable power savings on the card. It did however not lower the clocks much during the playback.

[pal666]

Yeah, it's been a whole... 2 months since their last stable release.

yes, whole one commit in 2020. how novideo wayland support goes?