Опция счетчика потоков в FFmpeg для преобразования FASTEST в h264?
Мне нужно максимизировать скорость при конвертировании видео с помощью FFmpeg на h264
- Любой формат ввода исходных видеороликов
- Пользовательский аппарат может иметь любое количество ядер
- Потребляемая мощность и потребление памяти не являются проблемами.
Конечно, есть целая куча опций, которые можно настроить, но этот вопрос, в частности, касается выбора лучшего -thread <count>
. Я пытаюсь найти идеальный счетчик потоков как функцию
- нет. ядер
- формат входного видео
- h264-дружественные значения могут быть?
- что-то еще пропущено выше?
Я знаю, что значение по умолчанию -thread 0
соответствует принципу с одним потоком для ядра, который должен быть оптимальным. Но я не уверен, что это время или оптимизированное пространство. Кроме того, на некоторых тестовых ящиках я видел больше потоков (скажем, 4 потока на моей двухъядерной тестовой машине) заканчивается быстрее, чем по умолчанию.
В любом другом направлении, например, настройте параметры w.r.t. темы, заслуживающие внимания?
Ответы
Ответ 1
Я обнаружил, что threads
не очень хорошо используют все ядра, гиперпотоки вообще не используются. Одним из решений, которое я мог бы предложить, является одновременное выполнение от 3 до 4 процессов ffmpeg, см. https://superuser.com/questions/538164/how-many-instances-of-ffmpeg-commands-can-i-run-in-parallel/547340#547340. Этот подход завершается с использованием всех ядер полностью и быстрее чем один вход, несколько выходов в одной команде.
Ответ 2
Если ваш "двухъядерный" имеет гиперпоточность, то, вероятно, 2-х ядерные ядра будут правильными. Там вряд ли будет выигрыш, выходящий за пределы количества виртуальных ядер (включая гиперпоточность), но, возможно, из-за внутренних проблем в FFmpeg это может быть правдой.
Ответ 3
Я тщательно экспериментировал с потоками 0, 6, 12, 24, и это не влияет на частоту кадров, общее время обработки или использование ЦП. Обратите внимание: моя система также имеет 12 физических ядер. Как правило, кажется, что вы хорошо работаете с вычислительной мощностью без указания тем, где мои 12 ядер в основном 98-99% используются в течение всего времени, наблюдая за верхним/системным монитором.
Мне жаль, что не было волшебной пули, но пока нет другого способа ускорить процесс, так как ffmpeg в настоящее время оптимизирован очень хорошо, на мой взгляд. Единственная альтернатива - просто получить больше вычислительной мощности или сделать распределенную обработку.
* Обратите внимание, что все мои тесты использовали ffmpeg version 3.3.1