Просмотр и конвертация HEVC (h265) bt2020 10 bit в h264 8 bit

[Жрец Нефтиды]

Предположим, откуда-либо к нам приплыл файл, сжатый кодеком 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. Тогда уместно заняться конвертированием. О конвертировании я напишу в следующем посту.

[Жрец Нефтиды]

Задача: конвертировать HEVC (h265) bt2020 10 bit в привычный h264 bt709 8 bit таким методом, чтобы конвертант максимально точно соответствовал оригиналу.
Замечу, что на сегодняшний день я не считаю h264 устаревшим, и если приходится пережимать, то жму только в него. Бесполезно (пока) просить меня помочь конвертировать в h265.
Всё, изложенное здесь, идеально работает на Windows. Не знаю, сработает ли на Пингвине.
Поехали.
При помощи mkvtoolnix-gui, который я называю "матрёшечник", создаём файл, в котором только одна видео дорожка. Назовём его 11.mkv.
Казалось бы, для декодирования на поверхности лежит способ, описанный мною ещё в теме про XVID, а именно, через скрип Ависинта:
LoadPlugin("ffms2.dll")
LoadPlugin("SplineResize.dll")
FFVideoSource("11.mkv", fpsnum=24000, fpsden=1001)
assumefps(24000,1001)
Spline144Resize(1920, 1080)
Но не прокатит. Да, ffms2.dll лихо декодирует HEVC. На том сочтёт свою миссию выполненной. А в степень возводить Марина Цветаева будет? В результате конвертант получится блёклым. По этой же причине не прокатит такой простенький бат-файл:
ffmpeg.exe -i 11.mkv -vf scale=1920:1080:flags=bicubic,format=yuv420p
(Параметры кодирования я в нём не записал.)
Делаем так.
Скачиваем последний официальный релиз ffmpeg.exe. Желательно отсюда, здесь есть и 32-х битные релизы:
[Для просмотра данной ссылки нужно зарегистрироваться]
Скачиваем обязательно статическую версию!
В одной папке располагаем bat-файл, 11.mkv и ffmpeg.exe.
bat-файл пишем так:
ffmpeg.exe -i 11.mkv -vf format=yuv420p16,zscale=dither=none:primaries=709: transfer=709:matrix=709:npl=100:w=1920:h=1080:filt er=spline36,colorspace=all=bt709:iall=bt709:format =yuv420p:dither=none -aspect 16:9 -codec:v libx264 -x264-params qp=16:no-deblock=1:ipratio=1:pbratio=1:no-psy=1:no-fast-pskip=1:no-dct-decimate=1:deadzone-inter=0:deadzone-intra=0:subme=9:colorprim=bt709:transfer=bt709:col ormatrix=bt709:level=4.1 01.mkv
pause
Подробное объяснение параметров на русском языке.
Если какие-либо описанные ниже параметры представлены в Медиаинфо, то их название здесь будет соответствовать названию в официальном русском интерфейсе Медиаинфо.
-i 11.mkv имя входного файла
-vf Эта команда указывает, что дальше последуют видео фильтры. Видео фильтры – это не опции. Это именно видео фильтры. В какой последовательности ты их напишешь, в такой они и будут применены для обработки видео. Поэтому принципиально важно написать их в нужной последовательности. Один видео фильтр отделяется от другого запятой. У видео фильтра могут быть параметры, они же опции, одна или несколько. Если у фильтра есть опции, то формат записи таков. После имени фильтра пишется знак равенства. После знака равенства пишется имя опции, дальше снова знак равенства, после него значение опции. Если количество опций больше одной, то после значения первой опции ставится двоеточие, далее снова опция=значение, и так далее. Вот опции можно записывать в любой последовательности.
Когда мы напишем команду с дефисом впереди, это будет значить, что видео фильтры закончились.
format=yuv420p16 Поднимаем битность до 16. Само по себе это не улучшает и не ухудшает видео. Данное действие может показаться странным. Но в нём заложен глубокий жреческий смысл: мы заставим компьютер производить вычисления с максимальной точностью. Особенно актуальным это будет для альтернативного варианта, когда пропишем гамма-коррекцию. Округление до 8 бит будет производиться в самом конце, перед подачей видео на кодер. Начинать обработку с повышения битности до 16 можно считать признаком хорошего тона.
zscale= Запускаем видео фильтр zscale с множеством опций.
Перед началом конвертирования исследуй 11.mkv Медиаинфо. В списке обязательно должны быть три значения: "Основные цвета" ("Color primaries"), "Характеристики трансфера" ("Transfer characteristics") и "Коэффициенты матрицы" ("Matrix coefficients"). Если они есть – а, скорее всего, так и будет, – то используешь прикреплённый bat-файл, как он есть. Если Медиаинфо не показывает этих значений, то в опции zscale нужно дописать ещё три опции:
primariesin=2020 Для входного потока задаём "Основные цвета" – "BT.2020". Только задаём, ничего не преобразуя.
transferin=smpte2084 Для входного потока задаём трансфер, который в Медиаинфо называется PQ (Perceptual Quantizer). Вот так, немножко необычно. Только задаём, ничего не преобразуя.
matrixin=2020_ncl Для входного потока задаём "Коэффициенты матрицы" – "BT.2020 non-constant". Только задаём, ничего не преобразуя.
Рассматриваем остальные опции.
dither=none Отключить добавления зерна. По умолчанию и так отключено, но подстрахуемся.
primaries=709 Основные цвета преобразуем в bt709. В руководстве к этому фильтру написано, что значение опции записывается "709" (а не "bt709"). Поэтому так и пишем.
transfer=709 Трансфер преобразуем в bt709.
matrix=709 Коэффициенты матрицы преобразуем в bt709.
npl=100 Объяснено в первом посту. Если мы зададим npl больше 100, например, 400, то это будет значить, что мы пытаемся загнать 400 нит в математическую модель, рассчитанную на 100 нит. В результате получим тёмную картинку. Если мы зададим npl меньше 100, например, 50, то получим ядовито-яркие цвета.
Замечу, что я нигде, даже на англоязычных ресурсах, не нашёл хорошего объяснения опции npl. Наш форум лучший.
w=1920 Ширина в пикселях выходящего кадра.
h=1080 Высота в пикселях выходящего кадра.
Все помнят, что ресайз уместен только в сторону уменьшения размера.
filter=spline36 Алгоритм ресайза. Пожалуй, самый лучший.
Что лучше: вначале трансформировать цвета, а потом произвести ресайз, или наоборот? Однозначно я не берусь ответить на этот вопрос. Мы могли бы принудительно задать последовательность этих действий, написав два фильтра zscale. Но мне представляется разумным предоставить самому фильтру возможность решать, в какой последовательности что делать. Поэтому я единым махом записал и трансформацию цветов, и ресайз в опциях фильтра. Будем считать, что программисты фильтра умные.
Запятую видишь? Это значит, что видео фильтр zscale закончил свою работу.
До сих пор мы шли на 16 битах.
colorspace=all=bt709:iall=bt709:format=yuv420p:dit her=none При помощи фильтра colorspace трансформируем 16-ти битный формат в стандартный формат yuv420p, работающий на восьми битах. Здесь как раз и происходит понижение битности до 8. В этом фильтре bt никак не изменяется, так как all и iall мы задали одинаковыми. Изменяется здесь только формат. Почему бы просто не написать format=yuv420p ? Мои тонкие исследования показали, что если мы так просто напишем, то при пересчёте битности дробь будет округляться до целого всегда в меньшую сторону, то есть простым отбрасыванием десятичной части. В фильтре же colorspace округление до целого производится по законам математики, то есть 0.5 и больше округляется в большую сторону. (В самом начале bat-файла битность мы поднимали, там можно было написать просто format= .)
Видео фильтры закончились.
-aspect 16:9 Задаём видимое соотношение сторон. В данном примере оно и так 16:9, но в другом случае видимое соотношение сторон может и не соответствовать пиксельному соотношению сторон.
С классическим математически точным декодированием закончено. Прежде, чем пойти дальше, минута отдыха. Я просмотрел очень много форумов на эту тему, и русскоязычных, и англоязычных. И почувствовал себя астролётчиком, прилетевшим с планеты Фрина на планету парадоксов. Количество советов, позволяющих получить правильную цветовую гамму, можно пересчитать по пальцам одной руки. Причём все они повторяют один другого: вначале идёт фильтр линеаризации, то есть значения заменяются приближёнными, само же преобразование в 709 выполняется там ещё в два фильтра. Какая погрешность набежит? Конструкции, предлагаемой мной, где одним фильтром производится трансформация, я не обнаружил нигде. Теперь, возможно, такие конструкции появятся. На здоровье, только большое пожалуйста – со ссылкой на сюда. Наш форум лучший!
Однако!
Делая всё, как описано у меня здесь, мы получим видео, у которого на светлых участках мелкие детали засвечены, а на тёмных – затемнены. Это не очень заметно, но при покадровом просмотре можно отследить. Издержки преобразования стандарта, отличающегося от bt709. Нам предстоит решить двуединую задачу: понизить яркость ярких участков и поднять яркость тёмных участков. Есть красивый выход. Задаём npl=200. Видео станет более тёмным. Засветка деталей на ярких участках исчезнет. Тёмные детали подсветим гамма-коррекцией. При этом гамма-коррекция должна идти непременно после фильтра zscale (а не до него). Гамму прописываем через фильтр lut (фильтр eq не используем, он понижает битность до 8).
Есть две принципиально разные гамма-коррекции, хоть и похожие по конечному визуальному результату: 1. Возвести в степень планар яркости. 2. Разжать планарный формат до RGB и возвести в степень каналы R, G и B. Второй подход мне представляется более правильным, его и будем использовать.
Поскольку здесь мы будем и выполнять ресайз, и разжимать до RGB, то в самом начале bat-файла не только поднимем битность до 16, но и превратим формат 420 в 444. Вот здесь мы столкнёмся с тонкостью, описание которой я не нашёл во всей великой Сети. Если фильтром format мы будем только поднимать битность, то битность поднимется, а информационная наполненность видео не изменится. Но если фильтром format мы будем преобразовывать формат 420 в 444, то, кроме смены формата, будет ещё и производиться дизеринг. Поэтому для преобразования 420 в 444 будем использовать colorspace.
Смотрим прилагаемый bat-файл. В самом первом фильтре там прописано "bt709". Это не ошибка жреца. Именно при такой записи фильтр colorspace будет только преобразовывать 420 в 444 и поднимать битность до 12, и ничего больше делать не будет. Что нам и нужно. Если бы мы написали "bt2020", то видео было бы подвергнуто некоторой обработке. Увы, 16 в colorspace нет. Поэтому в следующем фильтре мы только поднимаем битность до 16 – тут дизеринга не будет.
Записав в первом фильтре "bt709", мы "навесили ярлык" на видео, что оно bt709. Реально никаких изменений не произвели. (Вспоминаем басню про льва и ярлык.) Поэтому в фильтре zscale мы явно указываем в опциях параметры входного видео.
Когда yuv444p16 будет преобразовываться в rgb48 фильтром format, то тут дизеринга тоже не будет.
Значение gamma=0.78 я получил эмпирически.
Вот здесь мы подошли к сильному преимуществу предлагаемого мной bat-файла. При гамма-коррекции мы возводим в степень 16-ти битное видео. (На самом деле здесь возводятся в степень десятичные числа от 0 до 1, представляющие из себя относительные значения яркости каналов r, g и b, после чего относительные значения яркости переводятся в абсолютные целочисленные значения.) Целочисленные деления у 16-ти битного видео расположены в 256 раз чаще, чем у 8-битного. Поэтому когда мы перейдём к 8-битному, то выбывания целочисленных значений на шкале 0-255 не будет. То есть конвертант будет смотреться на 8-ми битном мониторе лучше, чем если бы мы просматривали на этом же 8-ми битном мониторе непосредственно исходник.
Таким образом, мы встали перед сложной дилеммой: либо произвести конвертацию математически точно, но получить результат, не на сто процентов радующий глаз, либо слегка отойти от математической точности, но получить приятное для просмотра видео. Я выбираю второе.
Прилагаю архив с двумя гарантированно работающими bat-файлами: для математически точного результата и для результата, радующего глаза. Выбирай.
Если нужно, чтобы bat-файл перезаписывал уже существующий конечный файл с таким же именем без дополнительного вопроса, то после ffmpeg.exe нужно записать -y
В следующем посту разберём опции кодирования и оставшиеся тонкости.

