Как создать несжатый AVI из серии изображений PNG с использованием FFMPEG

Как я могу создать несжатый AVI из серии изображений PNG 1000 с использованием FFMPEG?

Я использовал эту команду для преобразования input.aviфайла в серию кадров PNG:

ffmpeg -y -i input.avi  -an -vcodec png  -s 1024x768 pic%d.png`

Теперь мне нужно знать, как сделать несжатое видео AVI из всех этих кадров PNG. Я попробовал это:

ffmpeg -i pic%d.png -y -f avi -b 1150 -s 1024x768 -r 29.97 -g 12 -qmin 3 -qmax 13 -ab 224 -ar 44100 -ac 2 test.avi

Но полученное видео теряет много качества по сравнению с оригинальным AVI.

Есть несколько способов получить «несжатый» AVI ffmpeg, но я подозреваю, что вы на самом деле имеете в виду «без потерь». Как вы увидите, оба термина имеют достаточно места для маневра в своих определениях.

Я собираюсь связать это обсуждение с 720p HD-версией Big Buck Bunny , так как это свободно доступное видео, с которым мы все можем протестировать и получить результаты, которые мы можем сравнить. Скорость необработанных данных для видео 1280 × 720p при 24 кадрах в секунду почти равна скорости вашей заявленной скорости 1024 × 768 при цели 29,97 кадров в секунду, поэтому мои результаты должны быть довольно хорошим ориентиром для скоростей передачи данных, которые вы можете ожидать на своих кадрах.

Автоматический список доступных опций

Следующая команда POSIX¹ дает вам список, который в основном соответствует тому, что мы обсуждаем ниже:

$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'

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

Теперь давайте обсудим эти варианты.

Полностью несжатый

Если ваше определение «несжатый» является формой видео в праве , прежде чем он обратился к фотонам цифрового дисплея, ближе всего я вижу в ffmpeg -codecsсписке -c:v r210, r10k, v410, v308, ayuvи v408. Все это по сути одно и то же, отличающееся только глубиной цвета , цветовым пространством и поддержкой альфа-канала .

• R210 и R10K имеют 4: 4: 4 RGB при 10 битах на компонент (бит / с), поэтому им обоим требуется около 708 Мбит / с для 720p в моем тестировании. (Это около ⅓ ТБ в час, друзья!)

  Оба эти кодека упаковывают 3 × 10-битные цветовые компоненты на пиксель в 32-битное значение для простоты манипулирования компьютерами, которым нравятся размеры степени 2. Единственная разница между этими кодеками заключается в том, на каком конце 32-битного слова находятся два неиспользуемых бита. Это тривиальное отличие, несомненно, потому что они приходят от конкурирующих компаний, Blackmagic Design и AJA Video Systems , соответственно.

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

• V410 - это просто версия YUV R210 / R10K; их скорости передачи данных идентичны. Этот кодек, тем не менее, может кодировать быстрее, потому что ffmpeg, скорее всего, будет ускоренный путь преобразования цветового пространства между цветовым пространством ваших входных кадров и этим цветовым пространством.

  Однако я не могу рекомендовать этот кодек, так как мне не удалось воспроизвести полученный файл с помощью любого программного обеспечения, которое я пробовал, даже с установленными кодеками AJA и Blackmagic.

• V308 - это 8-битный вариант V410, поэтомув моем тестированиион достиг 518 Мбит / с . Как и в случае с V410, мне не удалось воспроизвести эти файлы в обычном программном обеспечении видеоплеера.

• AYUV и V408 - это то же самое, что и V308, за исключением того, что они включают альфа-канал, независимо от того, нужен он или нет! Если ваше видео не использует прозрачность, это означает, что вы платите штраф за размер кодеков R210 / R10K 10 бит на канал выше, не получая преимущества более глубокого цветового пространства.

  У AYUV есть одно достоинство: это «родной» кодек в Windows Media, поэтому для его воспроизведения не требуется специального программного обеспечения.

  Предполагается, что V408 также является родным для QuickTime, но файл V408 не будет воспроизводиться в QuickTime 7 или 10 на моем Mac.

Итак, собираем все это вместе, если ваши PNG названы frame0001.pngи так далее:

$ ffmpeg -i frame%04d.png -c:v r10k output.mov
  ...or...                -c:v r210 output.mov
  ...or...                -c:v v410 output.mov
  ...or...                -c:v v408 output.mov
  ...or...                -c:v v308 output.mov
  ...or...                -c:v ayuv output.avi

Обратите внимание, что я указал AVI в случае с AYUV, так как это в значительной степени кодек только для Windows. Другие могут работать в QuickTime или AVI, в зависимости от того, какие кодеки установлены на вашем компьютере. Если один формат контейнера не работает, попробуйте другой.

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

Сжатый RGB, но и без потерь

Если, как я подозреваю, вы на самом деле имеете в виду «без потерь» вместо «несжатый», гораздо лучшим выбором, чем любой из вышеперечисленных, является Apple QuickTime Animation , через-c:v qtrle

Я знаю, что вы сказали, что хотите AVI, но дело в том, что вам, вероятно, придется установить кодек на машине Windows, чтобы прочитать любой из форматов файлов на основе AVI, упомянутых здесь, тогда как с QuickTime есть шанс, что видео Приложение по вашему выбору уже знает, как открыть файл анимации QuickTime. (Кодек AYUV выше - единственное исключение, о котором я знаю, но его скорость передачи данных ужасно высока, просто чтобы воспользоваться преимуществами AVI.)

ffmpegдобавит qtrleв AVI контейнер для вас, но результат может быть не очень совместимым. В моем тестировании QuickTime Player немного расскажет о таком файле, но потом его воспроизведет. Как ни странно, VLC не будет проигрывать его, хотя он частично основан на ffmpeg. Я бы придерживался контейнеров QT для этого кодека.

В кодеке QuickTime Animation используется тривиальная схема RLE , поэтому для простых анимаций он должен работать примерно так же, как показано ниже в Huffyuv. Чем больше цветов в каждом кадре, тем больше он будет приближаться к скорости передачи битов в полностью несжатых вариантах выше. В ходе тестирования с Big Buck Bunny, я смог ffmpegдать мне 165 Мбит / с файл в RGB 4: 4: 4 режима, с помощью -pix_fmt rgb24.

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

Реализация ffmpegQuickTime Animation также поддерживает -pix_fmt argb, что дает вам 4: 4: 4: 4 RGB, то есть имеет альфа-канал. В очень грубом виде это эквивалент QuickTime -c:v ayuv, упомянутый выше. Однако из-за сжатия без потерь он достигает только 214 Мбит / с , что меньше ⅓ скорости передачи данных AYUV с нулевой потерей качества или характеристик.

Существуют варианты QuickTime Animation с менее чем 24 битами на пиксель, но их лучше использовать для прогрессивно более простых стилей анимации. ffmpegпо-видимому, поддерживает только один из других форматов, определенных спецификацией -pix_fmt rgb555be, что означает 15-битный RGB с прямым порядком байтов. Это приемлемо для некоторых видео, и хорошо для большинства снимков экрана и простой анимации. Если вы можете принять прореживание цветового пространства, вам может понравиться скорость передачи данных 122 Мбит / с .

Собираем все это вместе:

$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24    output.mov
  ...or...                           -pix_fmt argb     output.mov
  ...or...                           -pix_fmt rgb555be output.mov

Эффективно без потерь: трюк YUV

Теперь, что касается RGB и 4: 4: 4 YUV , то, что эти кодировки очень легко обрабатываются компьютерами, но они игнорируют факт человеческого зрения, который заключается в том, что наши глаза более чувствительны к черно-белым различиям, чем к цветным различиям. ,

Поэтому системы хранения и доставки видео почти всегда используют меньше битов на пиксель для информации о цвете, чем для информации о яркости. Это называется подвыборкой цветности . Наиболее распространенными схемами являются 4: 2: 0 и 4: 2: 2.

Скорость передачи данных 4: 2: 0 YUV всего на 50% выше, чем для черно-белого (только Y) несжатого видео, и ½ скорости передачи данных 4: 4: 4 RGB или YUV.

4: 2: 2 является своего рода промежуточной точкой между 4: 2: 0 и 4: 4: 4. Это вдвое больше скорости передачи видео только по Y и скорости передачи данных 4: 4: 4.

Вы также иногда видите 4: 1: 1, как в старом стандарте камеры DV . 4: 1: 1 имеет такую ​​же несжатую скорость передачи данных, как 4: 2: 0, но информация о цвете организована по-другому.

Смысл всего этого в том, что если вы начинаете с H.264-файла 4: 2: 0, перекодируйте его в несжатый RGB формат 4: 4: 4, и вы абсолютно ничего не купите за 4: 2: 0 сжатого без потерь YUV. Это верно, даже если вы знаете, что ваш рабочий процесс имеет формат 4: 4: 4 RGB, поскольку это тривиальное преобразование; видеооборудование и программное обеспечение регулярно выполняют такие преобразования на лету.

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

Эффективно без потерь: выбор кодеков

После того, как вы откроете себя для кодеков YUV с цветовой прореживанием, ваши настройки тоже откроются. ffmpegимеет много эффективно кодеков без потерь .

Huffyuv

Наиболее широко совместимым вариантом является Huffyuv . Вы получаете это через -c:v huffyuv.

Оригинальный кодек Windows Huffyuv поддерживает только два формата пикселей: RGB24 и YUV 4: 2: 2. (На самом деле, он поддерживает два варианта YUV 4: 2: 2, отличающиеся только порядком байтов на диске.)

Более старые версии кодека FFmpeg Huffyuv не включали поддержку RGB24, поэтому, если вы попробуете это, и FFmpeg сообщит вам, что собирается использовать yuv422pформат пикселей, вам необходимо выполнить обновление.

FFmpeg также имеет вариант кодека Huffyuv под названием FFVHuff, который поддерживает YUV 4: 2: 0. Этот вариант несовместим с кодеком Windows DirectShow Huffyuv, но он должен открываться в любом программном обеспечении libavcodec, например, VLC.

• RGB24 - RGB 4: 4: 4 - это то же самое, что и опция цветового пространства QuickTime Animation RGB24. Два кодека будут несколько отличаться по сжатию для данного файла, но обычно они будут близки.

  По сути, это то же самое, что и режим YUV 4: 4: 4, используемый в опции V308 выше. Разница в цветовом пространстве не имеет практического значения, поскольку преобразование цветового пространства легко осуществить в реальном времени.

  Благодаря сжатию без потерь Хаффюва, я смог получить тестовое видео со сжатием до 251 Мбит / с в режиме RGB24, с качеством изображения, идентичным тому, что вы получаете от V308 или AYUV. Если AVI является для вас абсолютной необходимостью , установка кодека Huffyuv, вероятно, менее болезненна, чем оплата 3-кратной стоимости передачи данных AYUV.

• YUV 4: 2: 2 - этот режим гораздо более практичен для видео, чем RGB24, поэтому, несомненно, ffmpegразработчики решили сначала его реализовать. Как и следовало ожидать от теоретического сокращения, рассмотренного выше, мой тестовый файл был закодирован до 173 Мбит / с . Это почти точно ⅔, если принять во внимание тот факт, что звуковая дорожка не изменилась между этими двумя тестами.

• YUV 4: 2: 0 - эта опция уничтожает информацию о цвете больше, чем 4: 2: 2, снижая скорость передачи данных до 133 Мбит / с в моем тестировании.

Собираем все это вместе:

$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24   output.avi
  ...or...                             -pix_fmt yuv422p output.avi
  ...or...                -c:v ffvhuff -pix_fmt yuv420p output.avi

Хотя ffvhuffкодек по умолчанию составляет 4: 2: 0, когда я пишу это, и действительно поддерживает только этот формат пикселей в используемой версии выпуска, это меняется , поэтому вы должны включить флаг в случае изменения этого значения по умолчанию.

Ut Video

Более поздний вариант в том же духе, что и Huffyuv и FFVHuff, - это Ut Video . Как и Huffyuv, существует видеокодек Windows, что означает, что любая программа Windows, которая может воспроизводить фильм, может воспроизводить видео с использованием этого кодека с установленным кодеком. В отличие от Huffyuv, есть также видеокодек Mac, поэтому вы не ограничены программным обеспечением на основе FFmpeg или libavcodecдля чтения этих файлов на Mac.

Этот кодек очень гибок с точки зрения цветовых пространств, поэтому я просто приведу несколько примеров общих цветовых пространств:

• 4: 4: 4 RGB через -f avi -c:v utvideo -pix_fmt rgb24дает 178 Мбит / с на выходе

• 4: 4: 4 YUV через -f avi -c:v utvideo -pix_fmt yuv444pдает 153 Мбит / с на выходе

• 4: 2: 2 YUV через -f avi -c:v utvideo -pix_fmt yuv422pдает выходной 123 Мбит / с

• 4: 2: 0 YUV через -f avi -c:v utvideo -pix_fmt yuv420pдает выход 100 Мбит / с

Я подозреваю, что 4: 4: 4 YUV в этом тесте работает лучше, чем 4: 4: 4 RGB, несмотря на то, что эти два показателя технически эквивалентны, поскольку исходное видео имеет формат 4: 2: 0 YUV, поэтому расположение данных в формате YUV обеспечивает лучшее сжатие без потерь путем группировки частично избыточных каналов U и V вместе в файле.

FFV1

Еще один интересный вариант в этом пространстве - собственный FFV1кодек FFmpeg . Это в основном используется в качестве архивного кодека, а не кодека воспроизведения или редактирования, но, поскольку так много программного обеспечения либо основано на libavcodecбиблиотеке, лежащей в основе FFmpeg, либо может быть привязано к таким libavcodecинструментам, как ffdshow, это может быть полезно в любом случае.

По умолчанию, ffmpegпри использовании гибкого кодека, такого как FFV1 , будет сохранено цветовое пространство ваших входных файлов, поэтому, если вы подадите ему один из официальных файлов Big Buck Bunny MP4, использующих 4: 2: 0 YUV, это то, что вы получите если вы не дадите -pix_fmtфлаг ffmpeg. Это приводит к выходному файлу 63 Мбит / с .

Если вы заставите FFV1 использовать цветовое пространство 4: 4: 4 YUV с -pix_fmt yuv444p, размер файла увеличится только до 86 Мбит / с , но в этом случае он ничего не покупает, так как мы кодируем из оригинала 4: 2: 0 , Тем не менее, если вы подаете в наборе в формате PNG , а не, как и в исходном вопросе, выходной файл может использовать bgraили bgr0цветовое пространство, которые являются только перестановкой argbи rgb24цветовых пространств , воспитывающихся выше.

Без потерь H.264

Еще одна интересная альтернатива - Lossless H.264 . На момент написания статьи это в основном относится только к x264 , но те, кто использует FFmpeg на стороне кодирования, скорее всего, будут использовать другое программное обеспечение, которое также включает в себя libx264на стороне декодирования , например, VLC.

Самый простой способ получить такой файл:

$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4

-qp 0Флаг является ключом: более высокие значения дают сжатие с потерями. (Вы также можете дать, -crf 0чтобы получить тот же эффект.)

Как и в случае FFV1, ffmpegмы попытаемся угадать наилучшее выходное цветовое пространство, учитывая входное цветовое пространство, поэтому для сравнения с результатами, приведенными выше, я провел несколько проходов кодирования исходного файла Big Buck Bunny с различными цветовыми пространствами:

• yuv444p : это то, что ffmpegвыбирается, когда вы предоставляете ему поток PNG RGB, как в исходном вопросе, и в результате получается наш файл 44 Мбит / с с нашим тестовым файлом.

• yuv422p : Это похоже на цветовое пространство по умолчанию для Huffyuv, но в этом случае мы получаем файл 34 Мбит / с , что довольно экономно!

• yuv420p : Это значение по умолчанию для официальных MP4 Big Buck Bunny, с которыми я тестирую, и в результате получается файл со скоростью 29 Мбит / с .

Остерегайтесь того, что вы торгуете большой совместимостью, чтобы получить файлы такого маленького размера. Вот почему я даже не пытался вставить это в контейнер AVI или MOV. Он настолько тесно связан с x264, что вы могли бы вместо этого использовать его стандартный тип контейнера (MP4). Вы также можете использовать что-то вроде Matroska для этого.

Вы можете обменять часть этой скорости на более короткое время кодирования, добавив -preset ultrafast. Это увеличило скорость моего тестового файла до 44 Мбит / с в режиме YUV 4: 2: 2, но закодировалось намного быстрее, как и было обещано. Документы утверждают, что -preset veryslowэто также стоит, но это привело к гораздо более длительному времени кодирования при сохранении лишь небольшого места; Я не могу рекомендовать это.

другие

ffmpegтакже поддерживает режим только декодирования для Lagarith и режим только кодирования для Lossless JPEG . Эти два кодека на самом деле чем-то похожи, и должны давать файлы немного меньшего размера, чем Huffyuv, с тем же качеством. Если ffmpegразработчики когда-либо добавят кодировку Lagarith, это будет сильной альтернативой Huffyuv. Однако я не могу рекомендовать Lossless JPEG, поскольку он не имеет широкой поддержки декодирования.

Perceptually Lossless: или, возможно, вам удастся избежать потери

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

• Apple ProRes :-c:v proresили-c:v prores_ks- ProRes - это кодек на основе профиля. Это означает, что существует несколько вариантов, каждый из которых имеет разное соотношение качества и пространства:

  • ProRes 4444 кодирует наше тестовое видео, используя только 114 Мбит / с , но качество VFX . В настоящее времяprores*в FFmpegесть три разныхкодека, ноprores_ksподдерживаетсятолькоProRes 4444, как я пишу, через-profile:v 4444опцию.

    Если вас интересует, почему вы хотите использовать ProRes 4444 вместо Lossless H.264, это сводится к совместимости, скорости декодирования, предсказуемости и альфа-каналу.

  • ProRes 422 экономит еще больше места, ему требуется всего 84 Мбит / с, чтобы получить результат, который вы можете узнать из ProRes 4444 только с помощью пиксельного подглядывания. Если вам не нужен альфа-канал, предлагаемый ProRes 4444, вероятно, нет причин настаивать на ProRes 4444.

    ProRes 422 является более близким конкурентом к опции Lossless H.264, описанной выше, поскольку ни один из них не поддерживает альфа-канал. Вы захотите допустить более высокую скорость передачи данных ProRes, если вам нужна совместимость с видеоприложениями Apple pro, более низкая загрузка ЦП для кодирования и декодирования или предсказуемые скорости передачи данных. Последнее важно, например, для аппаратных кодеров. С другой стороны, если вы можете справиться с проблемами совместимости Lossless H.264, вы получите возможность использовать цветовое пространство 4: 2: 0, которое не доступно ни в одном профиле ProRes.

    Все три кодера ProRes в FFmpeg поддерживают профиль ProRes 422, поэтому самый простой вариант - использовать функцию автоматического профиля -c:v prores, а не -c:v prores_ks -profile hqзависеть от нее, prores_ksчтобы делать правильные вещи.

  Есть еще более экономные профили ProRes, но они предназначены для SD-видео или в качестве прокси для файлов с полным разрешением.

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

• DNxHD от Avid - это кодек, аналогичный ProRes, но он не привязан к миру видео Apple Pro. Avid предлагает свободно загружаемые кодеки для Windows и Macintosh, а FFmpeg теперь поддерживает их через-c:v dnxhd.

  Поскольку DNxHD - это кодек на основе профиля, такой как ProRes, вы выбираете профиль из предопределенного набора , и он сообщает кодеку, какой размер кадра, частоту кадров и битрейт использовать. Для тестового файла Big Buck Bunny -b:v 60Mпрофиль является наиболее подходящим. Неудивительно, что результирующий файл составляет около 59 Мбит / с .

• MJPEG с низкими потерями :-vcodec mjpeg -qscale:v 1- Это гораздо чаще, чем JPEG без потерь. Фактически, это был довольно распространенный кодек для редактирования видео, и он до сих пор часто используется такими вещами, как сетевые потоковые видеокамеры. Вся эта история означает, что легко найти программное обеспечение, которое поддерживает его.

  Ожидайте довольно широкую изменчивость в скоростях передачи данных от этого кодека. Тест, который я только что здесь сделал, дал мне 25 Мбит / с для видео 720p. Это достаточно высокое сжатие, чтобы я нервничал по поводу потери, но это выглядело довольно хорошо для меня. Исходя из одной скорости передачи данных, я бы сказал, что она, вероятно, на уровне качества - 12 Мбит / с MPEG-2 или 6 Мбит / с H.264.

Собираем все это вместе:

$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
  ...or...                -c:v prores_ks -profile:v hq   output.mov
  ...or...                -c:v prores                    output.mov
  ...or...                -c:v dnxhd -b:v 60M            output.mov
  ...or...                -c:v mjpeg -qscale:v 1         output.avi

Суть этих методов в том, что если вы не делаете что-то очень сложное, «достаточно хорошо» действительно достаточно хорошо.

Сноски и отступления

1. Команда должна работать, как указано, в Linux, macOS, BSD и Unix. Если вы работаете в Windows, вы можете получить командную строку POSIX через Cygwin или WSL .

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

   • Второе grepпредназначено для фильтрации неподходящих кодеров, bmpкоторые не являются «видео» кодеками, несмотря на то, что они помечены Vв этом списке. Хотя технически вы, вероятно, могли бы поместить многие из них в контейнер, такой как AVI, MP4 или MKV, чтобы получить однофайловое видео, этот файл, вероятно, не будет читаться ничем, кроме программы, основанной на ffmpegили libavcodec.

     Есть несколько исключений из этого, например, это -f avi -c:v ljpegдает то, что вы могли бы назвать «Lossless MJPEG», но, как правило, нам не интересно вставлять много файлов неподвижных изображений в A / V-контейнер здесь, чтобы сделать фильм. Мы хотим, чтобы здесь были широко признанные видеокодеки, а не семантическая хитрость.

   • В настоящее время команда не может отфильтровать некоторые неподходящие кодеры, такие как GIF, поскольку в настоящее время они не описаны в ffmpeg -codecsвыходных данных bitmapили в imageформатах файлов.

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

   • Некоторые из вариантов, показанных устарели или никогда действительно получил много тяги, таких как flashsv, diracи snow, таким образом , что не стоит обсуждать их выше.

   • Некоторые параметры в этом списке предназначены только для использования в конвейерах между ffmpegэкземплярами или между ffmpegдругой программой, такой как rawvideoи wrapped_avframe, и поэтому не подходят для наших целей здесь.

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

Так что я закончил тем, что делал свой собственный ответ слишком долго.
TL; DR summary: для сохранения последовательности изображений без потерь, используйте libx264или libx264rgbс -preset ultrafast -qp 0. Это почти так же быстро, как ffvhuff, с гораздо меньшим битрейтом и быстрее декодируется. huffyuvгораздо более широко поддерживается за пределами ffmpeg, но не поддерживает столько форматов пикселей, как ffvhuff. Так что это еще одна причина для использования h.264, предполагая, что ваши другие инструменты могут обрабатывать High 4:4:4 Predictiveпрофиль h.264, который x264 использует в режиме без потерь. x264 может делать внутри-только, если требуется быстрый произвольный доступ к произвольным кадрам.

Остерегайтесь ошибки ffmpeg, влияющей на libx264rgb при чтении из каталога изображений. (и кто знает, что в других случаях.) Проверьте на отсутствие потерь в вашей настройке перед использованием. (легко с ffmpeg -i in -pix_fmt rgb24 -f framemd5источником и без потерь сжат))

редактировать: utvideoкодирует и декодирует довольно быстро, и это гораздо более простой кодек, чем h.264. Это в основном современный huffyuv, с поддержкой более полезных цветовых пространств. Если у вас возникли проблемы с h.264, попробуйте utvideo next для поиска временных файлов.

edit2: PNG как кодек RGB, кажется, преуспевает, по крайней мере на трейлере Sintel.

Смотрите также мой аналогичный ответ на похожий вопрос: https://superuser.com/a/860335/20798

В ответе Уоррена Янга много информации о различных форматах и ​​кодеках. Я думаю, что ответ был бы более полезным, если бы он был короче, поэтому я делаю новый ответ. Если вы работаете с программным обеспечением, которое не поддерживает x264 или ffvhuff без потерь, то некоторая информация, вероятно, все еще полезна.

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

http://en.wikipedia.org/wiki/Chroma_subsampling

В идеале, избегайте нескольких преобразований цветового пространства. Ошибки округления могут накапливаться. Если вы собираетесь работать с вашим видео с фильтрами, работающими в цветовом пространстве RGB, то сохранение его в RGB имеет смысл, если только большие битрейты не являются проблемой. Возможно, вы в конечном итоге создадите yuv 4:2:0видео, но сохранение дополнительного разрешения цветности потенциально полезно в зависимости от того, какие фильтры вы собираетесь применять.

В любом случае, без потерь x264 и ffvhuff как поддержка RGB и YUV 4:4:4, 4:2:2и 4:2:0. Я бы предложил x264, так как он быстро декодируется. Если вы пытаетесь воспроизводить видео RGB HD в режиме реального времени, попробуйте opengl вместо xv, поскольку xv в моей системе принимает только ввод yuv. mplayer занимал дополнительное процессорное время для преобразования цветового пространства.

Источник для следующих тестов кодировщика: https://media.xiph.org/ . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz Они забыли сжать файлы y4m для трейлера sintel, поэтому архив png на самом деле намного меньше.

ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac \
-c:a copy -c:v libx264rgb -preset ultrafast -qp 0 \
frompng.sintel.264rgb.mkv

например

peter@tesla:/mnt/GP1TB/p/encoder-sample/sintel$ time ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 frompng.sintel.264rgb.mkv
ffmpeg version N-67983-g2b358b4 Copyright (c) 2000-2015 the FFmpeg developers
  built on Jan 10 2015 05:32:37 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000
  libavutil      54. 16.100 / 54. 16.100
  libavcodec     56. 20.100 / 56. 20.100
  libavformat    56. 18.100 / 56. 18.100
  libavdevice    56.  3.100 / 56.  3.100
  libavfilter     5.  7.100 /  5.  7.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, image2, from '1080/sintel_trailer_2k_%4d.png':
  Duration: 00:00:50.12, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 72:72 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
Input #1, flac, from 'sintel_trailer-audio.flac':
  Duration: 00:00:52.00, start: 0.000000, bitrate: 721 kb/s
    Stream #1:0: Audio: flac, 48000 Hz, stereo, s16
File 'frompng.sintel.264rgb.mkv' already exists. Overwrite ? [y/N] y
No pixel format specified, rgb24 for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264rgb @ 0x2770760] using SAR=1/1
[libx264rgb @ 0x2770760] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264rgb @ 0x2770760] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit
[libx264rgb @ 0x2770760] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0
Output #0, matroska, to 'frompng.sintel.264rgb.mkv':
  Metadata:
    encoder         : Lavf56.18.100
    Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1920x1080 [SAR 72:72 DAR 16:9], q=-1--1, 25 fps, 1k tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.20.100 libx264rgb
    Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo (16 bit)
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> h264 (libx264rgb))
  Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 1253 fps= 18 q=-1.0 Lsize=  834790kB time=00:00:51.96 bitrate=131592.5kbits/s
video:830198kB audio:4575kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002025%
[libx264rgb @ 0x2770760] frame I:6     Avg QP: 0.00  size:612470
[libx264rgb @ 0x2770760] frame P:1247  Avg QP: 0.00  size:678787
[libx264rgb @ 0x2770760] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264rgb @ 0x2770760] mb P  I16..4: 50.3%  0.0%  0.0%  P16..4: 12.0%  0.0%  0.0%  0.0%  0.0%    skip:37.6%
[libx264rgb @ 0x2770760] coded y,u,v intra: 71.1% 68.2% 70.0% inter: 22.8% 22.8% 23.2%
[libx264rgb @ 0x2770760] i16 v,h,dc,p: 50% 48%  1%  1%
[libx264rgb @ 0x2770760] kb/s:135693.94

Обратите внимание, что я забыл указать -r 24fps, поэтому он не будет синхронизироваться с аудио. (и значения битрейта (но не размера файла) тоже будут отключены. ffmpeg по умолчанию 25fps). Процессор в этой машине - Core-Duo 1-го поколения (Conroe) 2,4 ГГц (E6600).

полученные результаты:

4.5M    sintel_trailer-audio.flac  # this is muxed in to every mkv
948M    1080  # the directory of PNGs
940M    /var/tmp/dl/sintel_trailer-1080-png.tar.gz
7434M   sintel.y4m  # yuv444, uncompressed.  mplayer gets the colors wrong?
2342M   qtrle.mkv   # encode went at 16fps, so qtrle is slower and worse filesize
2105M   sintel.huff.mkv  # ffvhuff with default options, rgb pix fmt
1228M    sintel.utvideo.mkv  # muxed without audio, I should update the others this way
946M    png-copy.mkv  # -codec copy makes a MPNG stream.  Use -codec png for non-png sources, but it won't make PNGs as small.  Decodes very fast
824M    lossy.prores_ks.mov # yuv444p10le extremely slow to encode (2.3fps), and worse bitrate.
816M    frompng.sintel.264rgb.mkv
735M    sintel.x264rgb.medium.nocabac.mkv  # encode went at 3.3 fps instead of 18.  Better gain than for live-action, though
626M    sintel_trailer.rgb.lossless.veryslow.mkv # 1.1fps.  With CABAC, 16 ref frames, etc. etc.
512M    lossy.prores.mov # yuv422p10le, 12fps
341M    sintel.yuv420.x264.lossless.mkv
21M     lossy.rgb.crf26.preset=medium.mkv
13M     lossy.yuv420.crf26.preset=medium.mkv  # remember this is WITH 4.5MB audio

Обратите внимание, что mediainfoне знает о RGB h.264, он по-прежнему говорит, что файлы YUV.

Проверьте, что это действительно было без потерь:

ffmpeg -i 1080/sintel_trailer_2k_%4d.png -f framemd5 png.framemd5
ffmpeg -i fromhuff.sintel.264rgb.mkv -an -sn -pix_fmt rgb24  -f framemd5 x264rgb.framemd5
diff -s *.framemd5
Files png.framemd5 and x264rgb.framemd5 are identical

Таким образом, вы можете восстановить исходные PNG-данные таким образом, то есть вы можете создавать PNG-файлы с идентичными данными изображения.

Обратите внимание -pix_fmt rgb24на тест x264. Декодер h.264 ffmpeg выводит вывод gbrp (плоский, не упакованный), поэтому биты одинаковые, но в другом порядке. «Контейнер» framemd5 не накладывает никаких ограничений на формат, но вы получите тот же md5, только если биты расположены одинаково. Я просто посмотрел на то, что ffmpeg сказал, что он использует для пикселя fmt, когда я подал ему PNG, а затем использовал это в качестве аргумента -pix_fmtдля декодирования. Кстати, именно поэтому vlc не будет воспроизводить файлы RGB h.264 (до следующего выпуска или текущих ночных сборок): он не поддерживает пиксельный формат gbrp.

Для использования yuv libx264, нет libx264rgb. Вам не нужно устанавливать версию RGB x264, реальная библиотека поддерживает оба варианта. Это просто ffmpeg, который реализовал его как два кодировщика с разными именами. Я думаю, что если бы они этого не сделали, стандартным поведением было бы оставить вход rgb как rgb и работать очень медленно, производя намного более высокий битрейт для того же качества. (вы все еще иногда приходится использовать , -pix_fmt yuv420pесли вы хотите 420вместо 444h.264 вывода.

Если вы не делаете файлы для длительного хранения, всегда используйте -preset ultrafastдля x264 без потерь. Больше опорных кадров и поиск по движению едва ли имеют значение для без потерь, для не анимированного материала с любым шумом. CABAC требует огромного количества ресурсов процессора при битрейтах без потерь даже для декодирования. Используйте только для архивных целей, а не для царапин файлов. (сверхбыстрый отключает CABAC). CABAC дает от 10 до 15% экономии битрейта.

Если вам нужно, чтобы каждый кадр был ключевым, установите -keyint 1. Тогда программа для редактирования видео, которая хочет вырезать только ключевые кадры или w / e, не будет ограничивать вас.

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

ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv

Если вам действительно нужны выходные данные в файлах изображений, которые вы можете изменить с помощью инструментов для создания неподвижных изображений, то обязательно декодируйте в png. Вы не потеряете ничего больше, чем, возможно, наименее значимое из 8 битов для каждого из значений Y, Cb и Cr для каждого пикселя.

x264 действительно очень хорош в этом, потому что есть много черных рамок с небольшим количеством текста, постепенным появлением и постепенным исчезновением, а также совершенным сходством между большими областями многих кадров, которыми он даже может воспользоваться -preset ultrafast. В прямом эфире я все еще вижу x264 на половине размера файла ffvhuff (yuv420).

Для всех, кто интересуется: RGB-кодирование без потерь с большим временем процессора (x264 core 144 r2525):

[libx264rgb @ 0x35b97a0] frame I:27    Avg QP: 0.00  size:604367
[libx264rgb @ 0x35b97a0] frame P:1226  Avg QP: 0.00  size:517512
[libx264rgb @ 0x35b97a0] mb I  I16..4..PCM: 46.3% 38.1% 15.7%  0.0%
[libx264rgb @ 0x35b97a0] mb P  I16..4..PCM: 24.3%  5.4%  4.5%  0.0%  P16..4: 10.5%  3.3%  5.7%  0.0%  0.0%    skip:46.3%
[libx264rgb @ 0x35b97a0] 8x8 transform intra:17.3% inter:46.1%
[libx264rgb @ 0x35b97a0] coded y,u,v intra: 81.6% 77.5% 80.0% inter: 28.0% 27.7% 28.1%
[libx264rgb @ 0x35b97a0] i16 v,h,dc,p: 35% 64%  1%  0%
[libx264rgb @ 0x35b97a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 49% 13%  2%  1%  1%  1%  1%  1%
[libx264rgb @ 0x35b97a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 37%  5%  5%  6%  5%  5%  4%  3%
[libx264rgb @ 0x35b97a0] Weighted P-Frames: Y:41.1% UV:40.7%
[libx264rgb @ 0x35b97a0] ref P L0: 74.5%  4.2%  9.1%  4.1%  2.1%  1.7%  1.2%  0.8%  0.6%  0.5%  0.3%  0.2%  0.2%  0.2%  0.2%  0.1%
[libx264rgb @ 0x35b97a0] kb/s:99721.66

Обратите внимание на действительно большую долю взвешенных p-кадров, а также действительно большую долю пропущенных макроблоков. Каждый переход сцены - это затухание, а не срез, и x264 использует преимущество, если вы даете ему время ЦП, чтобы выяснить, как это сделать.

дополнительные примечания (кодеки с потерями для редактирования):

Для очистки вперед / назад через клипы обычно предпочтительны интра-кодеки (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). Я бы предположил, что обычный AVC с короткими GOP (от 1/2 до 1 секунды) тоже будет достаточно хорошо чистить, если программное обеспечение знает, что оно делает (декодировать ближайший I кадр при быстрой очистке, декодировать в GOP, чтобы добраться до промежуточный кадр, если вы увеличиваете достаточно на временной шкале, чтобы это было необходимо).

Я опубликовал некоторые негативные замечания по этому поводу и https://video.stackexchange.com/ о pro-res, например, «какой смысл, если это медленнее и хуже сжатие, чем кодек без потерь», но у него есть некоторые интересные особенности. Apple утверждает, что она может декодировать с половинным разрешением, используя всего 1/3 процессорного времени декодирования с полным разрешением.

Прошлая реализация ffmpeg, вероятно, не так оптимизирована по скорости, как у Apple, и поэтому мое тестирование с использованием ffmpeg выглядело медленно. Это, вероятно, не стоит использовать, если у вас есть рабочий процесс Свободного программного обеспечения с инструментами, основанными на ffmpeg, но, возможно, стоит попробовать, если вы используете коммерческое программное обеспечение.

Я не много занимаюсь редактированием видео, в основном просто кодированием, поэтому у меня нет четкого представления о том, какие тесты подойдут для таких кодеков, как prores. Я предполагаю, что, возможно, mjpeg будет хорошей быстрой альтернативой, если short-GOP x264 не работает хорошо. В дистрибутивах Linux есть реализации jpeg с ускорением asm, и это довольно простой кодек. Вы можете увеличивать или уменьшать качество по мере необходимости, чтобы сравнить качество и размер файла + скорость кодирования / декодирования. Он древний, но если вам нужен действительно быстрый кодек только для внутреннего использования, он может превзойти x264.

Для x264 я бы попробовал что-то вроде x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (Intra-only, без каких-либо других вещей, которые --avcintra-classустанавливаются.) Примечание superfast(без CABAC) или fasterнет ultrafast, вероятно, лучше всего подходит для операций с потерями. Я думаю, что ультрабыстрый теряет много качества, не будучи намного быстрее. Чем ниже качество (выше crf), которое вы используете, тем больше стоит потратить немного больше процессорного времени на поиск лучшего кодирования. Многое из этого, вероятно, не относится к GOP size = 1, хотя.

При размере GOP> 1, если вы добавляете так много битов в коде, что лучшее межкадровое предсказание не спасет много битов при кодировании остатков (потому что шум / зернистость / едва различимые изменения между кадрами сохраняются очень точно), тогда просто супербыстрый, наверное, хорошо. Иначе, с --keyint=30чем-то, наверное, --preset veryfast --crf 12было бы интересно.

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

Я думаю, что ffmpeg действительно поддерживает преобразование в несжатое видео.
Я использовал ffmpeg -i input.mp4 -vcodec rawvideo out.avi, и в результате .avi был примерно подходящего размера файла. Проигрыватель Windows Media, похоже, не мог воспроизвести его правильно, но он мог быть прочитан VirtualDub, и я не увидел каких-либо потерь в качестве изображения.