H264 кодирование без потерь

Можно ли полностью кодировать без потерь в h264? Без потерь я имею в виду, что если я буду кормить его серией кадров и закодировать их, а затем, если я извлечу все кадры из кодированного видео, я получу те же самые кадры, что и во входном, пиксельном пикселе, по кадре, Это действительно возможно? Возьмите этот пример:

Я генерирую кучу кадров, затем кодирую последовательность изображений в несжатый AVI (с чем-то вроде virtualdub), затем применяю без потерь h264 (файлы справки утверждают, что установка --qp 0 делает сжатие без потерь, но я не уверен, что это означает, что в любой момент процесса нет потерь или что квантование без потерь). Затем я могу извлечь кадры из полученного видео h264 с чем-то вроде mplayer.

Сначала я попытался использовать Handbrake, но, оказывается, он не поддерживает кодирование без потерь. Я попробовал x264, но он сработает. Возможно, это связано с тем, что мой исходный AVI файл находится в цветовом пространстве RGB вместо YV12. Я не знаю, как кормить серию растровых изображений YV12 и в каком формате для x264 в любом случае, поэтому я даже не могу попробовать.

Вкратце, что я хочу знать, если есть способ перехода от

Серия растровых изображений без потерь (в любом цветовом пространстве) → некоторое преобразование → h264 encode → h264 decode → некоторое преобразование → исходная серия растровых изображений без потерь

Если есть способ достичь этого?

EDIT: Существует ОЧЕНЬ действительная точка без потерь H264, которая не имеет особого смысла. Мне хорошо известно, что я никак не могу сказать (с моими глазами) разницу между несжатым клипом и другим сжатым с высокой скоростью в H264, но я не думаю, что это не без использования. Например, это может быть полезно для хранения видео для редактирования, не занимая огромных пространств, а не теряя качество и тратя слишком много времени на кодирование при каждом сохранении файла.

ОБНОВЛЕНИЕ 2: Теперь x264 не сбой. Я могу использовать в качестве источников либо avisynth, либо без потерь yv12 lagarith (чтобы избежать предупреждения сжатия цветового пространства). Howerver, даже с -qp 0 и источником rgb или yv12, я все еще получаю некоторые различия, минимальные, но присутствующие. Это вызывает беспокойство, потому что вся информация, которую я обнаружил при прогностическом кодировании без потерь (-qp 0), утверждает, что вся кодировка должна быть без потерь, но я не могу проверить это.

Ответ 1

Я собираюсь добавить последний ответ на этот вопрос, проведя весь день, пытаясь понять, как получить YUV 4: 4: 4 пикселя в x264. В то время как x264 действительно принимает исходные 4: 2: 0 пикселов в файле, это действительно довольно сложно получить 4: 4: 4 пикселя. В последних версиях ffmpeg для работы с кодировкой и извлечением без потерь можно выполнить следующее:

Сначала напишите свой необработанный файл yuv 4: 4: 4 в файл в плоском формате. Плоскость представляет собой набор байтов Y, а затем U и V байты, где U и V используют 128 в качестве нулевого значения. Теперь вызовите ffmpeg и передайте размер необработанных кадров YUV, используя два пиксельных формата "yuv444p", например:

ffmpeg -y -s 480x480 -pix_fmt yuv444p -i Tree480.yuv \
-c:v libx264 -pix_fmt yuv444p -profile:v high444 -crf 0 \
-preset:v slow \
Tree480_lossless.m4v

Как только кодирование в h264 и завершение в качестве файла Quicktime завершено, можно извлечь точно такие же байты:

ffmpeg -y -i Tree480_lossless.m4v -vcodec rawvideo -pix_fmt yuv444p \
Tree480_m4v_decoded.yuv

Наконец, проверьте два двоичных файла с diff:

$ diff -s Tree480.yuv Tree480_m4v_decoded.yuv
Files Tree480.yuv and Tree480_m4v_decoded.yuv are identical

Просто имейте в виду, что вам нужно записать байты YUV в файл самостоятельно, не позволяйте ffmpeg делать любое преобразование значений YUV!

Ответ 2

Если x264 делает кодирование без потерь, но не нравится ваш формат ввода, то лучше всего использовать ffmpeg для обработки входного файла. Попробуйте начать с чего-то вроде

ffmpeg -i input.avi -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout \
  | x264 $OPTIONS -o output.264 /dev/stdin

и добавление параметров оттуда. YUV4MPEG - это несжатый формат без потерь, подходящий для соединения между различными видеоустройствами; ffmpeg знает, как его записать, и x264 знает, как его читать.

Ответ 3

