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

Я пытаюсь найти наиболее подходящий формат видео без потерь для видео 1280x720 25fps. Видео имеет 4 минуты. Звук будет 320 кбит / с mp3, это не имеет большого значения. Идеальные условия:

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

Это вообще возможно? Уже три дня боролись, без каких-либо удовлетворительных результатов, даже получая файлы 12 ГБ (кажется, много - 3 ГБ / мин).

video ffmpeg video-editing

— mrkva
источник

Для сравнения см en.wikipedia.org/wiki/List_of_codecs#Lossless_compression

— artistoex

Извините, но вы практически не можете получить (визуально) видео без потерь 720p за 4 минуты, сжатое до менее чем 700 МБ (здесь я предположил мегабайт, а не «mb», что означало бы «бит»). Почему у вас есть такое ограничение? Разве видео не может быть закодировано в формате h.264?

— slhck

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

— Мрква

Поскольку вы получаете файлы размером 12 ГБ, я предполагаю, что вы используете 24-битную глубину цвета. Поток несжатых видеоданных составляет около 4 ГБ в минуту. Это огромное количество данных. То, что вы хотите, составляет около 170 МБ в минуту. Независимо от того, какой кодек вы выберете, вы можете достичь этого только со статичной сценой без особого движения. Я боюсь, что вам нужно ослабить ограничения, чтобы избежать потерь, уменьшить частоту кадров или допустить больший размер файла.

— Марко

Не могли бы вы уточнить: «Контейнер + кодек можно воспроизводить на современных проигрывателях 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 обычно считается «визуально без потерь»:

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

Как правило, я рекомендую очень быстрый пресет для кодирования с x264, по моему опыту он предлагает лучший компромисс между скоростью и размером (существует большой спад в размере файла между супербыстрым и очень быстрым, любой медленнее, чем этот, и он более инкрементный). Общий совет - использовать самые медленные пресеты, которые вы можете обработать, пресеты: сверхбыстрые, сверхбыстрые, очень быстрые, быстрые, быстрые, средние, медленные, медленные, очень низкие.

Смотрите здесь для более подробного руководства по кодированию x264.

— evilsoup
источник

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

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

У ffmpeg есть несколько других кодеков без потерь, которые также стоит попробовать [FFv1 приходит на ум]. GL!

— rogerdpack

Не понижает ли libx264 два цветовых канала (в YUV UV) наполовину в любом направлении, даже если вы используете CRF 0, так что это не совсем без потерь. Кроме того, с ошибками округления не гарантируется, что данные будут идентичны по битам после цикла сжатия x264.

— Адисак

В моих экспериментах с ffmpeg 3.4.1 в libx264 использовался пиксельный формат yuv444, где «444» означает «не уменьшать частоту U, V». И ОП явно не возражает против ошибок округления: «может быть без потери восприятия». Итак, @ Adisak, ваши опасения разумны, но не применимы к этому ответу.

— Джим 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 это выглядит так: if "% ADJUSTED_CPUCOUNT%" EQU "" (если% NUMBER_OF_PROCESSORS% EQU 1 (установить ADJUSTED_CPUCOUNT = 1), в противном случае, если% NUMBER_OF_PROCESSORS% EQU 2 (установить ADJUSTED_CPESSOF%% NBER = PUCOUNT% NCP = OCOROF% EQU 3 (установите ADJUSTED_CPUCOUNT = 2) иначе, если% NUMBER_OF_PROCESSORS% EQU 4 (установите ADJUSTED_CPUCOUNT = 3), иначе (установите / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2)

— Адисак,

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должно сделать это

# AUDIO

Избегайте перекодирования аудио-треков с кодеками с потерями - любой формат mp3 с потерями, даже 320 кбит / с.
Используйте -c:a copyвместо этого.

До сих пор это сделало довольно хорошую работу для меня. нет проблем с синхронизацией
Аудиопотоки не привязаны к ключевым кадрам. Точные сокращения возможны.
Если ваша звуковая дорожка записана с частотой дискретизации 44 кГц, используйте макс. 256 Кбит / с

Используйте кодеки с потерями только для окончательного кодирования вашего видео, если вам необходимо выполнить определенные предварительные условия.

Я слышал о некоторых проблемах с синхронизацией звука, но похоже, что основная проблема была, это был защищенный материал (!).

# В заключение

Я бы предпочел что-то вроде этого:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

— d'ой
источник

Опция "-level 4.0" не нужна. Уровень в x264 определяется на основе разрешения и FPS, поэтому обычно нет смысла устанавливать его вручную, это ничего не улучшит. Насколько я знаю, ffmpeg может устанавливать правильный уровень автоматически, поэтому, если у вас нет веских причин для его принудительного применения и полного понимания того, как выбирать уровень на основе FPS и разрешения, вы не должны использовать опцию «-level». Если вы заботитесь о максимальной совместимости, используйте профиль «baseline» вместо «high».

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