cingg создание прокси-файла внешней командой ффмпег

Скрипт точно работает на rx550 и для другой карты требует адаптации.

Благодарю.

Я лично делал этой командой тогда:

ffmpeg -i $filename -s 320x180 $filename.proxy-6.avi

Не знаю насколько это правильно, но я так делал.

Насчет рендера: Есть подозрение что возможно проблема может быть то ли из-за самого формата MTS, то ли может из-за тормознутости usb3.1 флешки на 128 гигабайт с разогнанными частотами производителем. Эта флешка то работает очень быстро, то зависает намертво на минуту. (Проблема именно с флешкой, она так себя ведет на всех компьютерах)

Кстати, если рендерить в режиме прокси, то ролик получается без разрывов. Разрывы именно с оригинальными клипами. Отключил кеширование переходов, разрывов стало меньше.

У меня ролик с кучей кривых скорости. В последнее время слишком пристрастился к этой возможности. Возможно из-за неё могут быть проблемы, кто знает…

А может с проксями накосячил. Ведь делал примитивней не куда.

ну, поступило предложение выставить hwaccel=auto …и там же есть переменные окружения на которые cin реагирует.

https://cinelerra-gg.org/download/CinelerraGG_Manual/GPU_hardware_decoding.html

CIN_HW_DEVICE может и выбор устройства renderer128+ можно туда же прикрутить …. (у меня теперь есть ноут с двумя видяшками)

Я лично делал этой командой тогда

Вся суть скрипта в том, чтобы возложить уменьшение размера и перекодировку на видеокарту, она это делает плохо по качеству, но быстро,то что надо для создания прокси файла.

За скрипт благодарю, но в Orange Pi 4 lts с аппаратным кодированием и уменьшением размера мне ничего не понятно. Вроде модуль Hantro в ядре есть, а что дальше надо с ним делать, понятных инструкций не дано.

ну, поступило предложение выставить hwaccel=auto

Тогда надо и остальную часть скрипта брать из cinelerra, включая кодеки и профиль. При этом опросить видеокарту, какие кодеки она понимает и с какими профилями.

работает на rx550

А насколько эта видеокарта хороша для Cinelerra-GG и Cinelerra-HV 8?

Делал титры с прозрачностью к одному ролику в программе CinGG за Celeron J4005.

В формате проекта указал RGBA 8bit.

В настройках рендера выбрал PNG Sequence со включенной прозрачностью.

Отрендеренный результат получился не с прозрачным, а с черным фоном.

В Natron, например, такой проблемы нет.

Вопрос: Может я что-то не так делаю?

https://www.youtube.com/watch?v=XobSAXZaKJ8

а черный фон если обратно в cingg секвенцию загрузить или вообще везде?

Рендерит без альфа-канала. Просто открываю первый попавшийся кадр просмоторщиком изображений и сразу становится ясно что альфа-канала там нет.

Пришлось создавать титры заново в программе Natron. Экспортировал в ту же PNG секвенцию и импортировал её потом в CinGG. Работает как надо, но Natron, как я понял, под ARM не собрать.

Я так понимаю что для ARM только 3 программы для композитинга существуют стабильно работающие - AviSynth+, VapourSynth и CinGG.

cтранно, у меня альфа-канал есть, но целиком на 1.0 весь - посмотрел в gimp-e

Я пытался просто фэйдером сделать дорожку полупрозрачной. А ты чем делал?

так, похоже это баг.

Если создавать изображения exr/png - то альфы нету, а если tiff - то есть. Еще можно через ffmpeg png создавать.

кажется я нашел баг.

просьба протестировать патч

