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

[asriel]

Does hardware AV1 decode work for anyone on tigerlake? So far I have tried it and in MPV it produce garbage on screen, with VLC it crash the system for me.
Here is the bug in intel-media-driver that I've found but it is not resolved yet.

https://github.com/intel/media-driver/issues/1155

[[TV]]

why does windows have no such problems?

But it does or at least did. Specifically dxva2 had this problem which resulted in inaccurate colors. I tested this myself years ago with an HD 4650 card on Win7. Also you couldn't do separate chroma upscaling using dxva2. D3d11va did not have these problems.

[Gusar]

why does windows have no such problems?

What makes you think it doesn't? Chocking on some files happens because of the inflexibility of fixed function hardware compared to software that can be tweaked to handle edge cases, the OS doesn't matter. And wrong colorspace conversion happens in Windows too, depending on player and/or driver settings. But unless we're talking HDR, using the wrong conversion matrix will still produce fully watchable video, so you may not even notice that the colors are off.

[numacross]

No, that's called basic security.

And so is using languages that help you achieve more secure programs, yet you said it's tinfoilhattery.

why does windows have no such problems?

Having a Microsoft-mandated API (DXVA) to follow might be one reason. Another might be that hardware vendors actually test under Windows.

[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?

[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.

[birdie]

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

No, that's called basic security.

[numacross]

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

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

[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?

[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.