FFmpeg 3.0 Released, Supports VP9 VA-API Acceleration

[phoronix]

Phoronix: FFmpeg 3.0 Released, Supports VP9 VA-API Acceleration

FFmpeg 3.0 is now available for your open-source multimedia needs...

http://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-3.0-Released

[Krejzi]

And it also breaks all hardware acceleration plugins in VLC (VAAPI, VDPAU, DXVA2).

[Gusar]

And it also breaks all hardware acceleration plugins in VLC (VAAPI, VDPAU, DXVA2).

It's actually VLC that uses hwaccel in a way that the ffmpeg devs don't want to support, as it causes corruption or crashes. While VLC managed to work around that by sprinkling locks all over the place, the proper solution would be for VLC to stop using multi-threading with hwaccel. No other player does, that's why only VLC was broken. Keyword "was", throwing an error when attempting to use hwaccel-mt has been reduced to throwing a warning shortly before the release, so VLC is not broken anymore.

[Krejzi]

It's actually VLC that uses hwaccel in a way that the ffmpeg devs don't want to support, as it causes corruption or crashes. While VLC managed to work around that by sprinkling locks all over the place, the proper solution would be for VLC to stop using multi-threading with hwaccel. No other player does, that's why only VLC was broken. Keyword "was", throwing an error when attempting to use hwaccel-mt has been reduced to throwing a warning shortly before the release, so VLC is not broken anymore.

Thanks for the info. I suppose I should poke VLC guys to remove the libavcodec version restriction when hwaccel is enabled.

[carewolf]

It's actually VLC that uses hwaccel in a way that the ffmpeg devs don't want to support, as it causes corruption or crashes. While VLC managed to work around that by sprinkling locks all over the place, the proper solution would be for VLC to stop using multi-threading with hwaccel. No other player does, that's why only VLC was broken. Keyword "was", throwing an error when attempting to use hwaccel-mt has been reduced to throwing a warning shortly before the release, so VLC is not broken anymore.

I believe the "proper" solution would be for FFMPEG to make their code thread-safe. Spreading locks around code that is not thread-safe is the best way to use multi-thread broken code.

[Anvil]

VLC is getting crappy IMO . dunno bou 3.0 of VLC. but i wonder if we'll get ffmpeg3.0 in RPMFusion

[Gusar]

I believe the "proper" solution would be for FFMPEG to make their code thread-safe.

It's not really about ffmpeg's code. It's the interaction with the hardware, hw decode frameworks are very tricky beasts. There are issues regarding accessing a frame while the hardware is using it for something else, sorry don't recall exact details right now. Not trying to access the hardware from multiple threads relieves you of those issues. hwaccel-mt doesn't bring any performance increase anyway, there's no reason to use it. Only VLC ever did. It was created so that when hw decode fails, you'd automatically get a multi-threaded software fallback. But what other players do, they simply reopen the decoder when hw decode fails. For some reason the VLC devs don't want to recode their player to do the same.

[(tpm)]

Re. "no other player does that" - GStreamer is heavily multithreaded, and gstreamer-vaapi (which is maintained by Intel developers) seems to cope with that just fine, so not sure it can all be blamed on the underlying hwaccel APIs, at least for this particular case.

[Gusar]

Re. "no other player does that" - GStreamer is heavily multithreaded, and gstreamer-vaapi (which is maintained by Intel developers) seems to cope with that just fine, so not sure it can all be blamed on the underlying hwaccel APIs, at least for this particular case.

Just because gstreamer itself is multithreaded does not mean that gstreamer-vaapi is accessing hardware video surfaces from several threads simultaneously. mpv is multithreaded too, but that doesn't say anything about how it uses hwaccel.

[SystemCrasher]

I believe the "proper" solution would be for FFMPEG to make their code thread-safe. Spreading locks around code that is not thread-safe is the best way to use multi-thread broken code.

VLC also causes all sorts of bizarre bugs on e.g. Android devices, when it comes to HW acceleration. Somehow, VLC always manages to provoke strange bugs on HW decoders. So maybe it would be better for them to calm down a bit and prefer simple/reliable code to fiddle with HW decoders?