--- a/cinelerra-5.1/cinelerra/virtualvconsole.C                         +++ b/cinelerra-5.1/cinelerra/virtualvconsole.C                         @@ -101,7 +101,7 @@ int VirtualVConsole::process_buffer(int64_t input_position,                                                                                                                                                 EDLSession *session = renderengine->get_edl()->session;                 int clr_color = session->cwindow_clear_color;                   -       vrender->video_out->set_clear_color(clr_color, 0xff);           
+       vrender->video_out->set_clear_color(clr_color, 0x00);                                                                                           if(use_opengl)                                                          {                                                               --

то есть после строчки

vrender->video_out->set_clear_color(clr_color, 0xff);

добавить эту

vrender->video_out->set_clear_color(clr_color, 0x00);

?

нет, просто в этой строчке поменять 0xff -> 0x00

Понял, когда появится время, протестирую.

А насколько эта видеокарта хороша для Cinelerra-GG

Чего-то пропустил это сообщение. Ну, она работает, если учесть, что синелерра все делает на ЦП, кроме воспроизведения, там аппаратное ускорение очень приятно, но опять же не всех форматов. Например картинки и 4к она не сможет показать, а фулл хд как раз. Можно ещё пытаться делать эффекты через ffmpeg с аппаратным ускорением. Прокси я делал именно через ffmpeg, было быстро.

Сейчас у меня встройка на 5300u там аппаратная поддержка 4к, старый проект можно делать без проксей, что прикольно. Но опять же все зависит от применяемых эффектов.

Да не, 4к меня особо не интересует, ибо хорошие 4к камеры - это очень дорого. Я себе и фуллхдешную Canon EOS C100 позволить вообще никак не могу. Дорого. Пользуюсь сенсором 1/3 в фуллхд.

А как там дела с эффектом хромакея + картинками в режиме моушн трекинга и каким-нибудь фоном? RX’а 550 потянет в фуллхд 1:1 предпросмотре с минимальными задержками или таки будет слабовата? Или она картинки совсем не показывает?

ибо хорошие 4к камеры - это очень дорого

Согласен, я вообще снимаю на телефон с гиростабилизированной палкой.

А как там дела с эффектом хромакея + картинками в режиме моушн трекинга и каким-нибудь фоном?

Честно говоря не знаю, но думаю не потянет.

RX’а 550 потянет в фуллхд 1:1 предпросмотре с минимальными задержками или таки будет слабовата?

Если есть небольшой тестовый проект, скидывай, могу попробовать. Просмотр 1:1 с цветокоррекцией тянет, всякие стабилизации уже нет.

Или она картинки совсем не показывает?

Если мы говорим про аппаратное ускорение, то для картинок его нет, если синелерра сможет переключится на ходу на софтварь то сможет. А так на прошлогодней версии у меня был черный экран вместо картинки, решил просто - сделал минимальный видеоролик в mp4 из этой картинки.

Ну то есть для моушн трекинга лучше иметь очень многопоточный процессор, например xeon из алиэкспресса?

Если есть небольшой тестовый проект

Если железо не повиснет намертво, то попробую сделать.

Вот что у меня выдает ffmpeg -filters | grep vaapi и соответственно может быть выполнено быстро на видеокарте (ноутбучная встройка amd):

deinterlace_vaapi V->V       Deinterlacing of VAAPI surfaces
denoise_vaapi     V->V       VAAPI VPP for de-noise
overlay_vaapi     VV->V      Overlay one video on top of another
procamp_vaapi     V->V       ProcAmp (color balance) adjustments for hue, saturation, brightness, contrast
scale_vaapi       V->V       Scale to/from VAAPI surfaces.
sharpness_vaapi   V->V       VAAPI VPP ffmpeg deshake vs vidstabfor sharpness
tonemap_vaapi     V->V       VAAPI VPP for tone-mapping
transpose_vaapi   V->V       VAAPI VPP for transpose

Все что за пределами этих фильтров будет делаться на процессоре.

По поводу стабилизации видео, рекомендую загуглить ffmpeg deshake vs vidstab, там будут и сравнения и примеры использования. Говорят, что есть поддержка многопоточности, не проверял. Но в любом случае, всегда можно скриптом разрезать видео на количество процессоров и запустить стабилизацию каждого, а когда все закончат, слить их в одно видео. Тоже самое кстати можно и в синелерре, там есть свои фильтры по стабилизации, плюс распределенный рендеринг, я им тоже увлекался, работает. Его даже рекомендуется применять при рендеренге финала на многопоточном процессоре, будет быстрее и эффективнее.

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

лучше иметь очень многопоточный процессор, например xeon из алиэкспресса

Финал всегда лучше делать на процессоре, будет лучше как по качеству, так и по размеру файла. По поводу китайского зеона, тредрипер будет лучше, современный проц тоже, но они дешевы так почему бы и нет. Я свой микросервер рендерингом не нагружал еще.

сразу снимать стабильное видео

У меня для этих целей есть трипод. Вопрос был по поводу прикрепления картинок к движимим объектам из видео. Вот чисто интересно какое железо должно быть для комфортного использования этой возможности.

современный проц

Смотрел ценники и как-то не хочется столько денег тратить. Китайские зеоны тем и хороши что дают конкурентноспособную производительность за адекватные деньги, как мне думается.

В любом случае благодарю. Это очень полезная мне информация.

Спасибо большущее!

Рендерил PNG с прозрачностью - идеально!

Даже вставка титров с прозрачностью в режиме EDL починилась!

Шикарная работа! Огроменная благодарность!

Теперь могу делать титры прямиком в CinGG без использования Natron.

даже вставка титров с прозрачностью в режиме EDL починилась!

А можно поподробнее как такое делать? А то может я один баг «починил» другой добавил …

теоретически в ффмпег есть еще opencl фильтры, но заводить их на Радеоне пока сложно - OpenCL через clover недостаточно фичастый, а для rusticl нужен очевидно rust и всякие WIP merge requests с мезовского gitlab (я вроде в рассылку cingg отправил письмо про это).

Вопрос был по поводу прикрепления картинок к движимим объектам из видео.

А этим случаем не openCV занимается? Ну там всякие рамочки вокруг распознанных объектов ….

Открываю xml файл с титрами в режиме вставки в текущую позицию и референса. Раньше была вставка с черным фоном, теперь вставляет по задумке с прозрачным фоном.

Какие баги всплыли? Я проверял с прозрачностью и без, yuva и yuv. Все режимы отрабатывают своё. Что не так?

пока не знаю, я тут баг словил что не могу nested edl loading откатить по undo (z).

Поковырявшись в коде сделал так что теперь от undo загрузки nested edl не падает, зато почему-то все 25 файлов разом на 25 дорожек открыть можно, а вот откатить загрузку уже никак - зависон ….5-6 шт разом открываются

Тогда откатываемся к последнему рабочему варианту и забиваем на альфа-канал, иначе базовый видеомонтаж станет невозможным. А это самая важная часть программы. В этом вопросе под arm по комфорту cinGG нет равных.

не, это кажется отдельный баг с кэшем изображений, с альфа-каналом не связанный. Я просто его как пример использовал, чтобы сказать что я могу починить что-то одно и сломать что-то чем я не пользовался никогда.

Но кажется я этот крашер победил, посмотрим что в рассылке скажут (и я сам еще потестрессстирую)

https://lists.cinelerra-gg.org/pipermail/cin/2022-November/005840.html

вот. Там имя патча при загрузке с веб-интерфейса не показывается, так что надо переименовать вручную.

А патч про альфа-баг соответственно выше в другой ветке

https://lists.cinelerra-gg.org/pipermail/cin/2022-November/005821.html

https://lists.cinelerra-gg.org/pipermail/cin/2022-November/005841.html

ой, тестировать мне надо было лучше (баг с откатом загрузки nested edl я вроде как починил, но скорость проигрывания упала в единицы фпс. Поправил, вроде как ….)

Сколько fps выдает rx550 при аппаратном энкодинге h264_vaapi fullhd 25fps чистым ffmpeg? Заранее благодарен.

Постараюсь. А чтобы было с чем сравнить я пока сделал тесты на ноутбуке с ryzen 5300u:

hardware:
ffmpeg -threads 8 -hwaccel vaapi  -vaapi_device /dev/dri/renderD128 -i Тёмная\ ночь-312981129955.mp4  -c:v h264_vaapi -vf format=nv12,hwupload -vcodec h264_vaapi  -preset fast -c:a copy -bf 0 -profile:v 66 out.mp4
software:
ffmpeg -threads 8 -i Тёмная\ ночь-312981129955.mp4  -c:v h264 -vf "format=nv12" -vcodec h264  -preset fast -c:a copy -bf 0 -profile:v baseline out.mp4

hardware
frame= 5766 fps= 54 q=-0.0 Lsize=  245255kB time=00:03:50.63 bitrate=8711.5kbits/s dup=2 drop=0 speed=2.15x
software
CPU 1400MHZ
frame= 5766 fps= 36 q=-1.0 Lsize=  112925kB time=00:03:50.63 bitrate=4011.1kbits/s dup=2 drop=0 speed=1.46x  
CPU 2600MHZ
frame= 5766 fps= 52 q=-1.0 Lsize=  112925kB time=00:03:50.63 bitrate=4011.1kbits/s dup=2 drop=0 speed=2.09x

По размерам, исходник - 140Мб, на hardware 240Мб, software 110Мб.

rx550:

frame= 5766 fps= 28 q=-0.0 Lsize=  217988kB time=00:03:50.60 bitrate=7743.7kbits/s dup=2 drop=0 speed=1.11x

На процессоре i5-4460S:

frame= 5766 fps= 51 q=-1.0 Lsize=  112946kB time=00:03:50.60 bitrate=4012.2kbits/s dup=2 drop=0 speed=2.04x 

Выходит, что кодирование fullhd через ffmpeg на rx550 не имеет особого смысла. Хотя возможно создание именно proxy файлов будет быстрее, там сжимать нужно намного меньшую картинку.

P.S. А ноутбук то неплох, на уровне старого десктопа)))

Ну и создание proxy файлов:

hardware:
ffmpeg -threads 2 -hwaccel vaapi  -vaapi_device /dev/dri/renderD128  -i  "Тёмная ночь-312981129955.mp4" -c:v h264_vaapi -vf "format=nv12,hwupload,scale_vaapi=iw/6:ih/6" -vcodec h264_vaapi  -preset fast -c:a copy -bf 0 -profile:v 66 out.mp4

software:
ffmpeg -threads 4  -i  "Тёмная ночь-312981129955.mp4" -c:v h264 -vf "format=nv12,scale=iw/6:ih/6" -vcodec h264  -preset fast -c:a copy -bf 0 -profile:v baseline out.mp4

rx550:
frame= 5766 fps=160 q=-0.0 Lsize=   31695kB time=00:03:50.60 bitrate=1125.9kbits/s dup=2 drop=0 speed= 6.4x
i5-4460S:
frame= 5766 fps=243 q=-1.0 Lsize=   13477kB time=00:03:50.60 bitrate= 478.7kbits/s dup=2 drop=0 speed=9.72x

Ryzen Hardware:
frame= 5766 fps=106 q=-0.0 Lsize=   34254kB time=00:03:50.63 bitrate=1216.7kbits/s dup=2 drop=0 speed=4.25x
Software 1400Mhz:
frame= 5766 fps=169 q=-1.0 Lsize=   13477kB time=00:03:50.63 bitrate= 478.7kbits/s dup=2 drop=0 speed=6.75x

