Універсальний відеоформат без втрат

Я намагаюся знайти найбільш підходящий формат відео без втрат для 1280x720 відео в 25 кадрів в секунду. Відео має 4 хвилини. Звук складе 320 kbps mp3, це не є великою справою. Ідеальні умови:

Без втрат (можна сприймати без втрат)
Контейнер + кодек можна відтворювати на більшості платформ
Контейнер + кодек можна відтворювати на сучасних програвачах DVD (підтримуючи інші формати, крім DVD)
Розмір менше 700 Мб

Це навіть можливо? Випробовуєте вже три дні, не маючи задовільних результатів, навіть отримуючи 12 ГБ файлів (здається, багато - 3 ГБ / хвилина).

video ffmpeg video-editing

— мрква
джерело

Для порівняння см en.wikipedia.org/wiki/List_of_codecs#Lossless_compression

— artistoex

Вибачте, але ви практично не можете отримати (візуально) 720p відео без втрат за 4 хвилини, стиснуте до менш ніж 700 Мб (я припускав, що тут Мегабайт, а не "mb", що означало б "біт"). Чому у вас таке обмеження? Неможливо відео кодувати h.264?

— slhck

так, МБ, вибачте за плутанину. Мені потрібно помістити cca 5 відео x 4 хвилини на 4 ГБ (середні обмеження).

— мрква

Оскільки ви отримуєте файли 12GiB, я вважаю, що ви використовуєте глибину кольору 24Bit. Потік нестиснених відео даних складає близько 4 Гбіт в хвилину. Це величезна кількість даних. Те, що ви хочете, - це приблизно 170 Мбіт в хвилину. Незалежно від обраного кодеку, ви можете досягти цього лише статичною сценою без особливих рухів. Боюся, вам доведеться розслабити контраст, щоб не втратити, зменшити частоту кадрів або допустити більший розмір файлу.

— Марко

Чи можете ви уточнити: "Container + кодек може відтворюватися на сучасних програвачах DVD (підтримуючи інші формати, крім DVD)"?

— llogan

Відповіді:

Найкращий фактичний, математично збитковий формат, про який я знаю, - це huffyuv, але це дозволить створити надзвичайно величезні файли, і це було б не сумісно з багатьма. Для запису ffmpeg може це зробити за допомогою:

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

X264, кодер з відкритим кодом h.264, має режим без втрат. Це може містити контейнер MP4 і має бути сумісним з більшістю обладнання, виготовленого за останні кілька років. Перша команда дасть швидку швидкість кодування, але великий файл; друга команда займе набагато більше часу, але файл повинен бути приблизно вдвічі меншим за розміром швидко кодованого (він все ще буде досить великим):

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

Якщо це не дає вам достатньо невеликого файлу, CRF з 18, як правило, вважається "візуально без втрат":

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

Я, як правило, рекомендую дуже швидке налаштування для кодування за допомогою x264, на мій досвід, він пропонує найкращу швидкість / розмір компромісу (є великий перепад розміру файлу між надшвидким та дуже швидким, будь-який повільніше, ніж це, і він є більш поступовим). Загальна порада - використовувати найповільніші налаштування, якими ви можете скористатися, такі пресети: надшвидкий, надшвидкий, дуже швидкий, швидкий, швидкий, швидкий, середній, повільний, повільніший, вейслоlow.

Дивіться тут для більш глибокого посібника з кодування x264.

— злість
джерело

Не пропонуйте veryfastгарний дефолт для втрати x264. mediumце хороша середина, але я зазвичай використовую veryslowдля остаточного кодування чого-небудь. Крім того, huffyuvце не дуже швидко, я б не рекомендував його нічого, крім сумісності.

— Пітер Кордес

ffmpeg має ще кілька кодеків без втрат, які, можливо, варто спробувати [FFv1 також]. GL!

— rogerdpack

Не libx264 знижує два кольорових канали (у YUV УФ) вдвічі в будь-якому напрямку, навіть якщо ви використовуєте CRF 0, так що це не справді без втрат. Крім того, при помилках округлення дані не гарантуються, що вони є біт-за-бітом вказівні після раунда стиснення x264.

— Адісак

