FFmpeg 4.4 Released With AV1 VA-API Decoder, SVT-AV1 Encoding

[birdie]

Also OpenMandriva use cool stuff which solves this issue in yet another way. They are using dllopen. This mean, FFmpeg (and others aplication) can support restricted libs like x264 or x265 etc at runtime. This mean, FFmpeg is compiled via dllopen and if you need for example support for x265, then you only need install x265 lib from repo and then ffmpeg start supporting it without any recompiltion. Just out-of-box.

Mageia does it differently: not via dlopen but by offering two sets of media libraries - one set is patent-free, the other one, so called "tainted", only for countries which don't "respect" patents. Megeia developers are quite brave I'd say, if not intrepid - they include "tainted" patent encumbered packages right on their servers/mirrors. That may backfire in a major way.

Why do distros patch it fast if nobody gets hacked?

To eliminate attack vectors like with all other applications/libraries.

[MadeUpName]

https://koji.rpmfusion.org/koji/pack...o?packageID=54

Thanks for the link. FFMpeg 4.4-0.7 is allready in the RPMFusion 34 repo. A lot of really good stuff in this release. Really liking the AV1 and 10/12 bit support. Big thanks to the devs. This is a package that has saved me endless amounts of time.

[fafreeman]

1. CPU use/power consumption is still quite a lot higher than in Windows
2. mpv doesn't enable it by default
3. Firefox doesn't enable it by default even under Wayland
4. Some prominent distros, e.g. Fedora, don't even include libva-intel-driver - you have to manually enable third-party repos to install the driver.

Otherwise it's all perfect, right.



FFmpeg and distros normally resolve such issues fast.



True so and also VDPAU doesn't offer hardware accelerated video encoding - that's the biggest issue with it.

mpv doesn't recommend hardware acceleration by default because of video quality. cpu software based is typically better quality vs hardware acceleration. they don't even recommend it on windows because of that very reason. if your cpu can handle the decoding, then there's no reason to use hardware acceleration as it typically won't be at the same level of quality in the output.
they only one they will give a marginal exception to in terms of quality is nvenc as its really good but its not 100%. its just better than others.

since i have a intel 10850k i turn off hardware acceleration as my 10850k has no issue running 4k 60fps and multitasking at the same time. like playing a game.

[birdie]

mpv doesn't recommend hardware acceleration by default because of video quality. cpu software based is typically better quality vs hardware acceleration. they don't even recommend it on windows because of that very reason. if your cpu can handle the decoding, then there's no reason to use hardware acceleration as it typically won't be at the same level of quality in the output.
they only one they will give a marginal exception to in terms of quality is nvenc as its really good but its not 100%. its just better than others.

since i have a intel 10850k i turn off hardware acceleration as my 10850k has no issue running 4k 60fps and multitasking at the same time. like playing a game.

I'd love to see some actual proof of that. In my experience software and hardware decoding of H.264 have been exactly the same.

Also, from FFmpeg developers: Hardware decoders will generate equivalent output to software decoders, but may use less power and CPU to do so.

Maybe you've confused decoding with encoding. Yes, software encoding can and does provide much better results because it's not constrained (it doesn't have to be real time or faster than real time).

[Gusar]

I'd love to see some actual proof of that. In my experience software and hardware decoding of H.264 have been exactly the same.

Hardware decode APIs sometimes force color-space conversion on you, which may or may not be accurate. So while the decoding is bit-accurate (by design of the codec), the final picture might still look wrong. Also, software decoding is typically more robust, hardware decoding sometimes chokes on files that a software decoder handles fine. It's for these two reasons that mpv defaults to software decoding.

[elatllat]

On Ubuntu 20.04 ffplay(v4.2.4) has low saturation with 10 bit source, mpv works properly. Anyone know if that is still an issue with 4.4?

[numacross]

To eliminate attack vectors like with all other applications/libraries.

"A tinfoil hat probably won't hurt as well."

[birdie]

"A tinfoil hat probably won't hurt as well."

No, that's called basic security.

[MadeUpName]

On Ubuntu 20.04 ffplay(v4.2.4) has low saturation with 10 bit source, mpv works properly. Anyone know if that is still an issue with 4.4?

I run Fedora not Ubuntu but I render every thing out in 4K 10bit 422 and I have never had color issues with MPV. It sounds like you have a missmatch between your source color space and your display color space. If you look at the man page and skip down to the section "Quality reduction with hardware decoding" it may give you some clues as to what is going on.

[sireangelus]

Hardware decode APIs sometimes force color-space conversion on you, which may or may not be accurate. So while the decoding is bit-accurate (by design of the codec), the final picture might still look wrong. Also, software decoding is typically more robust, hardware decoding sometimes chokes on files that a software decoder handles fine. It's for these two reasons that mpv defaults to software decoding.

why does windows have no such problems?