Штатная функция Cinelerra создает proxy для этого файла за 1 мин 45 сек, fps можно посчитать самому. Параметр threads в настройках прокси не влияет на загрузку системы, используется всегда 2 потока, а не 8 как в ffmpeg.

Удивила прежде всего низкая производительность железного кодировщика как rx550 так и ноутбучной встройки, ожидал сильно большего. Скорее всего когда писал тот скрипт, у меня был дрвухядерный пентиум, там rx550 прямо сильно заметно быстрее было, чем в cinelerra. Чуть менее древний i5-4460S прям неожиданно быстр. Ноут на 2600MHz не тестировал.

Спасибо огромное за тесты, теперь я знаю что RX550 не даст никакого прироста относительно встроенного кодировщика в Celeron J4005.

А сколько fps выдает Celeron J4005 в схожих условиях?

На Celeron J4005 я умудрился сломать Ubuntu, когда переустановлю, отпишусь.

На свежепоставленном Debian 11 на Celeron J4005:

С помощью похожей команды кодирование из MTS в MP4:

ffmpeg -threads 8 -hwaccel vaapi  -vaapi_device /dev/dri/renderD128 -i 00000.MTS  -c:v h264_vaapi -vf format=nv12,hwupload -vcodec h264_vaapi  -preset fast -c:a copy -bf 0 -profile:v 66 out.mp4