Я не знаю ваших требований к сжатию и декомпрессии, но архиватор общего назначения (например, 7-zip с LZMA2) должен иметь возможность сжимать как малые или, в некоторых случаях, даже значительно меньше, чем видеокодек без потерь, И это намного проще и безопаснее, чем целая цепочка видеообработки. Недостатком является гораздо более медленная скорость, и вам нужно извлечь ее, прежде чем ее увидеть. Но для изображений, я думаю, вы должны попробовать.

Также есть форматы изображений без потерь, например .png.

Для кодирования без потерь RGB с x264 вы должны использовать версию командной строки x264 (вы не можете доверять графическим интерфейсам в этом случае, они, вероятно, будут беспорядочно) r2020 или новее, с чем-то вроде этого:

x264 --qp 0 --preset fast --input-csp rgb --output-csp rgb --colormatrix GBR --output "the_lossless_output.mkv" "someinput.avs"

Любые потери/различия между входом и выходом должны быть из какого-либо преобразования цветового пространства (до кодирования или при воспроизведении), неправильных настроек или некоторых утерянных заголовков/метаданных. x264 не поддерживает RGBA, но RGB в порядке. Сжатие YUV 4: 4: 4 более эффективно, но вы потеряете некоторые данные в преобразовании цветового пространства, так как ваш вход RGB. YV12/i420 намного меньше и, безусловно, наиболее распространенное цветовое пространство в видео, но у вас меньше разрешения цветности.

Дополнительная информация о настройках x264: http://mewiki.project357.com/wiki/X264_Settings

Кроме того, избегайте лагаритов. Он использует x87 с плавающей запятой... и есть лучшие альтернативы. http://codecs.multimedia.cx/?p=303 http://mod16.org/hurfdurf/?p=142

EDIT: Я не знаю, почему меня не одобрили. Пожалуйста, оставьте комментарий, когда вы это сделаете.

Ответ 4

FFmpeg имеет режим "без потерь" для x264, см. Руководство по кодированию FFmpeg и x264

& Раздел; Lossless H.264

по существу это -qp 0

Ответ 5

Чтобы создать без потерь H.264 с GUI HandBrake, установите Video Codec: H.264, Constant Quality, RF: 0, H.264 Profile: auto. Хотя этот файл не поддерживается Apple, он может быть перекодирован как почти без потерь для воспроизведения.

Окно активности GUI HandBrake:

H.264 Профиль: auto; Кодирование при константе RF 0.000000... профиль Высокий 4: 4: 4 Предсказательный, уровень 3.0, 4: 2: 0 8-бит

H.264 Профиль: высокий; Кодирование при постоянном RF 0,000000... без потерь требует профиля high444, отключения... профиля, уровня 3.0

Ответ 6

Если вы не можете получить сжатие без потерь, используя кодировщик и декодер h.264, возможно, вы могли бы изучить две альтернативы:

(1) Вместо того, чтобы передавать все данные в формате h.264, некоторые люди экспериментируют с передачей некоторых данных с остаточным "боковым каналом" :

(h.264 файл) → h264-декодирование → некоторое преобразование → приближение с потерями исходной серии растровых изображений
(сжатый остаточный файл) → декодер → серия остаточных растровых изображений без потерь
Для каждого пикселя в каждом растровом изображении приблизительный_пиксель + остаток_пиксель = бит бит бит для бит, равный исходному пикселю.

(2) Используйте формат сжатия видеоизображения Dirac в режиме "без потерь".

Ответ 7

Я согласен, что иногда потеря данных приемлема, но это не просто вопрос о том, как она выглядит сразу после сжатия.

Даже визуально незаметная потеря цветовых данных может ухудшить кадры, так что цветокоррекция, привязка к зеленому экрану, отслеживание и другие пост-задачи становятся более трудными или невозможными, что увеличивает затраты на производство.

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

Ответ 8

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

Здесь приведено сравнение одного и того же изображения, но кодируется по-разному с форматом с потерями и без потерь.

PNG (без потерь) 148 kB:

JPEG-8 (потеря) 36 kB:

JPEG-10 (потеря) 65 kB:

JPEG-12 (потеря) 122 kB:

Теперь откройте PNG (без потерь) изображение и изображение JPEG-10 (потеря) в двух новых вкладках в вашем веб-браузере. Переверните назад и вперед, вы можете видеть слабую разницу, но едва. Я хочу сказать, что вы никогда не скажете разницу в качестве, не глядя на обоих из них в одно и то же время и внимательно изучая их. Сжатие данных без потерь не стоит в большинстве случаев, потому что форматы с потерями могут дать точное качество по более низкой цене (размер файла).