Предположим, откуда-либо к нам приплыл файл, сжатый кодеком HEVC, он же кодек h265, и Медиаинфо показало "Основные цвета" – "BT.2020", "Коэффициенты матрицы" – "BT.2020 non-constant", и "Характеристики трансфера" – "PQ" (Perceptual Quantizer). Некоторые фильмы сейчас можно найти в таком формате, например, "Спартак" 1960-го года.
Важно понимать, что все описанные в этой теме трудности и их успешное разрешение имеют место не собственно от кодека h265 – это просто кодек, и не от 10 бит. Проблемы создают трансфер "PQ", основные цвета и непостоянные коэффициенты матрицы! Далее я буду сокращённо называть форматом bt2020 то видео, у которого "Основные цвета" – "BT.2020", "Коэффициенты матрицы" – "BT.2020 non-constant", и "Характеристики трансфера" – "PQ".
Формат bt2020 отличается от bt709 и bt601. Когда нам нужно было преобразовать, например, bt709 в bt601, то достаточно было подставить коэффициенты, то есть произвести линейное преобразование. Совсем по-другому обстоят дела с bt2020. Можно сказать, что bt2020 – это стандарт, рассчитанный на определённое "железо".
Предположим, у меня (или у тебя) есть старый монитор SDR (Standard Dynamic Range) 8 bit. Слово "старый" я взял в кавычки: например, мой "Панасоник" Full HD, которому 10 лет, за эти годы совсем не утратил цветопередающие способности, и выкидывать его я не собираюсь. Да, в плеере BE можно включить встроенный декодер HEVC, и показывать-то BE будет без проблем. Без проблем, кроме одной: видео будет блёклое.
Задача: просмотреть bt2020 на "старом" мониторе и конвертировать bt2020 в h264 для просмотра на "старом" мониторе.
Я не буду в этой теме читать морали, а зачем же было скачивать bt2020, если у тебя монитор SDR rec709 8 bit. Я не буду рассуждать, насколько HDR по глазным ощущениям отображает картинку лучше, чем SDR. Я не буду советовать купить более современный монитор, или, наоборот, остаться на SDR. И вас прошу этого не делать. Здесь мы подробно разберём, как решить поставленную задачу: максимально точно, насколько это возможно, воспроизвести десятибитное видео bt2020 с указанными выше характеристиками на восьмибитном мониторе SDR rec709. А также научимся конвертировать bt2020 в привычный стандарт bt709.
Перед тем, как мы перейдём к практическим действиям, нам нужно осознать отличие стандарта bt2020 от bt709 и теорию преобразования bt2020 в bt709. Без знания теории мы, скорее всего, будем терпеть фиаско. Научным языком теория объяснена, например, в статье
[Для просмотра данной ссылки нужно зарегистрироваться] Можешь прочитать, а можешь и не читать. Похоже, что это перевод с английского, так что есть смысл скачать и английский вариант. Я же покажу всю эту кухню на простом примере. Как сказал Эйнштейн, "Если вы не можете объяснить это простыми словами, вы не до конца это понимаете".
Первое, и самое простое, отличие монитора bt2020 10 bit от "старого" монитора налицо: десять бит. То есть больше точность. Но есть и второе, гораздо более сложное, отличие.
Перед нами стоит монитор (в статье он называется дисплеем) rec2020 10 bit. Допустим, на данном кадре на красную составляющую какого-либо пикселя подаётся сигнал величиной 783. Относительная величина яркости E=783/1023=0,765. Рядом стоит "старый" монитор rec709 8 bit. Нам нужно, чтобы красная составляющая пикселя этого "старого" монитора светилась примерно с такой же яркостью, как и красная составляющая монитора rec2020. Используя терминологию статьи, эту идею можно описать такой фразой: "если цель заключается в сохранении цветов, видимых на дисплее rec2020, при отображении на дисплее rec709…"
Считаем. E*255=195 ?
А вот и не правильно! Вначале относительную яркость нужно возвести в степень (1/2,4). То есть 0,765**(1/2.4)*255=228 Такое преобразование называется нелинейно-линейное.
Это ещё не всё. Существует понятие "пиковая номинальная яркость", она же "пиковая яркость", она же "максимальная яркость". В английском варианте эта величина называется "nominal peak luminance". Когда мы подойдём к конвертированию, данную величину мы будем задавать опцией npl. В других кодерах и в плеере она может обозначаться по-другому.
Для стандарта SDR пиковая номинальная яркость равна 100. То есть npl=100 нит. Это прописано в самом стандарте SDR. Для "нового" монитора rec2020, работающего, например, по стандарту HDR, эта величина будет больше. Величина npl тоже входит в преобразование. И трансфер входит в преобразование. И непостоянные коэффициенты матрицы. Не будем дальше грузиться математикой, для практики это не важно.
К чему же мы подошли? К тому, что невозможно системой из трёх линейных уравнений перекинуть bt2020 с трансфером "PQ" в bt709. Для этой цели нужны более серьёзные математические преобразования. Но не плачь, когда дочитаешь до конца, поймёшь, что на практике всё очень просто.
Теперь возьми лист бумаги, нарисуй квадрат, а в нём график Y=X**(1/2.4). Ты увидишь, что этот график довольно сильно изогнут. То есть когда относительная яркость E входного стандарта bt2020 близка к нулю, то небольшое её изменение приводит к значительным изменениям относительной яркости выходного стандарта bt709. Но ведь на входе у нас 10 бит, на выходе, в конечном счёте, 8 бит. Шкала X оказывается проградуирована более мелкими делениями, чем шкала Y. К чему я это всё говорю? Шевелим древнеегипетской мозговой извилиной. Какая последовательность действий лучше для максимально точной передачи изображения и для того, чтобы минимизировать бандинг: вначале понизить битность до 8, и потом произвести нелинейно-линейное преобразование, или вначале произвести нелинейно-линейное преобразование, а потом понизить битность? Шевелим, шевелим. Так вот, гораздо лучше вначале произвести нелинейно-линейное преобразование, и ресайз, если он нужен, а в самом конце, перед подачей на кодер, понизить битность. Запомним эту важную мысль.
С теорией всё. Переходим к практике.
Из бесплатных в очередной раз лучшим оказался плеер BE.
Первый способ.
Обязательно нужно задать Видео-рендерер "Exchanged Video Renderer (custom parameter)". "Формат текстуры" в нём – 10-bit Integer. Зачем 10, когда у древнеегипетского монитора 8? А затем, чтобы всё было максимально точно обработано на 10, и уже потом, при подаче на монитор, было понижено до 8. Впрочем, если задашь в настройках 8, то вряд ли на глаз увидишь разницу по отношению к 10. Декодирование ведём кодеком LAV. В нём включаем HEVC, а птицу в LAV ставим только у формата "YV12".
Второй способ. LAV не потребуется. Также задаём Видео-рендерер "Exchanged Video Renderer (custom parameter)". Декодируем встроенным в BE декодером: "Встроенные фильтры" – "Видео декодеры" – птица у HEVC. Но в этом способе также ещё надо "Настройка видео декодера" – ставим птицу у "YV12". Если ты не выполнишь какое-либо из этих условий, то видео может получиться блёклое. Попробуй.
Обязательно перезапусти плеер BE, и наслаждайся.
Лично мне первый способ нравится больше.
Изображение будет тёмноватое. Плеер делает изображение тёмным очень даже с того и с сего: иначе на светлых участках кадра будут засвечены детали. Чтобы подсветить тёмные детали и не засветить светлые, нужна гамма-коррекция. К сожалению, в BE нет встроенного гамма-корректора. Поэтому используем Gamma Panel 1.0.0 (build 20) – он, имхо, лучший. Комфортное значение гаммы будет примерно 1,4. Гамма-коррекция – действие с потерями. Чем больше отстоит гамма от 1, тем больше выбывает целочисленных значений на восьмибитной шкале 0-255. В Gamma Panel есть показатель LUT – это максимально возможное количество различных цветов, которые могут быть воспроизведены при данном значении гамма. Очень полезный индикатор. Но исходник-то у нас 10 бит. Когда будем говорить о конвертации, я покажу, как можно избежать выбывания значений при гамма-коррекции.
Увы, HEVC – кодек ресурсозатратный. Скорости твоего (ну хорошо, моего) древнеегипетского процессора может не хватить для декодирования с заданной частотой кадров. Особенно если исходник имеет разрешение 3840x2160. Тогда уместно заняться конвертированием. О конвертировании я напишу в следующем посту.