2012-07-20 5 views
3

Я использую ffmpeg для преобразования набора изображений (bmps) со звуковой дорожкой в ​​готовое к Интернету видео. Целевые форматы - h.264 mp4, webm и flv. Это очень большой экземпляр Windows Azure (8 proc), используя предварительно построенные статические сборки zeranoe (http://ffmpeg.zeranoe.com/builds/).ffmpeg: требуется скорость

Предположим, я готов пожертвовать качеством и размером для сырой скорости. Какие параметры для каждого формата дадут самый быстрый результат?

Моя команда «базовый» выглядит следующим образом (поменять расширение для других форматов):

ffmpeg -y -i frames%5d.bmp -i audio.mp3 -r 23.97 out.mp4 

я могу изменить входы в другие форматы, если это необходимо (JPG изображения, AAC аудио и т.д.).

+0

Это более общий FFMPEG вопрос, чем Лазурный вопрос. Один намек, однако, используйте 32-битный исполняемый файл ffmpeg. У меня возникли проблемы с 64-битной версией, и выяснилось, что 32-разрядный работает очень стабильно и стабильно. – astaykov

+0

Вы смотрели Media Services? Это не даст вам сырой пропускной способности по одному запросу, но позволит довольно крупномасштабную работу. – BrentDaCodeMonkey

+0

@bdcm Я создаю пользовательское видео для каждого пользователя. Мне нужны индивидуальные запросы, чтобы быть хеллой быстро – roufamatic

ответ

4

Основной «ручкой» вы изменяете баланс скорости/скорости кодирования для любого формата - bitrate. При тестировании только сейчас видео, которое занимает 97 секунд для кодирования с настройками по умолчанию, битрейт ~ 900 тыс., Заняло меньше половины, чем с битрейтом, набранным до 100 тыс. Выходное видео было намного меньше, а качество было заметно хуже.

В вашем случае, исходя из изображений, вы, вероятно, можете получить крупное ускорение отключались оценки движения, как указано в FFmpeg's encoding tips:

Если ваш компьютер не достаточно быстро, вы можете ускорить сжатие в за счет степени сжатия. Вы можете использовать '-me ноль' для ускорения оценки движения и '-g 0', чтобы полностью отключить оценку движения (у вас есть только I-кадры, что означает, что он примерно такой же, как JPEG-сжатие). [Следует отметить, что более поздние версии FFmpeg использовать -me_method вместо -me.]

В тестировании, то 97-вторых кодирования закончен в секунд -g 0. Было гораздо меньше сжатия, 63% от исходного размера и 25% с настройками по умолчанию, но качество остается хорошим, в отличие от кодировок с низким битрейтом.

Вот полные результаты моего быстрого тестирования, время в режиме реального времени используется для кодирования:
Baseline, 27М MOV в MP4, битрейт ~ 900K: 97s
с -me_method zero: 84S
с -flags2 fast: 84S
с -b 500k: 75S
с -b 100k: 43s
с -g 0: 20s

с -flags2 fast и -b 100k и -g 0: 12s (выход выглядит ужасно)

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

1

Какое разрешение этих изображений? Используя максимально возможное разрешение, вы получите лучшую производительность. Также используйте опцию -threads в ffmpeg для оптимального использования 8 ядер.

+0

Я не могу управлять разрешением (760x442). Ffmpeg добавляет в -threads 0 по умолчанию, заставляя его использовать 12 потоков в 8-процессорном поле. Я фактически сохранил вторую часть времени рендеринга, используя -threads 8. Это начало! – roufamatic