У моїх експериментах з ffmpeg 3.4.1, libx264 використовував формат пікселів yuv444, де "444" означає "не знижувати зразок U, V". І ОП явно не проти помилок округлення: "може бути безпристрасно без втрат". Отже, @Adisak, ваші занепокоєння є обґрунтованими, але не стосуються цієї відповіді.

— Jim DeLaHunt

ffmpeg і libx264 в режимі YUV узгоджують формат пікселів YUV на основі вхідних даних. Отже, якщо вхід YUV 4: 2: 0, то і формат пікселя на виході. Якщо вхід YUV 4: 4: 4 або RGB, то вихід YUV 4: 4: 4.

— Gyan

У наші дні мені подобається webm :

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

Для швидшого перетворення за допомогою багатоядерних процесорів я читав, що рекомендується використовувати один потік менше, ніж у вас справжніх ядер. Отже, за допомогою 8 ядра ви можете вказати 7 потоків:

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm

— LonnieBest
джерело

Мені подобається використовувати змінну середовища% NUMBER_OF_PROCESSORS%, щоб визначити кількість потоків для використання. Якщо кількість рахунків дорівнює 1 або 2, я використовував усі процесори. Якщо кількість дорівнює 3 або 4, я використовую всі, крім одного процесора. І якщо кількість вище, я використовую всі, крім двох процесорів, для підрахунку потоку.

— Адісак

Як вирази DOS, це виглядає так: якщо "% ADJUSTED_CPUCOUNT%" EQU "" (якщо% NUMBER_OF_PROCESSORS% EQU 1 (встановити ADJUSTED_CPUCOUNT = 1) інше, якщо% NUMBER_OF_PROCESSORS% EQU 2 (встановити ADJUSTED_CPOROCPOR) EQU 3 (встановити ADJUSTED_CPUCOUNT = 2) інше, якщо% NUMBER_OF_PROCESSORS% EQU 4 (встановити ADJUSTED_CPUCOUNT = 3) інше (set / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2))

— Adisak

superuser.com/questions/155305/… каже, що ffmpeg вже вибирає оптимальну кількість ниток

— Борис

Кращий вибір, ніж webm (в наші дні), можливо, формат av1 .

— LonnieBest

-1

# КОНТЕЙНЕР

щоб мати повну сумісність з програвачами DVD, вам потрібно буде використовувати формат MPEG-2, контейнер, обмеження, кодеки. Я здогадуюсь, "сучасні плеєри" означають сумісність "mp4", яка в основному є і здебільшого mp4-плеєром - H.264, MPEG-4, AVC => libx264
читати далі: https://de.wikipedia.org/wiki /H.264

# ВІДЕО

Погляньте на https://trac.ffmpeg.org/wiki/Encode/H.264 , особливо частину, де йдеться про "профіль" та "рівень", для сумісності
Використання -profile:v high -level 4.0має робити це

# АУДІО

Уникайте повторного кодування аудіозаписів кодеками з втратою - будь-який формат mp3 є втратним, навіть 320 кбіт / с.
Використовуйте -c:a copyзамість цього.

Поки що це зробило досить непогану роботу для мене. немає проблем із синхронізацією.
Аудіо потоки не прив’язані до ключових кадрів. Точні порізи можливі.
Якщо ваша аудіо-запис записана на частоті дискретизації 44 кГц, використовуйте макс. 256kbps

Використовуйте втрачені кодеки лише для остаточного кодування вашого відео, якщо вам потрібно відповідати певним умовам.

Я чув про деякі проблеми з аудіосинхронізацією, але, схоже, головна проблема там була, це захищений матеріал (!).

# Нарешті

Я вважаю за краще щось подібне:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

— d'oh
джерело

Опція "-рівень 4.0" не потрібна. Рівень у x264 визначається на основі роздільної здатності та FPS, тому зазвичай немає сенсу встановлювати його вручну, це нічого не поліпшить. Наскільки я знаю, ffmpeg може встановити правильний рівень автоматично, тому, якщо у вас немає дуже вагомих причин змусити його і повністю зрозуміти, як вибрати рівень на основі FPS та роздільної здатності, ви не повинні використовувати опцію "-level". Якщо ви дбаєте про найвищу сумісність, використовуйте профіль «базовий рівень» замість «високий».

— Ліссанро Рейен