[Жрец Нефтиды]

Почему-то в прошлом посту bat-файл получился с пробелами, видимо, особенности устройства сайта, пока не знаю, как исправить.
Прикреплённые bat-файлы точно правильные, используй их.

[aleks_nsk]

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

[Жрец Нефтиды]

Файлы и фильмы в таком формате уже стали появляться. Я не говорю, что их много, пока что единицы. Но лучше заранее быть готовым к их конвертированию в нечто привычное.
Например, появился "Спартак" 60-го года в вышеуказанном формате с большим количеством переводов от разных студий, весит под 100 гигов, разрешение 3840x2160. Мой древнеегипетский процессор не успевает декодировать такую махину в реальном времени, да и разрешение 3840x2160 для монитора 1920x1080 ни к чему. После конвертации получил фильм с семью разными переводами, включая дубляж. Этот конвертант, имхо-визуально, смотрится лучше, чем HD с одним закадровым переводом.
Что-то мне подсказывает, что фильмов в таком формате будет становиться всё больше.

[Жрец Нефтиды]

Кодирование.
-codec:v libx264 Кодировать видео будем в h264 при помощи libx264
-x264-params Эта команда указывает, что сейчас мы зададим опции кодирования в h264. Опции пишутся в любой последовательности, одна опция от другой отделяется двоеточием.
Обрати внимание, что мы не используем пресеты, а сами, осознанно, задаём все опции.
qp=16 Кодирование всех кадров на постоянном квантизёре. 16 – это такое значение квантизёра, при котором найти различия между подаваемым и закодированным изображением я не смог даже при покадровом очень внимательном рассматривании монитора. Если нужно получить видео вообще без потерь, то qp=0
Остальные опции описаны в теме сравнения h264 и XViD. Чтобы не грузиться чтением, их суть: мы полностью отключаем психовизуальную обработку и все другие виды обработок, которые хоть как-то упрощают изображение в угоду уменьшения конечного объёма. Мой незыблемый постулат – все детали, которые есть в исходнике, включая самые мелкие и незначительные, непременно должны быть и в конвертанте. Компьютерная программа не может решать за Человека, что для него важно, а что нет.
При таких опциях объём конечного файла будет большим и непредсказуемым. Это даже хорошо: тебя, возможно, будут встречать музыкой и аплодисментами в компьютерных магазинах, приторговывающих внешними USB-дисками.
:colorprim=bt709:transfer=bt709:colormatrix=bt709 Записать в заголовке конечного файла информацию об основных цветах, трансфере и коэффициентах матрицы. Даная информация может потребоваться плееру для правильного воспроизведения. На собственно кодирование эти опции не влияют. Если мы посмотрим через Медиаинфо на файл фильма классического блюрея, то увидим, что там эта информация есть. Пусть и у нас будет.
Обычно кодер h264 сам задаёт нужный уровень. Но мы его можем увеличить, добавив ещё одну опцию. Например: level=4.1
01.mkv Выходной файл. Любители монтажа могут заменить .mkv на mp4, качество видео от этого не изменится.
Запускаем батник. Если ты всё сделал правильно, то в сообщениях, выводимых батником, не должно быть текста красного или жёлтого цвета. Текст бирюзового цвета будет, это нормально.
Конвертация продлится долго или очень долго. Для длинного фильма это могут быть сутки и даже более. Зато качество будет отличным без всякого "или".
Во время этой геркулесовой работы рекомендую запустить бесплатный индикатор CPUID HWMonitor или Core Temp, и периодически посматривать на температуру процессора.
Конвертирование закончилось. При помощи матрёшечника присоединяем одну или несколько звуковых дорожек.
Если тебе непременно нужен контейнер mp4, то делаем так. Собранную матрёшку открываем в XMedia Recode, и перекидываем без пережатия в контейнер mp4, там есть такой формат MP4 (stream copy). XMedia Recode можно заменить Авидемюксом.
Вроде всё.