Існує кілька способів позбутися "нестисненого" 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 біт на компонент (bpc), томудля мого тестуванняобом потрібно 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 bpc вище, не отримуючи перевагу більш глибокого кольорового простору.
У 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 трохи поцікавиться таким файлом, але він відтворює його. Як не дивно, проте VLC не відтворить його, хоча частково базується ffmpeg. Я б дотримувався контейнерів QT для цього кодека.
Кодек анімації QuickTime використовує тривіальну схему RLE , тому для простих анімацій це слід робити так само, як і Huffyuv нижче. Чим більше кольорів у кожному кадрі, тим більше він наближається до швидкості передачі бітів повністю нестиснених параметрів, наведених вище. Під час мого тестування з Big Buck Bunny мені вдалося отримати ffmpegфайл 165 Мбіт / с у режимі RGB 4: 4: 4 через -pix_fmt rgb24.
Хоча цей формат стискається, він надасть однакові значення вихідних пікселів вашим вхідним файлам PNG з тієї ж причини, що стиснення без втрат PNG не впливає на значення пікселів.
Реалізація ffmpegQuickTime Animation також підтримує -pix_fmt argb, завдяки чому ви отримуєте RGB 4: 4: 4: 4, це означає, що він має альфа-канал. Дуже грубо подібним чином це еквівалент QuickTime -c:v ayuv, згаданий вище. Через стиснення без втрат вона дорівнює лише 214 Мбіт / с , меншою за rate швидкість передачі даних AYUV з нульовою втратою якості або особливостей.
Існують варіанти QuickTime Animation, що мають менше 24 біт на піксель, але їх найкраще використовувати для прогресивно простіших стилів анімації. ffmpegСхоже, підтримує лише один з інших форматів, визначених специфікацією -pix_fmt rgb555be, що означає 15 bpp RGB big-endian. Це допустимо для деяких відео, і чудово підходить для більшості знімків екранізації та простих анімацій. Якщо ви можете прийняти зменшення простору кольорів, швидкість передачі даних 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
Ефективно без втрат: трюк ЮВ
Тепер, що стосується 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 та rate швидкість передачі даних 4: 4: 4.
Ви також іноді бачите 4: 1: 1, як у старому стандарті DV-камери . 4: 1: 1 має ту саму нестиснуту швидкість передачі даних, що і 4: 2: 0, але кольорова інформація розташована інакше.
Сенс всього цього полягає в тому, що якщо ви починаєте з файлу H.264 у форматі 4: 2: 0, повторне кодування його до 4: 4: 4 нестисненого RGB не купує вам абсолютно нічого за 4: 2: 0 без стиснення без втрат YUV. Це вірно, навіть якщо ви знаєте, що ваш робочий процес в іншому випадку становить 4: 4: 4 RGB, оскільки це тривіальне перетворення; Відео- та програмне забезпечення роблять такі перетворення на ходу звичайно.
Насправді вам потрібні лише 4: 4: 4, коли ви переглядаєте пікселі або робите піксельні зміни кольору на відео, і вам потрібно зберегти точні значення пікселів. Робота з візуальними ефектами (VFX) простіше виконати, наприклад, у форматі пікселів 4: 4: 4, тому будинки високого класу VFX часто готові терпіти більш високі швидкості передачі даних, які потрібні.
Ефективно без втрат: вибір кодека
Як тільки ви відкриєте себе до кодеків YUV з кольоровим зменшенням, ваші параметри також відкриються. ffmpegмає безліч кодеків без втрат .
Хаффюв
Найбільш сумісний варіант - 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 QuickTime Animation. Два кодеки будуть дещо відрізнятися стисненням для даного файлу, але вони зазвичай будуть близькими.
Це по суті те саме, що і режим YUV 4: 4: 4, який використовується вищевказаним варіантом V308. Різниця в кольоровому просторі практично не відрізняється, оскільки перетворення простору кольорів легко зробити в режимі реального часу.
Завдяки стисненню Huffyuv, я зміг отримати тестове відео для стиснення до близько 251 Мбіт / с в режимі RGB24, з однаковою візуальною якістю, ніж у V308 або AYUV. Якщо AVI для вас абсолютно необхідний , установка кодека Huffyuv , ймовірно, менш болісна, ніж оплата 3 × швидкості передачі даних AYUV.
YUV 4: 2: 2 - Цей режим набагато практичніший для відео, ніж RGB24, що, безсумнівно, ffmpegрозробники вирішили його реалізувати першими. Як ви очікували від розглянутих вище теоретичних discussed скорочень, мій тестовий файл кодується до 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читати ці файли на Macs.
Цей кодек є дуже гнучким щодо кольорових просторів, тому я наведу лише кілька прикладів загальних кольорових просторів:
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, так що якщо ви подасте його одним із офіційних файлів MP4 Big Buck Bunny MP4, який використовує YUV 4: 2: 0, це ви отримаєте якщо ви не надасте -pix_fmtпрапор ffmpeg. У результаті виходить вихідний файл 63 Мбіт / с .
Якщо ви змусите FFV1 використовувати кольоровий простір YUV 4: 4: 4 -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 PNG, як у оригінальному запитанні, і приводить до 44 Мбіт / сек файл з нашим тестовим файлом
yuv422p : Це схоже на кольоровий простір за замовчуванням для Huffyuv, але в цьому випадку ми отримуємо 34 Мбіт / сек файл, досить економія!
yuv420p : Це типовий параметр для офіційних MP4 Big Buck Bunny, з якими я тестую, і отримує файл 29 Мбіт / сек .
Не забудьте торгувати великою кількістю сумісності, щоб отримати такі невеликі розміри файлів. Тому я навіть не намагався вкласти це в контейнер AVI або MOV. Він настільки тісно пов'язаний з x264, що ви можете використовувати його стандартний тип контейнера (MP4). Ви також можете використати для цього щось на зразок Матроски .
Ви можете торгувати частиною цієї швидкості передач, щоб швидше кодувати час, додавши -preset ultrafast. Це збільшило бітову швидкість мого тестового файлу до 44 Мбіт / с в режимі YUV 4: 2: 2, але кодується набагато швидше, як і було обіцяно. Документи стверджують, що -preset veryslowтакож варто, але це призвело до набагато більшого часу кодування, заощаджуючи лише крихітний простір; Я не можу рекомендувати це.
Інші
ffmpegтакож підтримує режим декодування для Lagarith і режим тільки для кодування для JPEG без втрат . Ці два кодеки насправді дещо схожі, і повинні надавати файлам трохи менше, ніж Huffyuv з однаковою якістю. Якщо ffmpegрозробники коли-небудь додадуть кодування Lagarith, це було б сильною альтернативою Huffyuv. Я не можу рекомендувати JPEG без втрат, оскільки він не користується широкою підтримкою декодування.
Перцептуально без втрат: або, ймовірно, ви можете піти з деякими втратами
Потім є кодеки, які сприймаються без втрат. Якщо ви не пикаєте пікселі, ви майже напевно не можете сказати, що вони дають інші візуальні результати, ніж попередні дві групи. Відмовившись від ідеї абсолютно нульової зміни між датчиком відеозйомки та пристроєм відображення, ви купуєте значну економію:
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 для відеопрограми Apple, меншими накладними витратами на процесор для кодування та декодування, або передбачувані швидкості передачі бітів. Останнє важливо, наприклад, з апаратними кодерами. З іншого боку, якщо ви можете впоратися з проблемами сумісності 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 і pro відеосвітів.
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фільтр у вищевказаній команді.
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov.