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

Я пытаюсь найти наиболее подходящий формат видео без потерь для видео 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».

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