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

Question

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

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

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

Подводя итог, я хочу знать, есть ли способ перейти от

Серия растровых изображений без потерь (в любом цветовом пространстве) -> некоторое преобразование -> Кодирование h264 -> Декодирование h264 -> Некоторое преобразование -> Исходная серия растровых изображений без потерь

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

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

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

Answer 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!

Answer 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 знает, как его прочитать.

Answer 3

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

& Раздел; Без потерь H.264

по сути это -qp 0

Answer 4

Я не знаю ваших требований к сжатию и распаковке, но архиватор общего назначения (например, 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

РЕДАКТИРОВАТЬ: Я не знаю, почему я был проголосовал.Пожалуйста, оставьте комментарий, когда вы это сделаете.

Answer 5

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

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

H.264 Profile: auto; Кодирование при постоянном RF 0,000000 ... профиль Высокий 4: 4: 4 Прогнозирующий, уровень 3,0, 4: 2: 0 8-битный

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

Answer 6

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

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

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

Answer 7

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

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

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

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