Ffmpeg использовать все ядра процессора

Обновлено: 16.05.2024

Но он использует% 15-20 процессора, мне нужно сделать 16 потоков на том же сервере, но я не могу.

Я не могу сделать конфигурацию, например, просто загрузить .ts файлы, клонирующие m3u8?

3 ответа

По умолчанию FFmpeg будет пытаться перекодировать ввод, даже если вы не используете никаких параметров, связанных с кодированием.

Если вы хотите просто скопировать поток как есть, попробуйте использовать функцию streamcopy:

Копируя входящие потоки, вы можете полностью пропустить процесс кодирования.

Итак, ваша команда будет выглядеть так:

(Не уверен, что это сработает.)

Когда вам нужно перекодировать входящий поток, вы должны добавить некоторые параметры кодирования в команду.

По умолчанию ffmpeg пытается сопоставить исходные параметры и качество, которые не всегда самые оптимальные в реальных приложениях.

«Очень быстрые, сверхбыстрые и сверхбыстрые» пресеты h264 - хорошее начало для повышения производительности.

Вы также можете поиграть с кодированием CRF (коэффициент постоянной скорости), более высокими битрейтами и т. Д.

Хотя этот вопрос уже считается ответом, я полагаю, что в нем нет ответа, который не включает настройку параметров команды и, тем не менее, может использоваться с другими инструментами или командами, а не только с FFmpeg.

Инструмент CPUlimit предназначен именно для этой цели и будет эффективно работать не только для FFmpeg, но и для любых других ресурсоемких процессоров. Процесс, который вы хотите уменьшить использование этого ресурса.

Наиболее важным аргументом CPUlimit является -l , который позволяет вам указать процент CPU, который процессу будет разрешено использовать (в качестве его верхнего предела).

Также обратите внимание, что этот предел зависит от количества процессоров / ядер / потоков, которые есть на машине, например, если на машине установлено 8 процессоров, допустимые значения CPULimit -l будут в диапазоне от 0 до 800 (0 - бесполезно, конечно, и 800 означает не ограничивать процесс вообще, так как 800% означает всю производительность машины).

Пример использования половины емкости для компьютера с 8 процессорами:

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

Кроме того, что касается исходного вопроса, если вы пытаетесь ограничить сценарий bash (или все, что разветвляется на дочерний процесс), обязательно добавьте параметр -i или --include-children и укажите местоположение сценария. если это не в PATH.

Чтение ввода с частотой кадров. В основном используется для имитации устройства захвата или живого потока ввода (например, при чтении из файла). Не следует использовать с реальными устройствами захвата или живыми входными потоками (где это может привести к потере пакетов).

По умолчанию FFmpeg пытается читать ввод (ы) как можно быстрее. Эта опция замедлит чтение входных данных до исходной частоты кадров входных данных. Это полезно для вывода в реальном времени (например, прямой эфир).

Я вижу, что есть -threads <count> параметр командной строки в ffmpeg. Каково значение этого параметра по умолчанию?

Это зависит от используемого кодека, версии ffmpeg и количества ядер процессора. Иногда это просто один поток на ядро. Иногда это сложнее, как:

с libx264 это ядра x 1.5 для фреймовых потоков и ядра x 1 для слайсовых потоков.

по состоянию на 2014 год, он использует оптимальное число.

вы можете проверить это на многоядерном компьютере, изучив загрузку процессора (Linux: top , Windows: диспетчер задач) с различными параметрами для ffmpeg:

-threads 0 (оптимальный);

-threads 1 (однопоточный);

-threads 2 (2 потока, например, для Intel Core 2 Duo);

none (по умолчанию, также оптимальный.)

2015 редактировать: на 12-ядерном процессоре некоторые команды ffmpeg имеют Linux top показывает не более 200% cpu (только 2 ядра), независимо от того, какое число дано -threads . Таким образом, значение по умолчанию все еще может быть оптимальным в смысле "так хорошо, как этот двоичный файл ffmpeg может получить", но не оптимальным в смысле "полного использования моего процессора leet."

в 2015 году на Ubuntu 14.04 с ffmpeg 0.8.10-6, он использовал 1 ядро на 4 ядра системы. htop показал это; только одно ядро было использовано, и я получил коэффициент конверсии 16 кадров в секунду для видео FullHD.

используя -threads 4 сделал все мои ядра процессора идут на 100%, и я получил коэффициент конверсии 47 кадров в секунду.

я использовал следующую команду:

Если вы включили резьбы, назначили 1,5 х Количество ядер.

играя с некоторыми преобразования в CentOS 6.5 VM (Ryzen 1700 8c / 16t-vm назначен 12 из 16 ядер) делает некоторые стандартные def (480p) фильмы сетчатой следующее:

