Есть несколько способов получить «несжатый» 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 не влияет на значения пикселей.
Реализация ffmpeg
QuickTime 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
Суть этих методов в том, что если вы не делаете что-то очень сложное, «достаточно хорошо» действительно достаточно хорошо.
Сноски и отступления
Команда должна работать, как указано, в Linux, macOS, BSD и Unix. Если вы работаете в Windows, вы можете получить командную строку POSIX через Cygwin или WSL .
Есть несколько причин, по которым список, созданный этой командой, не полностью соответствует набору кодеков, которые я выбрал для обсуждения выше:
Второе 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
фильтр в приведенной выше команде.
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov
.