Add libav x264 decoder, and modern VA API encoder and decoders #1742
Conversation
|
Thanks for the PR! I just tested it and found one issue - With those I think this is good to go. Semi-related: #1775 |
| case "msdkvp9enc": | ||
| case "vaapivp9enc": | ||
| case "msdkvp8enc": | ||
| case "vavp8enc": |
There was a problem hiding this comment.
This is missing vavp9enc - however I think the vp9 elements will fail the tests anyway without vp9parse for both en- and decoding (vp8 is one of the only codecs not needing that).
Given that vavp9enc is
- only supported by a very limited set of devices (Intel only)
- pretty unlikely to be used as
vah264encis usually present
I suggest to drop it from the PR altogether and only leave the decoding/vavp9dec parts (even though that'll likely need vp9parse in get_decode_prefix() , see rmader@829a5c3
There was a problem hiding this comment.
P.S.: not sure if that actually makes sense as vp9 encoding would still be broken/problematic. Maybe it's better to just drop vp9 altogether - vp8 is the better fallback and h264 is the better default anyway.
I.e. leaving it out in this PR and then do a follow-up PR dropping support for vp9 and the legacy vaapi* elements.
|
@rmader I not sure that replacing "deprecated" decoder/encoder is good idea. As far as I recall modern is supported by only new enough hardware, and old hardware is supported only with old or deprecated driver. |
Fortunately this is not the case. I just double-checked #1781 on my oldest test device with H264 en/decoding support - a Thinkpad X220 from 2011 (*1) - and hardware video decoding with
Note that on that device hardware encoding is blocked by Gstreamer as we found it to be too buggy when enabling hardware encoding by default in Gnome-Shell (for screen recording).
|
No description provided.