Опция подсчета потоков в FFmpeg для быстрого преобразования в h264? - PullRequest
Новая
       16

Опция подсчета потоков в FFmpeg для быстрого преобразования в h264?

25 голосов
/ 11 сентября 2011

Мне нужно увеличить скорость при преобразовании видео с помощью FFmpeg в h264

  • Любой формат ввода исходных видео
  • Машина пользователяможет иметь любое количество ядер
  • Энергопотребление и потребление памяти не являются проблемой

Конечно, есть множество вариантов, которые можно настроить, ноЭтот вопрос, в частности, касается выбора лучшего варианта -thread <count>.Я пытаюсь найти идеальное число потоков как функцию

  • нет.ядер
  • входной формат видео
  • h264-дружественные значения, может быть?
  • что-нибудь еще пропущено выше?

Я знаю значение по умолчанию -thread 0 следует принципу «один поток на ядро», который должен быть оптимальным.Но я не уверен, оптимизировано ли это время или пространство.Кроме того, в некоторых тестовых случаях я видел, как большее количество потоков (скажем, 4 потока на моей двухъядерной тестовой машине) завершается быстрее, чем по умолчанию.

Любое другое направление, скажем, настройки параметров в зависимости от потоков, которые стоит продолжить?

Ответы [ 3 ]

14 голосов
/ 07 февраля 2013

Я обнаружил, что threads плохо справляется с использованием всех ядер, гиперпотоки вообще не используются. Одно из решений, которое я мог бы предложить, - это запускать 3-4 процесса ffmpeg параллельно, см .: https://superuser.com/questions/538164/how-many-instances-of-ffmpeg-commands-can-i-run-in-parallel/547340#547340 Этот подход полностью использует все ядра и работает быстрее, чем один вход, несколько выходов в одной команде опция.

1 голос
/ 26 июля 2017

Я тщательно экспериментировал с потоками 0, 6, 12, 24, и это не влияет на частоту кадров, общее время обработки или загрузку ЦП.Обратите внимание, что моя система также имеет 12 физических ядер.В целом, кажется, что это хорошо справляется с использованием вашей вычислительной мощности без указания потоков, в которых мои 12 ядер в основном используются на 98-99% в течение продолжительного времени при просмотре системного монитора.

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

* Обратите внимание, что все мои тесты использовали ffmpeg версии 3.3.1

1 голос
/ 18 сентября 2011

Если ваш «двухъядерный» имеет гиперпоточность, то 2x ядер, вероятно, будут правильными. Маловероятно, что выигрыш будет превышать количество виртуальных ядер (включая гиперпоточность), но, возможно, из-за внутренних проблем в FFmpeg это может быть правдой.

...