Как указать параметры качества CRF для различных программ кодирования

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

Я пытаюсь помочь коллеге создать спецификацию для внешних подрядчиков, когда они доставляют нам видео для использования на нашем веб-сайте в виде файлов mp4 со сжатием h.264. Мы можем указать битрейт, но это не так хорошо работает, если нам нужно сжатие с переменным битрейтом и постоянным качеством (CRF).

Если бы я знал, что они будут использовать libx264 для сжатия, я мог бы дать им диапазон для -crfнастройки, но они будут использовать все виды программного обеспечения для сжатия. Итак, как мне указать качество, кроме как сказать что-то расплывчатое, например, «визуально без потерь» или «хорошее качество»?

Для VBR нельзя указать и средний битрейт, и уровень качества (по сути, минимальный битрейт)? Если вам нужно достичь определенной цели, возможно, вам придется использовать CBR.
Это будет сложно, потому что не все кодировщики одинаковы, и даже «профессионалы в области видео» не всегда знают, что они делают, поэтому ваши результаты, вероятно, будут сильно различаться. Можете ли вы потребовать промежуточный формат без потерь (или приемлемого качества с потерями) и перекодировать его в соответствии с вашими требованиями?
Это то, что я предлагал. Мне никогда не приходилось связываться с подрядчиком, чтобы заставить его поставить мне mp4, потому что у меня есть только мастер-файл ProRes, но обратное довольно распространено.
Но в качестве академического упражнения, подойдет ли указание профиля + уровня? Я обычно кодирую основной профиль для совместимости, могу ли я указать уровень 3 или выше?
Это зависит от устройств, которые вы хотите поддерживать, если видео передается напрямую от подрядчика к клиенту, и могут встречаться ограничения уровня в зависимости от выбранного уровня и параметров вывода (пример. См. предупреждения в: ffmpeg -f lavfi -i testsrc=s=hd720:d=5,format=yuv420p -c:v libx264 -level 3 output.mp4)
Я явно использую профиль и уровень только в том случае, если это требуется устройству воспроизведения. В противном случае я просто позволяю x264выбирать.
Профиль и уровень будут такими же, как указание битрейта, с дополнительными ограничениями на rez/fps и на ref-кадры. Кроме того, из любви к науке заставьте людей использовать высокий профиль, если вы действительно не хотите, чтобы видео воспроизводилось на дрянных старых телефонах или других аппаратных проигрывателях. 8x8dct очень помогает, особенно. в HD рез. (Однако это, вероятно, меньше помогает при очень высоких битрейтах, поэтому для мастеров с очень очень высокими битрейтами это, возможно, не так сильно теряет качество.)
Кроме того, уровень — это всего лишь верхняя граница битрейта. Установка предела уровня для x264 просто гарантирует, что он не превысит его; Это не говорит ему, что вы хотите максимально увеличить битрейт в пределах этого уровня. Я предполагаю, что другие кодировщики будут иметь настройку уровня отдельно от целей качества / битрейта.

Ответы (1)

Любой приличный кодировщик может достичь целевого битрейта (с 2-проходным), но при этом разумно расходовать биты для достижения одинакового качества во всем файле. x264 2pass выясняет, какой CRF даст нужный битрейт (pass1), а затем использует его (pass2). (источник: Dark Shikari. ср. ссылки, которые я откопал для своего ответа на этот вопрос о потоковой передаче VBR ).

Вы получаете CBR только с x264, если vbv-maxrate= bitrate, и даже тогда это может быть VBR в пределах размера буфера. (h.264 никогда не будет строго CBR, как mp3 или что-то в этом роде, если только ваши I-кадры не будут выглядеть УЖАСНО: P)

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

(Есть ли слово для этого? гибкий битрейт? Кроме целевого качества, в отличие от целевого битрейта. CRF нацелен на эвристику качества, а не строго на цель качества.)

В любом случае, в таком случае я понятия не имею, что поддерживают другие кодировщики. H.264 без потерь, вероятно, лучший формат для отправки файлов. Он значительно меньше, чем huffyuv или utvideo, и может поддерживать до 10 бит. (на самом деле, я думаю, что FFmpeg может декодировать более высокую битовую глубину, но x264 может создавать файлы только до 10 бит.) Или, я думаю, вы могли бы заставить их отправлять вам файлы pro-res с небольшими потерями, если это намного проще для ваших рабочих процессов.

LordNeckBeard поднимает вопрос о том, доставляете ли вы эти файлы напрямую клиентам. Если это так, вам, вероятно, следует потребовать, чтобы они кодировали с помощью x264, по крайней мере, с предустановкой = медленнее, поэтому вы можете просто дать им значение crf, если вам уже требуется x264. Компромисс между скоростью и искажением имеет значение для конечных файлов, которые вы собираетесь транслировать много раз.

О, один независимый от кодировщика прокси для качества - средний квантизатор. Если они используют x264, они могут просто использовать CRF ниже требуемого среднего QP. (пси / AQ оба повышают квантователи, но улучшают воспринимаемое визуальное качество.) x264 с очень низким subme может выглядеть хуже при том же среднем QP (но это тоже влияет на CRF). В любом случае, если вам это нужно, а они НЕ используют x264, им может быть неудобно даже узнать об этом. Декодер h.264 ffmpeg не ведет статистику для печати среднего QP, но может экспортировать QP для каждого кадра, чтобы вы могли использовать файлы -vf codecview.
Если они не используют x264, они могут найти какой-нибудь режим целевого качества, если он есть, или, может быть, режим с фиксированным QP (который, вероятно, будет хуже RD, но, по крайней мере, известного качества). Убедитесь, что вы приложили свои доводы вместе с любым таким требованием. т. е. «средний QP < 14. (Используйте настройку кодировщика, которая выходит далеко за рамки визуально прозрачной, поскольку мы будем перекодировать это. Для x264 crf = 12 было бы идеальным.)» Пока они знают причину вашего правила , они будут знать, что вам важен не фактический QP, а визуальное качество.
Кроме того, nvm codecviewпредназначен для визуализации векторов движения и showinfoне печатает среднее значение QP для каждого кадра. Я просмотрел весь список видеофильтров ffmpeg, и ни один из них не печатает значения QP :/
Спасибо за Ваш ответ. Я думаю, что основная идея заключается в том, что если мы хотим иметь контроль качества нашего веб-видео, мы просим подрядчиков предоставить мастера и выполнить кодирование сами.
Да, если место для хранения мастеров на вашей стороне не является проблемой, НАМНОГО полезнее иметь их. В будущем вы можете вернуться и производить кодирование с другим битрейтом, или с VP9/HEVC, или для разных сценариев потоковой передачи, или делать что-то еще. Или просто измените настройки для новых кодировок, не прося подрядчиков обновить их настройки. Если ваши подрядчики выполняли кодирование, вы всегда можете посмотреть строку настроек x264, которую он встраивает в строку h.264, чтобы убедиться, что они используют достаточно высокое значение subme и другие настройки.