вариант потока / конверсионный курс (ФПС @ 60 секс) (нет / по умолчанию) / 130fps -потоки 1/70fps -нити 2/120 кадров в секунду -потоки 4/185fps -нити 6/228fps -нити 8/204fps - темы 10 / 181fps

интересная часть была загрузка процессора (с помощью htop, чтобы посмотреть его). Используя вариант никак-резьб заведенный вверх на ряде 130fps с распределением нагрузки по всем ядрам на низком уровне нагрузки. Используя 1 нить сделал именно это, загрузил одно ядро на 100%. Использование чего - либо еще привело к другой ситуации с распределенной нагрузкой.

Как вы можете видеть, есть также Точка уменьшения отдачи, поэтому вам придется настроить опцию-threads для вашей конкретной машины. Для моей установки, в частности, использование-threads 6 (на 12-ядерном компьютере) привело к лучшему FPS при преобразовании видео (от h264 до x264 с другим битрейтом для принудительного преобразования) и возвращает на самом деле уменьшилось больше потоков, которые я бросил в него.

Это тоже могла быть проблема с памятью - виртуальной машине было назначено только 1 ГБ. Я могу настроить это и посмотреть, изменится ли что-нибудь. Тем не менее, это показывает, что использование опции-threads может увеличить производительность, поэтому запустите некоторые тесты на вашей конкретной машине на разных уровнях, чтобы найти свое сладкое место.

Периодически, я интересуюсь видеокодеками и тем, насколько они становятся эффективнее по сравнению со своими предшественниками. В свое время, когда после H264 вышел HEVC, мне было безумно интересно его пощупать, но мое железо того времени оставляло желать лучшего.

Сейчас же железо подтянулось, но и HEVC давно устарел, ему на смену жаждет придти открытый AV1, обещающий нам до 50% экономии по сравнению с 1080p H264, но если скорость качественного кодирования в HEVC кажется медленноватой (по сравнения с H264), то AV1 со своим

0.2 fps деморализует полностью. Когда что-то кодируется настолько медленно, то это значит, что даже простой 10 минутный ролик, будет обрабатываться около суток. Т.е. чтобы просто посмотреть подходят ли параметры кодирования или нужно добавить немного битрейта, придется ждать не просто часами, а днями…

И вот, как-то раз, любуясь красивым закатом (кодека H264), я подумал: «А что, если натравить на AV1 все железо которое у меня есть одновременно?»

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

Посмотрев, что у нас есть на сегодня актуального по AV1, я составил список:

Встроенный в ffmpeg кодировщик libaom-av1
Проект rav1e
Проект SVT-AV1

Кодировщик разрежет исходное видео на кусочки по n секунд
На каждом моем компьютере будет web-сервер со специальным скриптом
Мы кодируем в один поток, а значит сервер может одновременно кодировать столько кусочков, сколько у него процессорных ядер
Кодировщик будет отправлять кусочки на серверы, и скачивать обратно закодированные результаты
Когда все кусочки будут готовы, кодировщик склеит их в один и наложит звук из исходного файла

Реализация

Сразу скажу, что реализация сделана под Windows. В теории ничего не мешает сделать тоже самое и под другие ОС, но я делал под то, что стояло у меня.

Web-сервер с PHP
ffmpeg
rav1e

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

2. FFmpeg — готовые бинарники я качал с Zeranoe builds

3. rav1e — также можно скачать бинарник из релизов проекта rav1e

PHP скрипт для каждого компьютера, который будет участвовать

Получаем кусочек, сохраняем его в папку
Генерим CMD файл с командой для кодирования и удаление самого CMD файла в конце
Запускаем CMD файл

Есть исходный файл, есть файл результата и есть CMD файл — кодирование еще идет
Есть исходный файл, есть файл результата и CMD файла нет — кодирование завершено

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

Локальный скрипт для запуска кодирования encode.php

Лежит где угодно. Важный момент: как вы видите, командная строка для кодирования прописывается именно в этом файле и эти пути должны быть едины на всех серверах. Поэтому на каждом сервере я скопировал файлы:

c:\Apps\OneDrive\commands\bin\ffmpeg\ffmpeg.exe — из Zeranoe builds
c:\Apps\OneDrive\commands\bin\ffmpeg\rav1e.exe — из проекта rav1e

Файл для запуска скрипта кодирования, лежит рядом со скриптом. Путь к PHP настраиваете сами.
encoding.cmd:

Поехали?

Для теста я использовал известный мультик про кролика Big Bucks Bunny, длиной 10 минут и размером 150Мб.

Железо

