Ffmpeg h264 аппаратный декодер для amd

ffmpeg -i test.mp4 -benchmark -f null -

video:1148KiB audio:1770KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown
frame= 2773 fps=784 q=-0.0 Lsize=N/A time=00:01:53.28 bitrate=N/A speed=  32x elapsed=0:00:03.53    
bench: utime=18.871s stime=0.298s rtime=3.536s
bench: maxrss=316920KiB

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i test.mp4 -benchmark -f null -

video:1148KiB audio:1770KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown
frame= 2773 fps=496 q=-0.0 Lsize=N/A time=00:01:53.28 bitrate=N/A speed=20.3x elapsed=0:00:05.59    
bench: utime=1.596s stime=1.739s rtime=5.591s
bench: maxrss=278268KiB

ffmpeg -hwaccel vulkan -init_hw_device vulkan=vk:1 -i test.mp4 -benchmark -f null -

video:1148KiB audio:1770KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: unknown
frame= 2773 fps=365 q=-0.0 Lsize=N/A time=00:01:53.28 bitrate=N/A speed=14.9x elapsed=0:00:07.58    
bench: utime=0.313s stime=0.583s rtime=7.589s
bench: maxrss=270964KiB

т.е. amd 9950x в полтора раза шустрее чем vaapi декодер на 9060 и в два раза быстрее чем на встроенном гпу

на дискретном 9060 вулкан отваливается с

[h264 @ 0x56134dfe40c0] Device does not support the VK_KHR_video_decode_queue extension!
[h264 @ 0x56134dfe40c0] Failed setup for format vulkan: hwaccel initialisation returned error.

и судя по тому что vulkaninfo упоминает декодер только один раз, то видимо дебиан 13 в него не умеет

vulkaninfo | grep KHR_video
WARNING: radv is not a conformant Vulkan implementation, testing use only.
        VK_KHR_video_decode_av1                       : extension revision 1
        VK_KHR_video_decode_h264                      : extension revision 9
        VK_KHR_video_decode_h265                      : extension revision 8
        VK_KHR_video_decode_queue                     : extension revision 8
        VK_KHR_video_encode_h264                      : extension revision 14
        VK_KHR_video_encode_h265                      : extension revision 14
        VK_KHR_video_encode_queue                     : extension revision 12
        VK_KHR_video_maintenance1                     : extension revision 1
        VK_KHR_video_queue                            : extension revision 8

Покупай амуде, говорили они, у нее отличная поддержка под линухом, говорили они
скам какой-то :-D

Для того, чтобы декодирование работало, надо чтобы драйвера видео были собраны с поддержкой декодирования (mesa-libva или как это в вашем дистрибутиве называется). В Fedora, например, собирают без поддержки кодирования/декодирования из-за патентных ограничений в США.

Когда я со своими АМД плясал с декодированием на Вулкане, то без вот этой переменной окружения:

export RADV_PERFTEST=video_decode

оно точно так же не хотело работать.

Сейчас попробовал h264 vaapi, но в арче ffmpeg поставляется без декодеров vaapi :)

> ffmpeg -hide_banner -decoders | grep 264
 VFS..D h264                 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
 V..... h264_v4l2m2m         V4L2 mem2mem H.264 decoder wrapper (codec h264)
 V....D h264_qsv             H264 video (Intel Quick Sync Video acceleration) (codec h264)
 V..... h264_cuvid           Nvidia CUVID H264 decoder (codec h264)

Щас у меня дособерётся ffmpeg-amd-full из АУРа, посмотрю там.

дебиан 13 в него не умеет

Есть деб-мультимедия, там пепесобирают ffmpeg, имеет смысл попробовать его.

Не, я фигню, написал, видимо. Специалисты сказали, что vaapi в списке декодеров и не должен появляться.

Прогнал тестовый файл с ffmpeg из реп арча и с ffmpeg-amd-full из аура, результат одинаковый: GPU декодит, судя по amdgpu_top с загрузкой декодера до 100%, цпу отдыхает при этом.

В логах вот такое есть:

[AVHWDeviceContext @ 0x5653ab2f1e40] libva: VA-API version 1.22.0
[AVHWDeviceContext @ 0x5653ab2f1e40] libva: Trying to open /usr/lib/dri/radeonsi_drv_video.so
[AVHWDeviceContext @ 0x5653ab2f1e40] libva: Found init function __vaDriverInit_1_22
[AVHWDeviceContext @ 0x5653ab2f1e40] libva: va_openDriver() returns 0
[AVHWDeviceContext @ 0x5653ab2f1e40] Initialised VAAPI connection: version 1.22
[AVHWDeviceContext @ 0x5653ab2f1e40] VAAPI driver: Mesa Gallium driver 25.2.2-arch1.1 for AMD Radeon RX Vega (radeonsi, vega10, ACO, DRM 3.63, 6.15.4-arch2-1).
[AVHWDeviceContext @ 0x5653ab2f1e40] Driver not found in known nonstandard list, using standard behaviour.
[h264 @ 0x5653ab4ac4c0] Reinit context to 3840x2160, pix_fmt: yuv420p
Selecting decoder 'h264' because of requested hwaccel method vaapi

...

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'sample_3840x2160.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf57.83.100
  Duration: 00:00:28.24, start: 0.000000, bitrate: 37573 kb/s
  Stream #0:0[0x1](und): Video: h264 (High), 1 reference frame (avc1 / 0x31637661), yuv420p(progressive, left), 3840x2160, 37570 kb/s, 23.98 fps, 23.98 tbr, 24k tbn (default)
      Metadata:
        handler_name    : VideoHandler
        vendor_id       : [0][0][0][0]
