Может ли H264 достичь «эквивалентности» ProRes 422?

Судя по цифрам, h264 имеет меньшую глубину цвета и точность цветопередачи, чем ProRes 422. PR422 имеет 10-битную субдискретизацию цветности 4:2:2, h264 имеет 8-битную и 4:2:0, если вы не кодируете в профиле Hi422P Intra. который не очень хорошо поддерживается в дикой природе, но предлагает 10 бит и 4: 2: 2. Так что в этом случае я не думаю, что у вас будет какая-то разница между двумя форматами, кроме лучшей степени сжатия, чем в ProRes.

Э: Если вы хотите по-настоящему пошалить, вы также можете кодировать во внутреннем профиле 4:4:4, который поддерживает глубину цвета до 14 бит. Так что технически превосходит ProRes4444. Хотя вы, вероятно, не найдете ни одного коммерческого приложения, поддерживающего это.

С другой стороны, я не думаю, что доставка контента для кино должна выполняться в формате h264 или ProRes 422, особенно если вы планируете впоследствии кодировать в кодек без потерь (JPEG2000/DCP). Это просто не имеет особого смысла, все, что вы теряете, это качество, хотя в этом нет необходимости, вы только экономите место, пока не закодируете свой DCP. Есть и другие хорошие кодеки без потерь, которые предлагают очень хорошее сжатие, которые можно использовать перед кодированием DCP.

Например, вы можете перейти непосредственно к DCP, Adobe Media Encoder предлагает экспорт в 2k DCP, начиная с CC 2014, вы можете пропустить этап кодирования и использовать кодек без потерь с очень хорошей степенью сжатия.

Еще одним отличным промежуточным кодеком является UtVideo , а также Schrödinger (реализация кодека Dirac от BBC, он доступен через FFmpeg ).

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

Кто-нибудь проводил или видел тесты, сравнивающие Apple ProRes 422 с высокобитрейтным H.264?

Нет, но я могу сказать вам, что x264 может быть настолько близок к без потерь, насколько вы хотите (или даже математически без потерь, с -qp 0). x264 может создавать потоки H.264 в цветовых пространствах YUV 4:2:0, 4:2:2 или 4:4:4 с 8 или 10 битами на компонент. (Он также может работать с RGB, но если вы не работаете без потерь, вы, вероятно, получите лучшее качество на битрейт от YUV.)

Поддержка декодеров для всего, кроме 4:2:0 8bit, не так широко распространена. (например, видеокарты имеют аппаратные декодеры, которые могут ускорять только 4:2:0 8 бит).

Обратите внимание, что x264 должен быть скомпилирован либо для 8-битного, либо для 10-битного вывода. Вам нужна отдельная сборка libx264 (или отдельная статическая сборка ffmpeg) для 8-битной и 10-битной версии. Любой из них может обрабатывать любую входную битовую глубину, которую вы хотите добавить, но всегда будет выводить битовую глубину, для которой он был скомпилирован.

Профиль Hi444PP h.264 поддерживает глубину до 14 бит для работы с потерями или без потерь, но x264 по-прежнему поддерживает только 8 или 10 бит. (Также 9-битный, если вы скомпилируете его с битовой глубиной = 9, но в этом действительно нет смысла. Удар по скорости наступает, как только вы выходите за пределы 8)

Кстати, даже если ваш ввод 8-битный, а ваш окончательный дисплей - 8-битный RGB, 10-битный h.264 выглядит лучше для того же битрейта. 8-битный h.264 — это компромисс между скоростью и качеством. (и, очевидно, совместимость с декодером.) Google должен найти несколько тем на doom9 и PDF-файл от ateme, чтобы подтвердить это утверждение.

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

Нам интересно, можно ли достичь надлежащего качества с H.264. Скажем, с битрейтом 50-100 Мбит/с и настройкой размера/структуры GOP. (Например, используя только фреймы «I».)

Увеличение количества I-кадров или только I-кадров НЕ повышает качество. Кодировщики h.264 «знают», чем их выходные данные отличаются от входных, и будут использовать макроблоки I там, где они предпочтительнее.

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

Если поиск вообще не вызывает беспокойства, вы можете установить keyint=1000, и тогда x264 сможет использовать GOP почти столько, сколько захочет. (Распознавание сцен включено во всех пресетах, кроме сверхбыстрых, поэтому x264 будет использовать IDR (ключевой кадр) каждый раз, когда вырезка сцены делает I-кадр хорошей идеей.)

Обновление 2: я провел еще несколько тестов ... с Adobe Media Encoder, используя MPEG2 и профиль «4: 2: 2», файл ProRes увеличился с 1920 МБ до 290 МБ! И я бы сказал, субъективно, что на 99% так же хорошо. Это замечательно. (С H264 у меня было 500-700 МБ)

Если вы получили такие же хорошие результаты с MPEG2, вы должны легко получить файлы даже меньшего размера с приличным кодировщиком h.264. Ваш контент, вероятно, довольно хорошо сжимается (низкая зернистость, некоторые области с большим сходством).

Если у вас есть вход в файл, который может прочитать ffmpeg (т.е. почти любой формат),

ffmpeg -i in.mp4 -c:a copy -c:v libx264 -preset medium -tune film -crf 10 -movflags +faststart out.mp4

CRF 10 намного превосходит визуальные потери. По умолчанию ffmpeg использует то же цветовое пространство, что и входное, если выходной кодек поддерживает его. Если ваш ввод 4:4:4, но вы хотите подвыборку цветности, используйте что-то вроде:

ffmpeg -i in ... -sws-flags lanczos+print_info -pix_fmt yuv422p  out
...
[swscaler @ 0x33be0c0] Lanczos scaler, from rgb24 to yuv422p using MMXEXT

Обновление 1: как технически «проверить» разницу? Или измерить информацию о цвете?

Измерить глубину цвета на выходе? может быть, с медиаинфо .

Чтобы сравнить качество различных кодировок одного и того же источника, измерьте SSIM или PSNR каждого кодирования относительно источника. x264 может измерять обе эти метрики в процессе кодирования. Есть и другие инструменты для сравнения двух уже сделанных видеофайлов, измерения этих показателей качества, но я ими не пользовался.

Для ffmpeg используйте -ssim 1 -psnr -tune ssim. (Не используйте -tune ssim, кроме как для сравнения этой метрики. По умолчанию она включает психовизуальную оптимизацию, которая дает результаты, которые лучше выглядят для человека, но математически менее похожи в соответствии с этой метрикой.)

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

Чтобы проверить отсутствие потерь, вы можете использовать -f framemd5кодек ffmpeg, чтобы убедиться, что h.264 декодирует биты, идентичные входным данным. (см. этот вопрос для примера. Убедитесь, что вы используете один и тот же -pix_fmt для всех тестов, потому что разные декодеры могут по-разному упаковывать одни и те же данные.)

О, только что прочитал ответ профессора Спарклза. Не понял, что вы в конечном итоге выводили без потерь. Вы просто стреляете себе в ногу, если по пути используете какие-либо кодеки с потерями. Кодек без потерь должен будет кодировать все невидимые артефакты блокировки/звонка, оставленные кодеками с потерями, поэтому вы, как правило, получаете файлы большего размера из кодека без потерь, если вводите в него входные данные, прошедшие через кодек с потерями, а не исходный источник.

Так что, если вы хотите использовать h.264, используйте без потерь. ( ffmpeg -i in -preset ultrafast -qp 0 out). (более медленные предустановки дают лишь незначительное улучшение сжатия для без потерь. Однако никогда не используйте сверхбыстрое для чего-либо, кроме без потерь.)