Немного лога:

ffmpeg version 4.3.5-0+deb11u1 Copyright (c) 2000-2022 the FFmpeg developers
  built with gcc 10 (Debian 10.2.1-6)
  configuration: --prefix=/usr --extra-version=0+deb11u1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-pocketsphinx --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100
Input #0, mpegts, from '00000.MTS':
  Duration: 00:00:34.56, start: 0.860000, bitrate: 23392 kb/s
  Program 1 
    Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 256 kb/s
Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified for stream 0, only the last option '-c:v h264_vaapi' will be used.
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_vaapi))
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
[h264_vaapi @ 0x563389bad4c0] H.264 baseline profile is not supported, using constrained baseline profile instead.
[h264_vaapi @ 0x563389bad4c0] No quality level set; using default (20).
[mp4 @ 0x563389cb3400] track 1: codec frame size is not set
Output #0, mp4, to 'out.mp4':
  Metadata:
    encoder         : Lavf58.45.100
    Stream #0:0: Video: h264 (h264_vaapi) (Constrained Baseline) (avc1 / 0x31637661), vaapi_vld, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 25 fps, 12800 tbn, 25 tbc
    Metadata:
      encoder         : Lavc58.91.100 h264_vaapi
    Stream #0:1: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, stereo, fltp, 256 kb/s
frame=    3 fps=0.0 q=-0.0 size=     256kB time=00:00:00.25 bitrate=8193.5kbits/frame=    8 fps=7.3 q=-0.0 size=    1024kB time=00:00:00.54 bitrate=15420.9kbits

Выдает 8.6 fps:

frame=  864 fps=8.6 q=-0.0 Lsize=   81116kB time=00:00:34.52 bitrate=19245.3kbits/s speed=0.342x

Для анекдота еще повторил с моим mp4 видеороликом:

ffmpeg -threads 8 -hwaccel vaapi  -vaapi_device /dev/dri/renderD128 -i Video_editing_on_calculators_for_naroda.mp4  -c:v h264_vaapi -vf format=nv12,hwupload -vcodec h264_vaapi  -preset fast -c:a copy -bf 0 -profile:v 66 out.mp4

И fps где-то тот же:

frame=  115 fps=8.6 q=-0.0 Lsize=    5699kB time=00:00:04.82 bitrate=9683.1kbits/s speed=0.362x

Похоже я погорячился когда предположил что Celeron J4005 не хуже чем RX550.

Похоже я погорячился когда предположил что Celeron J4005 не хуже чем RX550.

Надо бы сравнить на одинаковом материале. Исходник https://youtu.be/PGe9ruRxTkQ

Для анекдота еще повторил с моим mp4 видеороликом:

rx550 уже не могу протестировать, а вот rx6600 смогу, надеюсь что в ближайшее время. Если будет не влом, достану еще N2840 и проверю. Мне казалось, что железный энкодер должен плюс-минус 25фпс выдавать, а вона как.

rx550

Сейчас она должна совсем за муку продаваться если уже rx6600 за 23к можно найти.

