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

Есть несколько способов получить "несжатый" 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-битного слова находятся два неиспользованных бита. Это тривиальное отличие, несомненно, потому что они приходят от конкурирующих компаний, http://blackmagicdesign.com/ и 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 не влияет на значения пикселей.

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

Существуют варианты анимации QuickTime с менее чем 24 битами на пиксель, но их лучше всего использовать для прогрессивно более простых стилей анимации. ffmpeg кажется, поддерживает только один из других форматов, определенных в спецификации, -pix_fmt rgb555be, что означает 15 bpp big-endian 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 - это то же самое, что и опция цветового пространства RGB24 в QuickTime Animation. Два кодека будут несколько отличаться по сжатию для данного файла, но обычно они будут близки.

  По сути, это то же самое, что и режим 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

Еще один интересный вариант в этом пространстве - собственный FFmpeg FFV1 кодек Это в основном используется в качестве архивного кодека, а не для воспроизведения или редактирования кодека, но, поскольку так много программного обеспечения основано на 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 дает то, что вы могли бы назвать "Без потерь MJPEG", но, как правило, мы не заинтересованы в том, чтобы вставлять много файлов неподвижных изображений в контейнер A/V для создания фильма. Мы хотим, чтобы здесь были широко признанные видеокодеки, а не семантическая хитрость.

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

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

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

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

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

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

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

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

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

Смотрите также мой аналогичный ответ на похожий вопрос: /questions/598777/ffmpeg-x264-nastrojki-kodirovaniya/598782#598782

В ответе Уоррена Янга много информации о различных форматах и ​​кодеках. Я думаю, что ответ был бы более полезным, если бы он был короче, поэтому я делаю новый ответ. Если вы работаете с программным обеспечением, которое не поддерживает 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 24 fps, поэтому он не будет синхронизироваться с аудио. (и значения битрейта (но не размера файла) тоже будут отключены. 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.

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