Linux AV1 Hardware Video Decoding Support Ready For Intel Tiger Lake
The Intel Tiger Lake processors coming in September 2020 will be the first Intel processors with integrated graphics capable of decoding, but not encoding, AOMedia Video 1 (AV1) in hardware. Linux support for AV1 hardware decoding was merged into the libva VAAPI in March. Fei Wang submitted patches allowing ffmpeg to take advantage of that support yesterday. That makes it trivial to add AV1 hardware decoding support to end-user players like VLC and mpv.
written by 윤채경 (Yoon Chae-kyung). published 2020-08-22 - last edited 2020-08-22
vainfo showing the hardware video encoding and decoding capabilities on a machine with an older dual-core Intel i7 CPU with gen8 integrated graphics.
Intel-employed software developer Zefu Li submitted a patch adding hardware video decoding support for AV1 video to the
libva library on March 4th this year. The
libva library is what media libraries like ffmpeg use to provide hardware decoding for both AMD and Intel graphics chips. The ffmpeg library is, in turn, used by popular end-user media players like mpv.
Intel's Fei Wang submitted patches allowing ffmpeg to take advantage of libva's AV1 hardware video decoding support. That makes it trivial to add AV1 hardware video decoding to mpv and video player software.
"If you git grep the code base and look at results for "h264" or "hevc" (non-case sensitive) you will not find a lot of codec specific glue.
The biggest thing is the used-by-default hwdec_codecs list
My guess is that if you enable that codec name to be in the hwdec_codecs list (it's an option so you can override it via config/cli for testing), and you have hardware to test with it - I see no reason for it to not work"
The Intel "Tiger Lake" processors scheduled to be released early September will be the first Intel processors with integrated graphics capable of AV1 hardware decoding. The upcoming Tiger Lake laptops, featuring either LPDDR4 or LPDDR5 RAM, Thunderbolt, Soundwire and other goodies, will not be capable of AV1 hardware encoding. That is unfortunate because AV1 CPU-encoding is painfully slow. AV1 video encoding will not be a realistic alternative for home users until hardware encoding becomes an option.
AMD Isn't There
A close-up inspection of the current Linux kernels git version of
drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c reveals that the upcoming AMD "Sienna Cichlid" and "Navy Flounder" graphics cards will not be capable of AV1 hardware video decoding.
drivers/gpu/drm/amd/amdgpu/vce_v4_0.c reveals that they won't even be able to do VP9 hardware encoding. They will, like the existing Raven, Navi and Reinor chips, be limited to VP9 hardware decoding. Integrated Intel graphics chips have supported VP9 hardware encoding since Ice Lake was launched back in September 2019.
Hardware Encoding Would Be The Key
It is nice that upcoming Intel processors will have AV1 video decoding in hardware and it is nice that Linux support for it is there when the new Tiger Lake processors arrive. However, the simple truth is that it will not matter all that much as long has software video encoding is unbearably slow and hardware encoding remains unavailable.
AV1 video encoding is so slow it's a non-starter for everyone but very large mega-corporations like Google and Netflix. There is a notable but acceptable between the time it takes to software encode VP8 and VP9 video. It does not matter that much if it takes two or two and a half hours to encode a video. It would be bad if it took twice as long to encode VP9 as it takes to encode VP8 but it would not rule VP9 out as a practically usable format. The difference between the time it takes to encode video in VP9 and AV1 is so huge it is laughable: Software encoding a two hour long video as AV1 using ffmpeg and libaom-av1 takes more than one week. Four vs six hours would be in the same ball-park. Four hours vs one week is like the difference between shaving and cutting your head off. Don't expect any broad AV1 adoption until software encoding becomes significantly faster or hardware encoding becomes commonplace.