Видать что-то не так с аппаратным энкодингом в Debian 11. Ибо в Debian 11 я получил 9 fps. Хотя несвободный интеловский vaapi пакет вроде устанавливал.

ffmpeg -threads 8 -hwaccel vaapi  -vaapi_device /dev/dri/renderD128 -i Тёмная\ ночь-PGe9ruRxTkQ.mp4  -c:v h264_vaapi -vf format=nv12,hwupload -vcodec h264_vaapi  -preset fast -c:a copy -bf 0 -profile:v 66 ~/out.mp4

В Ubuntu livecd 22.04 я получил 51 fps:

Celeron J4005 Hardware:
frame= 5767 fps= 51 q=-0.0 Lsize=  194919kB time=00:03:50.66 bitrate=6922.4kbits/s speed=2.02x

Cкорость энкодинга заметно быстрей чем у RX550. Даже догоняет Ryzen на удивление.

Видать что-то не так с аппаратным энкодингом в Debian 11.

У меня deb-multimedia по умолчанию включен. Неужели в дебиане собирают ffmpeg без аппаратного ускорения.

Добрался до стационарника с rx6600.

Прокси файл. Разницы нет:

frame= 5766 fps=167 q=-0.0 Lsize=   34249kB time=00:03:50.63 bitrate=1216.5kbits/s dup=2 drop=0 speed=6.68x

Энкодинг. Так же как в ноутбуке:

frame= 5766 fps=114 q=-0.0 Lsize=  245346kB time=00:03:50.63 bitrate=8714.7kbits/s dup=2 drop=0 speed=4.56x

Немного лога:

ffmpeg version 5.1.2 Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 12 (Debian 12.2.0-9)
configuration: --disable-decoder=amrnb --disable-decoder=libopenjpeg --disable-gnutls --disable-liblensfun --disable-libopencv --disable-podpages --disable-sndio --disable-stripping --enable-avfilter --enable-chromaprint --enable-frei0r --enable-gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-libaribb24 --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --enable-libdc1394 --enable-libdrm --enable-libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libkvazaar --enable-libmp3lame --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librist --enable-librsvg --enable-librubberband --enable-libshine --enable-libsmbclient --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-openssl --enable-postproc --enable-pthreads --enable-shared --enable-version3 --enable-vulkan --incdir=/usr/include/x86_64-linux-gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --toolchain=hardened --enable-vaapi --enable-libmfx --enable-libvmaf --enable-libilbc --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu
libavutil      57. 28.100 / 57. 28.100
libavcodec     59. 37.100 / 59. 37.100
libavformat    59. 27.100 / 59. 27.100
libavdevice    59.  7.100 / 59.  7.100
libavfilter     8. 44.100 /  8. 44.100
libswscale      6.  7.100 /  6.  7.100
libswresample   4.  7.100 /  4.  7.100
libpostproc    56.  6.100 / 56.  6.100

Добрался до стационарника с rx6600.

Энкодинг fps=114

Какой реактивный компьютер! Рендерит со скоростью света

Какой реактивный компьютер! Рендерит со скоростью света

Комп древний уже, а вот видюха свежая. Значит использовать железо для энкодинга имеет смысл, хотя бы тех же прокси файлов, раз качество там не важно.

А я еще не закончил. Потестил на Xeon E5-2650v3 2.30GHz 10 ядер.

Прокси на 20 потоков:

frame= 5766 fps=232 q=-1.0 Lsize=   13477kB time=00:03:50.60 bitrate= 478.7kbits/s dup=2 drop=0 speed=9.28x

И энкодинг 20 потоков:

frame= 5766 fps= 84 q=-1.0 Lsize=  112882kB time=00:03:50.60 bitrate=4010.0kbits/s dup=2 drop=0 speed=3.36x

10 потоков:

frame= 5766 fps= 90 q=-1.0 Lsize=  112882kB time=00:03:50.60 bitrate=4010.0kbits/s dup=2 drop=0 speed=3.59x