Created attachment 10272 [details]
system-wide on-CPU profile (in a flamegraph form)

rpi4$ ffprobe Big_Buck_Bunny_60fps_4K_-_Official_Blender_Foundation_Short_Film-aqz-KE-bpKQ.webm 2>&1 | grep 'Video:'
  Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv, bt709), 1920x1080, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)
rpi4$ ffplay -loglevel quiet -vcodec libvpx-vp9 -fs Big_Buck_Bunny_60fps_4K_-_Official_Blender_Foundation_Short_Film-aqz-KE-bpKQ.webm

Получаем слайд-шоу, кадр сменяется раз в 10 -- 20 секунд.

rpi4# perf record -g --call-graph=dwarf,16384 -a -F 127
rpi4# apt-get install -y ffplay-debuginfo libvpx6-debuginfo
rpi4# perf script --header > ffplay-libvpx-c.stacks
rpi4$ stackcollapse-perf.pl < ffplay-libvpx-c.stacks | flamegraph.pl --title='ffplay, libvpx, C' > ffplay-libvpx-c.stacks

Более 97% стеков - декодирование видео. В основном
1) motion compensation (функция tile_worker_hook и выше по стеку), ~ 51%
2) deblocking filter (loop_filter_row_worker), ~ 21%

То, что основные затраты при декодировании приходятся на motion compensation
и deblocking -- вполне ожидаемо и правильно. Неправильно то, что при этом
вместо SIMD используются сферические кони в вакууме^W^W^W^W vpx_convolve8_c,
vpx_lpf_horizontal_16_dual_c, и т.п.

vpx декодер активно пользуется арифметикой с насыщением (saturation arithmetics).
Многие SIMD ISA (SSEv2 на x86, NEON на armv{7,8}, и т.п.) предоставляют быструю
арифметику с насыщением. А сделать её правильно и быстро на C сложно.
В libvpx есть и реализация на C, но она очень неторопливая, и годится в
основном для тестирования (чтобы было с чем сравнивать SIMD реализации).
Но для "посмотреть видео" C реализации практически бесполезны, что видно
при попытке проиграть практически любое HD видео с youtube.