кодирование без потерь h264
можно ли сделать полностью без потерь кодирование в h264? Под "без потерь" я подразумеваю, что если я подам ему серию кадров и закодирую их, а затем, если я извлеку все кадры из закодированного видео, я получу те же самые кадры, что и во входе, пиксель за пикселем, кадр за кадром. Это действительно возможно? Возьмем такой пример:
я генерирую кучу кадров, затем кодирую последовательность изображений в несжатый AVI( с чем-то вроде virtualdub), затем применяю lossless h264 (файлы справки утверждают, что setting --qp 0 делает сжатие без потерь, но я не уверен, означает ли это, что в любой точке процесса нет потерь или что только квантование без потерь). Затем я могу извлечь кадры из полученного видео h264 с помощью чего-то вроде mplayer.
сначала я попробовал ручной тормоз, но оказалось, что он не поддерживает кодировку без потерь. Я пробовал x264, но он падает. Это может быть потому, что мой исходный AVI-файл находится в цветовом пространстве RGB вместо YV12. Я не знаете, как кормить серию растровых изображений YV12 и в каком формате x264 в любом случае, поэтому я даже не могу попробовать.
в резюме что я хочу знать, если есть способ, чтобы перейти от
серия растровых изображений без потерь (в любом цветовом пространстве) -> некоторое преобразование -> кодирование h264 -> декодирование h264 -> некоторое преобразование -> исходная серия растровых изображений без потерь
Если есть способ достичь этого?
EDIT: есть очень верный момент о том, что без потерь H264 не делает тоже много смысла. Я хорошо знаю, что я не могу сказать (только глазами) разницу между и несжатым клипом и другим сжатым с высокой скоростью в H264, но я не думаю, что это не без использования. Например, это может быть полезно для хранения видео для редактирования, не занимая огромное количество места и не теряя качества и тратя слишком много времени на кодировку каждый раз, когда файл сохраняется.
обновление 2: Теперь у x264 не рухнет. Я могу использовать в качестве источников avisynth или без потерь yv12 lagarith (чтобы избежать предупреждения о сжатии цветового пространства). Howerver, даже с --qp 0 и источником rgb или yv12 я все еще получаю некоторые различия, минимальные, но присутствующие. Это беспокоит, потому что вся информация, которую я нашел о предсказательном кодировании без потерь (--qp 0), утверждает, что вся кодировка должна быть без потерь, но я не могу проверить это.
8 ответов
Я собираюсь добавить поздний ответ на этот вопрос, проведя весь день, пытаясь выяснить, как получить YUV 4:4:4 пикселей в x264. Хотя x264 принимает raw 4:2:0 пикселей в файле, на самом деле довольно сложно получить 4:4: 4 пикселей. С последними версиями ffmpeg, следующие работы для полностью без потерь кодирования и извлечения для проверки кодирования.
во-первых, напишите raw 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!
Если x264 делает кодировку без потерь, но не нравится ваш формат ввода, то лучше всего использовать ffmpeg для работы с входным файлом. Попробуйте начать с чего-то вроде
ffmpeg -i input.avi -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout \
| x264 $OPTIONS -o output.264 /dev/stdin
и добавление опций оттуда. YUV4MPEG-это несжатый формат без потерь, подходящий для трубопроводов между различными видеоинструментами; ffmpeg знает, как его писать, а x264 знает, как его читать.
Я не знаю ваших требований к сжатию и декомпрессии, но архиватор общего назначения (например, 7-zip с LZMA2) должен иметь возможность сжимать примерно так же мало или, в некоторых случаях, даже значительно меньше, чем видеокодек без потерь. И это намного проще и безопаснее, чем целая цепочка обработки видео. Недостатком является гораздо более медленная скорость, и что вы должны извлечь, прежде чем увидеть его. Но для изображений, я думаю, вы должны попробовать.
существует также изображение без потерь форматы, например .формат PNG.
для кодирования RGB без потерь с x264 вы должны использовать версию командной строки x264 (вы не можете доверять GUIs в этом случае edge, они, вероятно, испортят) r2020 или новее, с чем-то вроде этого:
x264 --qp 0 --preset fast --input-csp rgb --output-csp rgb --colormatrix GBR --output "the_lossless_output.mkv" "someinput.avs"
любые потери / различия между входом и выходом должны быть от некоторого преобразования цветового пространства (либо до кодирования, либо при воспроизведении), неправильных настроек или некоторых потерянных заголовков/метаданных. x264 не поддерживает RGBA, но RGB в порядке. ЮВ Сжатие 4:4:4 более эффективно, но вы потеряете некоторые данные в преобразовании цветового пространства, так как ваш вход RGB. YV12 / i420 намного меньше и на сегодняшний день является наиболее распространенным цветовым пространством в видео, но у вас меньше разрешения цветности.
дополнительная информация о настройках x264: http://mewiki.project357.com/wiki/X264_Settings
кроме того, избегайте lagarith. Он использует плавающую точку x87... и есть лучше альтернативы. http://codecs.multimedia.cx/?p=303 http://mod16.org/hurfdurf/?p=142
изменить: Я не знаю, почему я был donwvoted. Пожалуйста, оставьте комментарий, когда вы это сделаете.
FFmpeg имеет режим "без потерь" для x264, см. руководство по кодированию FFmpeg и x264
по сути это -qp 0
для того чтобы произвести lossless H. 264 с GUI HandBrake, установите видео-кодек: H. 264, постоянн качество, RF: 0, H. 264 профиль: автомобиль. Хотя этот файл изначально не поддерживается Apple, он может быть повторно закодирован как почти без потерь для воспроизведения.
Гуй ручник:H. 264 профиль: авто;кодирование при постоянном RF 0.000000...профиль высокий 4:4:4 интеллектуального, уровня 3.0, 4:2:0 8 бит
профиль H. 264: высокий;Кодирование в постоянный RF 0.000000...без потерь требуется профиль high444, отключение...высокий профиль, уровень 3.0
Если вы не можете получить сжатие без потерь с помощью h.264 кодер и декодер, возможно, вы могли бы рассмотреть две альтернативы:
(1) вместо передачи всех данных в h.Формат 264, некоторые люди экспериментируют с передачей некоторых данных с помощью остаточной "боковой канал":
- (ч. 264 файл) - > H264 декодировать - > некоторые преобразования - > приближение с потерями исходной серии растровых изображений
- (сжатый остаточный файл) --> декодер - > серия остаточных растровых изображений без потерь
- для каждого пикселя в каждом растровом изображении, approximate_pixel + residual_pixel = бит пиксела за бит, равный исходному пикселю.
(2) используйте формат сжатия видео Dirac в режиме "без потерь".
Я согласен, что иногда потеря данных приемлема, но дело не только в том, как она выглядит сразу после сжатия.
даже визуально незаметная потеря цветовых данных может ухудшить кадры, такие как цветокоррекция, зеленый экран, отслеживание и другие задачи post становятся более сложными или невозможными, что добавляет затраты на производство.
Это действительно зависит от того, когда и как вы сжимаете в конвейере, но в конечном итоге имеет смысл архивировать оригинальное качество, так как хранение обычно намного дешевле, чем перепрофилирование.
Это не совсем ответ на ваш вопрос, а скорее причина, почему быть потерянным может быть лучше, чем без потерь.
вот сравнение одного и того же изображения, но, закодированных по-разному с форматом с потерями и без потерь.
PNG (без потерь) 148 КБ:
JPEG-8 (с потерями) 36 КБ:
JPEG-10 (с потерями) 65 КБ:
JPEG-12 (с потерями) 122 КБ:
теперь откройте изображение PNG (без потерь) и изображение JPEG-10 (с потерями) на двух новых вкладках в вашем веб-браузере. Переверните назад и вперед, вы можете увидеть слабую разницу, но едва. Я хочу сказать, что вы никогда бы не заметили разницы в качестве, не посмотрев на них обоих одновременно и не изучив их внимательно. Сжатие данных без потерь не стоит в большинстве случаев, потому что форматы с потерями могут дать вам точное качество при более низкой стоимости (размер файла).