[out#0/null @ 0x5653ab34ff00] No explicit maps, mapping streams automatically...
[vost#0:0/wrapped_avframe @ 0x5653ab4d26c0] Created video stream from input stream 0:0
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
[vost#0:0/wrapped_avframe @ 0x5653ab4d26c0] Starting thread...
[vf#0:0 @ 0x5653ab373500] Starting thread...
[vist#0:0/h264 @ 0x5653ab4d1f00] [dec:h264 @ 0x5653ab36a040] Starting thread...
[in#0/mov,mp4,m4a,3gp,3g2,mj2 @ 0x5653ab4ab300] Starting thread...
Press [q] to stop, [?] for help
[h264 @ 0x5653ab4bee40] Reinit context to 3840x2160, pix_fmt: vaapi
[graph -1 input from stream 0:0 @ 0x7f74fc002f00] w:3840 h:2160 pixfmt:vaapi tb:1/24000 fr:24000/1001 sar:0/1 csp:unknown range:unknown
[graph -1 input from stream 0:0 @ 0x7f74fc002f00] video frame properties congruent with link at pts_time: 0

А сравнение скорости весёлое.

Vulkan:
Vega 11: 6.75x
Vega 56: 3.74x

Vaapi:
Vega 11: 6.85x
Vega 56: 7.64x

CPU: 3.63x

Железо древнее, да, но тем не менее.

из-за патентных ограничений

по крайней мере вулкан точно не по патентам ограничен - на встройке он декодер видит

но видимо меса на момент фиксации дебиана 13 не умела в 9060

сейчас попробую rocm навернуть но это довольно забавная процедура на 13ом - часть пакетиков пришлось качать ручками ибо амд конечно драйвера под 13шку не обновила (и судя по тому что они вообще для убунты то и не планирует) - П-поддержка :-D

Специалисты сказали, что vaapi в списке декодеров и не должен появляться.

да, я в начале тоже думал что у меня ffmpeg не умеет в такое ожидая увидеть h264_vaapi в списке но видимо он в просто h264 воткнут

т.е. amd 9950x в полтора раза шустрее чем vaapi декодер на 9060

Так основной смысл в энергопотреблении, а не производительности.
Естественно, что современный шестнадцати ядерный проц будет быстрее.
У меня на 5950 и 6700 разница между cpu и vaapi вообще почти в три раза.
А вот с vulkan там какая то беда, при его использовании декодер видяхи только наполовину нагружается, так что он еще в два раза медленнее чем vaapi.

Есть деб-мультимедия, там пепесобирают ffmpeg, имеет смысл попробовать его.

у меня ffmpeg собран и с ваапи и с вулканом

configuration: --prefix=/home/orlovsn/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/orlovsn/ffmpeg_build/include --extra-ldflags=-L/home/orlovsn/ffmpeg_build/lib --extra-libs='-lpthread -lm' --ld=g++ --bindir=/home/orlovsn/bin --enable-chromaprint --enable-frei0r --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libdav1d --enable-libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libmp3lame --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsvtav1 --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-nonfree --enable-opengl --enable-openssl --enable-version3 --enable-librubberband --enable-libharfbuzz --enable-libwebp --enable-libzimg --enable-libzvbi --enable-libgsm --enable-libvvenc --enable-vaapi --enable-vulkan

проблема явно где-то на стороне вулкана, который не может цепануть быстрое ГПУ (но может чахлика) и ваапи который видимо падает на софтовый дефолт

Про Вулкан:

Попробуй таки с export RADV_PERFTEST=‘video_decode’.

У меня без него не заводится вулкан декодирование ни на дискретке, ни на встройке.

сейчас попробую rocm навернуть

а не, это я в себя слишком поверил :-D

*** dma_resv->seq is missing. exit…. Stop.

и судя по багтрекеру это уже годами на дебиане по разным причинам, для 13 обещают починить «когда-нить в составе рокм7»

Ну точно скам :-D

Так основной смысл в энергопотреблении, а не производительности.

не совсем - на соседней машине rtx 4060 в два раза быстрее декодирует чем 14900 на h264_cuvid
мне просто много потоков надо паралелльно декодировать - смысл декодера разгрузить цпу и сразу свалить на гпу как минимум ресайз (ффмпег из коробки умеет судя по докам в ресайс в вгпу) и потом еще по возможности сразу как мат для opencv пользовать не гоняя в основную озу но это следующий шаг, хотелось бы для начала сам декодер оживить

увы но не помогло

Такс, трикси реально не поддерживает 9060.
Обновляемся до тестинга (бекпорты полумера на будущее) 🤣

Тестинг пришлось ставить с нуля ибо попытка воткнуть amdgpu не прошла незаметно и обвалила графоний от слова совсем
На чистеньком свеженьком тестинге с 6.16 ядром я так же печально не узрел декодера для вулкана на 9060 и профита от ваапи.
Видимо не судьба, радеон придется менять на правоверную невидию 🫤

su -c modprobe i-rinat

Нет смысла на бинарных дистрах сидеть — у них там непонятно с какими флагами собран софт.

Зато GPL, ты умный, ты допишешь.

Нет смысла на бинарных дистрах сидеть — у них там непонятно с какими флагами собран софт.

ffmpeg рассказывает по дефолту при запуске какие были флаги сборки, меса вроде давно везде с вулканом собирается, в 6.16 радеон есть и дебиан на удивление даже сам подтянул для него firmware т.е. проблема скорее глобальна чем дебиана

Зато GPL, ты умный, ты допишешь.

у меня лапки, я просто хочу жонглировать картинками на глазах у удивленной публики ^_^

LIBVA_DRIVER_NAME=radeonsi vainfo

Вот откуда берётся «В вашем линукс ничего не работает!». А потом оказывается тот линукс, на котором пробовали запустить «что не работает» — софт собран хрен пойми как и с какими флагами. И половина того, что должно работать просто не работает.

ffmpeg рассказывает по дефолту при запуске какие были флаги сборки

И посмотрев их внимательно увидишь что нужных флагов нет и пойдёшь ставить дев пакеты, занимающие десятки гигобайт превращая твой бинарный дистрибутив в сурсбейсед с убогими возможностями для сборки в отличие от сурсбейсед, пересобирая пакеты с нужными тебе флагами. А потом ещё найдёшь пакет, который без нужных тебе флагов собран, и ещё и ещё... В результате накопится больше половины пакетов дистра и смысл сидеть на бинарном дистре пропадает полностью!

Известная тропинка. ))

AMD

Мыши плакали, кололись, но продолжали есть кактус

А потом оказывается тот линукс, на котором пробовали запустить «что не работает» — софт собран хрен пойми как и с какими флагами.

Sir, парой постов выше выложены флаги сборки ffmpeg в которых есть и vulkan и vaapi и non-free чо уж там.
А вот откуда берутся лозунги «у амуде открытые дрова которые работают из коробки ведь они же прям в ядре и поддерживаются лучше всех!!1» действительно интересно 😁

у амуде открытые дрова которые работают из коробки

Так и есть, в рамках твоего вопроса.
У тебя изначально под vaapi все работало и быстрее работать не будет, ни под linux, ни под windows, по крайней мере в ffmpeg.

На тестинге так:

Trying display: wayland
libva info: VA-API version 1.22.0
libva info: User environment variable requested driver 'radeonsi'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_22
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.22 (libva 2.22.0)
vainfo: Driver version: Mesa Gallium driver 25.0.7-2 for AMD Radeon Graphics (radeonsi, gfx1200, ACO, DRM 3.64, 6.16.3+deb14-amd64)
vainfo: Supported profile and entrypoints
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain10             : VAEntrypointVLD
      VAProfileHEVCMain10             : VAEntrypointEncSlice
      VAProfileJPEGBaseline           : VAEntrypointVLD
      VAProfileVP9Profile0            : VAEntrypointVLD
      VAProfileVP9Profile2            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointVLD
      VAProfileAV1Profile0            : VAEntrypointEncSlice
      VAProfileNone                   : VAEntrypointVideoProc

У тебя изначально под vaapi все работало и быстрее работать не будет, ни под linux, ни под windows, по крайней мере в ffmpeg.

меня смущает не столько сильно падающая скорость декодирования (допустим бытовые гпу действительно не рассчитаны молотить гигапиксели из коробки ибо не типовой режим использования) сколько то что при включении vaapi нагрузка на cpu не падает т.е. текущая реализация драйвера - как минимум унылая (ну или не работающая) ибо под оффтопиком декодер этой-же 9060ой таки разгружает cpu на таком-же ffmpeg’е - т.е. физически что декодер может что процесс в ффмпеге построен логично.

и это я пока сравниваю «в лоб» т.е. на один декодер отдельный поток, под невидией я могу в одном контексте куды декодировать несколько потоков параллельно - на радеоне это видимо остается «за кадром» :/

https://trac.ffmpeg.org/wiki/Hardware/VAAPI Транкодинг так выглядит примерно, тут для декодинга и энкодира нужно указывать методы, пример для одной видяхи.

LIBVA_DRIVER_NAME=radeonsi ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.mp4 -c:v h264_vaapi output.mp4

Да, но я не делаю транскодинг, мне пока нужен только декодер и насколько я понимаю -benchmark даже не выгружает результат в бгр в озу (хотя потом ресайз и преобразование в бгр ессно тоже надо будет скинуть на гпу)

Вангую, vaapi и vdpau не предназначены для транскодирования множества видео файлов, они просто для ютюбчика и конференций, не на большие мощности, а для энергосбережения, поэтому cuda, opencl и подобные инструменты возможно будут быстрее.

при включении vaapi нагрузка на cpu не падает

А ты вроде такую статистику и не предоставлял.
Когда все работает, то нагрузка на cpu должна быть 1% в районе погрешности, а на декодер gpu(vcn) - 100%

Давно уже не ковырял тему аппаратных декодеров, и с тех пор могло всё поменяться. Но думается, что некоторые аспекты должны были остаться.

• Утилита ffmpeg и библиотеки ffmpeg это два разных мира. Даже если станешь гуру в опциях утилиты ffmpeg, при использовании библиотек придётся начинать чуть ли не заново.
• Утилита ffmpeg любит копировать картинку из GPU обратно на CPU, чтобы фильтры работали. Нужно опциями подбирать режим работы, когда всё декодированное остаётся в памяти GPU.
• API для использования декодеров в ffmpeg много раз менялся. Инструкции из интернета могут быть несколько раз устаревшими. API ffmpeg вообще не является чем-то стабильным. Миграция на новую версию может потребовать адаптации кода. Обычно они довольно мелкие.
• Большую часть производительности сжирает масштабирование картинки на CPU и её забор обратно из памяти GPU.
• Собственно декодирование H.264 уже лет 10 назад было достаточно дешёвым. От переноса только декодирования на GPU выигрыша не будет. Нужно как можно меньше делать на CPU.
• Декодер на CPU может оказаться быстрее декодера на GPU.
• С GPU бывают сюрпризы в виде ограничения на число одновременных потоков декодирования, число выделенных поверхностней и тому подобное. Раньше такое всплывало на NVIDIA. На встройках Intel таких ограничений не видел, а с AMD особо опыта не было. Возможно, с NVIDIA ограничения были в драйвере. Давно не проверял.