ffmpeg тормозит без видимых причин?

Пальцем в небо, но например упёрлось в сеть/другое io, или 100% загрузку одного ядра процессора, или в скорость памяти.

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

Если бы была проблема с одним ядром, то это, вероятно, показывал бы htop. Между тем, он показывает более-менее равномерную нагрузку на ядра.

Ввод-вывод я попытаюсь проверить iotop'ом. А как проверить идею насчёт скорости памяти?

посмотри нагрузку на диск.

Где же узкое место?

в виртуальной машинке

Что за «виртуальная машинка»? Какие потоки, какой кодек, какие параметры. Нагрузку ffmpeg в широких рамках регулируется настройками кодека.

Можно попробовать ограничить число потоков кодирования для одного процесса - 'ffmpeg ... -threads 1 ...'.

Нагрузка на диск минимальна. Проверял с помощью gstat.

Виртуалка - четыре ядра (а теперь и пять) уровне Intel Core i5, 4 гига памяти.

Процесс выглядит так:

ffmpeg -hide_banner \ -i «udp://@234.5.1.111:1234?fifo_size=10485760&buffer_size=10485760&overrun_nonfatal=1» \ -c:v libx264 -s 320x240 -aspect 4:3 -profile:v main -preset:v slow -x264opts force-cfr:subme=7:ref=4 -threads 0 -r 25 -b:v 325k -maxrate 325k -bufsize 160k -g 75 -keyint_min 75 -crf 18 \ -ar 48000 -strict experimental -c:a aac -b:a 128k -dts_delta_threshold 1000 -ac 2 -isync -af aresample=async=1000 \ -start_number 0 -hls_flags delete_segments -hls_time 10 -hls_list_size 5 -f hls ./test/Test1/playlist.m3u8 \ -c:v libx264 -s 448x336 -aspect 4:3 -profile:v main -preset:v slow -x264opts force-cfr:subme=7:ref=4 -threads 0 -r 25 -b:v 750k -maxrate 750k -bufsize 375k -g 75 -keyint_min 75 -crf 18 \ -ar 48000 -strict experimental -c:a aac -b:a 128k -dts_delta_threshold 1000 -ac 2 -isync -af aresample=async=1000 \ -start_number 0 -hls_flags delete_segments -hls_time 10 -hls_list_size 5 -f hls ./test/Test2/playlist.m3u8 \ -c:v libx264 -s 640x480 -aspect 4:3 -profile:v main -preset:v slow -x264opts force-cfr:subme=7:ref=4 -threads 0 -r 25 -b:v 1536k -maxrate 1536k -bufsize 768k -g 75 -keyint_min 75 -crf 18 \ -ar 48000 -strict experimental -c:a aac -b:a 128k -dts_delta_threshold 1000 -ac 2 -isync -af aresample=async=1000 \ -start_number 0 -hls_flags delete_segments -hls_time 10 -hls_list_size 5 -f hls ./test/Test3/playlist.m3u8 \ -c:v libx264 -s 640x480 -aspect 4:3 -profile:v main -preset:v slow -x264opts force-cfr:subme=7:ref=4 -threads 0 -r 25 -b:v 2048k -maxrate 2048k -bufsize 1024k -g 75 -keyint_min 75 -crf 18 \ -ar 48000 -strict experimental -c:a aac -b:a 128k -dts_delta_threshold 1000 -ac 2 -isync -af aresample=async=1000 \ -start_number 0 -hls_flags delete_segments -hls_time 10 -hls_list_size 5 -f hls ./test/Test4/playlist.m3u8

Параметр -threads 1, ясное дело, убивал весь процесс. Пытался играться с crf и проч., но шибко не помогало :(

Мда ну и разрешения, вы на нокия3310 вещаете чтоли. Как только вы выставите preset=veryfast и выкините x264opts у вас сразу все завретится

Попробуй четыре процесса ffmpeg вместо одного

-b:v 325k ... -crf 18

что-то одно, либо битрейт, либо crf, а то получается, что ты при неплохом таком значении crf можешь взять и поставить себе битрейт на выбор )

Outputting and re encoding multiple times in the same FFmpeg process will typically slow down to the «slowest encoder» in your list. Some encoders (like libx264) perform their encoding «threaded and in the background» so they will effectively allow for parallel encodings, however audio encoding may be serial and become the bottleneck, etc. It seems that if you do have any encodings that are serial, it will be treated as «real serial» by FFmpeg and thus your FFmpeg may not use all available cores. One work around to this is to use multiple ffmpeg instances running in parallel, or possible piping from one ffmpeg to another to «do the second encoding» etc. Or if you can avoid the limiting encoder (ex: using a different faster one [ex: raw format] or just doing a raw stream copy) that might help.

-strict experimental -c:a aac

попробуй ещё версию обновить

hizel, разрешения довольно типовые для публичного hls, если брать канал среднего качества, а не HD. Спасибо за рекомендацию, попробую veryfast. Только кажется, что хотя всё и залетает, качество будет совсем отстой.

ZenitharChampion, да, разделение на независимые процессы коренным образом изменило ситуацию. Отставания прекратились. Но появилась другая проблема, связанная, скорее всего, именно с этим разделением. hls-плеер ведь пытается подобрать лучший битрейт. Так вот, при переключении с одного битрейта на другой наблюдаются зависания. Похоже, разделение на процессы привело к небольшому рассинхрону между результирующими потоками, и для адаптивного hls это оказалось критичным. Но это пока гипотеза, диагностику ещё не проводил. Пытаюсь разобраться, умеет ли VLC скакать между битрейтами, и как это понять по его логам.

anonymous, да, у меня в командной строке много всякой хрени наворочено. Наверняка что-то лишнее, дублирующее или избыточное. А ещё, возможно, имеет смысл вынести в отдельный процесс транскодирование аудиодорожки. Чем дублировать её каждый раз в отдельном потоке.

ffmpeg тормозит без видимых причин? (комментарий) :)

ffmpeg тормозит без видимых причин? (комментарий) :)

Тег [user] в помощь :-) Рассинхрон, говоришь? А что если запускать процессы ffmpeg не тыкая пальцами в клавиатуру 4 раза, а скриптом, который запустит их в одну миллисекунду?

Спасибо :) Думаю над этим вариантом. Хочу попробовать. Как только, так сразу отпишусь.