Есть несколько способов получить "несжатый" 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 в моем тестировании. (Это о & frac13; ТБ в час, друзья!)
Оба эти кодека упаковывают 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 , поэтому для простых анимаций он должен работать примерно так же, как показано ниже. Чем больше цветов в каждом кадре, тем больше он будет приближаться к скорости передачи битов в полностью несжатых вариантах выше. В моем тестировании с 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 Мбит / с , что меньше & frac13; скорость передачи данных AYUV с нулевой потерей качества или функций.
Существуют варианты анимации QuickTime с менее чем 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 & & frac23; скорость передачи данных 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 решили его реализовать в первую очередь. Как и следовало ожидать от теоретического & frac23; сокращение, рассмотренное выше, мой тестовый файл, закодированный до 173 Мбит / с. Это почти точно & frac23 ;, если принять во внимание тот факт, что звуковая дорожка не изменилась между этими двумя тестами.
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.
Этот кодек очень гибок с точки зрения цветовых пространств, поэтому я просто приведу несколько примеров общих цветовых пространств:
RGB 4:4:4 через -f avi -c:v utvideo -pix_fmt rgb24 выдает 178 Мбит / с на выходе
YUV 4:4:4 через -f avi -c:v utvideo -pix_fmt yuv444p выдает 153 Мбит / с вывода
YUV 4:2:2 через -f avi -c:v utvideo -pix_fmt yuv422p выдает вывод 123 Мбит / с
YUV 4:2:0 через -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. В настоящее время в FFmpeg есть три различных prores* , но только 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 дает то, что вы могли бы назвать "MJPEG без потерь", но, как правило, нам не интересно вставлять много файлов неподвижных изображений в A/V контейнер здесь, чтобы сделать фильм. Мы хотим, чтобы здесь были общепризнанные видеокодеки, а не семантические трюки.
В настоящее время команда не может отфильтровать некоторые неподходящие кодеры, такие как GIF, поскольку в настоящее время они не описаны в выходных данных ffmpeg -codecs как bitmap или image форматы файлов.
GIF является интересным случаем: он поддерживает несколько кадров изображения в одном файле GIF с информацией о синхронизации для воспроизведения движения, но по нескольким причинам он совершенно не подходит для нашего обсуждения здесь.
Некоторые из показанных опций устарели или никогда не пользовались большой популярностью, например flashsv , dirac и snow , поэтому обсуждать их выше не стоит.
Некоторые параметры в этом списке предназначены только для использования в конвейерах между экземплярами ffmpeg или между ffmpeg и другой программой, такой как rawvideo и wrapped_avframe , и поэтому здесь не подходят для наших целей.
Ближе к концу обсуждения выше, я разумно немного расширил область вопроса, включив в нее несколько тщательно выбранных параметров с потерями, чтобы они не пропустили первый фильтр grep в приведенной выше команде.