AMD Ryzen 5 1600 (12 потоков) + 16GB DDR4 (Windows 10)
Intel Core i7 4770 (8 потоков) + 32GB DDR3 (Windows 10)
Intel Core i5 3570 (4 потока) + 8GB DDR3 (Windows 10)
Intel Xeon E5-2650 V2(16 потоков) + 32GB DDR3 (Windows 10)

Командная строка с параметрами

Результаты

Время кодирования: 55минут
Размер видео: 75мб

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

Отдельно отмечу, что для 1080p требуется около гигабайта оперативной памяти на поток, поэтому памяти должно быть много. Также замечу, что под конец стадо бежит со скоростью самого медленного барана и в то время как Ryzen и i7 уже давно закончили кодирование, Xeon и i5 еще продолжали пыхтеть над своими кусочками. Т.е. более длинное видео в целом кодировалось бы с большим общим fps за счет того, что более быстрые ядра успели бы сделать больше работы.

Запуская конвертацию на одном Ryzen 5 1600 с многопоточностью, максимум что я имел было около 1.5 fps. Здесь же, учитывая, что последние 10 минут кодирования — это добивка последних кусочков медленными ядрами, можно сказать, что получилось около 5-6 fps, что уже не так мало для такого продвинутого кодека. Вот и все, чем я хотел поделиться, надеюсь кому-нибудь это может пригодиться.

FFMpeg

Преимущества кодирования/декодирования видео мы будем рассматривать на примере FFmpeg. Это популярная бесплатная программа, с открытым исходным кодом, доступная на Linux и Windows. Разработка FFmpeg ведется довольно активно, что указывает на расширение функционала и повышения стабильности программы от релиза к релизу.

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

Что будем кодировать

Знакомство с кодированием на GPU начнем с NVIDIA и ее технологии NVDEC/NVENC.

NVIDIA NVENC

Обратите внимание, блоки NVDEC, NVENC располагаются отдельно от CUDA Cores, тем самым не создавая нагрузку на графический процессор, который в данный момент занимается важными делами (например, обрабатывает PhysX и Bullet для любимой компьютерной игры).

Установка

FFmpeg с поддержкой аппаратного кодека NVENC можно легко собрать из исходников, а можно воспользоваться и готовой сборкой для Windows.

Сборка из исходников

Далее, необходимо сделать:

Готовые пакеты

и ищите строчку с префиксом nvenc:

Пример

Теперь можно запустить аппаратное кодирование через ffmpeg и насладиться скоростью:

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

Центральный процессор при этом загружен минимально.

Кодек NVENC в ffmpeg предоставляет большое количество опций для выбора оптимального метода сжатия: несколько предустановленных профилей, постоянный/переменный битрейт, многопроходное кодирование и еще много других опций полный список, которых можно посмотреть выполнив:

Условия теста простейшие. Сначала сконвертируем фрагмент видео обычным способом (на CPU), затем сконвертируем на аппаратном кодеке NVENC и сравним времена.

По факту имеем ускорение в 2 раза.

Intel Quick Sync Video

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

QSV поддерживает следующие форматы видео; mpeg2, h.264, hevc. Есть несколько пресетов для аппаратного кодека: veryfast, faster, fast, medium, slow, slower, veryslow. Реализовано многопроходное кодирование. Есть возможность задания точного значения битрейта.

Установка

FFMpeg с поддержкой Intel QSV можно собрать из исходников, как под Linux, так и под Windows. Процесс этот довольно простой, поэтому его описание я приводить не буду. Для тех, кто не хочет заморачиваться со сборкой из исходников, в сети есть прекрасный ресурс, где выкладываются самые свежие версии FFMpeg с поддержкой QSV. Рекомендую скачивать статическую версию FFMpeg.

Чтобы проверить содержит ли скачанная версия FFMpeg поддержку qsv для декодирования/кодирования, выполните:

Если там будет вот такая строчка с h264_qsv:

Значит все в порядке и можно приступать к кодированию.

Пример

Простейший пример кодирования видео с помощью аппаратного ускорения в Intel GPU:

Тест проводился на стареньком ноутбуке ASUS с процессором Intel Core i3.

Согласитесь, неплохая прибавка (x4) к скорости кодирования на ноутбуке.

Выводы

Когда я впервые собрал ffmpeg с поддержкой GPU и попробовал сравнить скорость кодирования с обычным вариантом на CPU, честно говоря испытал какой-то взрыв эмоций. Вот ноутбук, видео кодируется обычно час, но оказывается на этом же ноуте можно сконвертировать за 15-20 минут. Ощущается, как халява. Двух-трехкратное ускорение, просто из ничего! При этом процессор свободен и можно заниматься своими делами и ничего не тормозит.
Конечно же никакой Америки я не открыл и эта технология давно используется. Тем не менее приятно задействовать все ресурсы ноутбука из которого казалось бы выжато уже все, что можно:-)

Читайте также: