HDR10Plus Tool извлекает динамические метаданные HDR10+ из HEVC в JSON, проверяет их наличие, внедряет JSON обратно в сырой HEVC-поток, удаляет SEI HDR10+, строит PNG-графики яркости и позволяет сдвигать структуру метаданных удалением или дублированием кадров.

Программа рассчитана на точную работу с метаданными SMPTE ST 2094-40, а не на цветокоррекцию изображения. Она не анализирует пиксели, чтобы заново придумать HDR10+ для обычного HDR10-видео, и не заменяет видеокодер: её задача — прочитать уже существующие динамические данные, представить их в понятном JSON, отредактировать привязку к кадрам, удалить либо внедрить соответствующие SEI-сообщения в HEVC.

Практический смысл HDR10Plus Tool лучше всего проявляется в цепочках с FFmpeg, x265, MKVToolNix и программами автоматизации кодирования. Утилита позволяет сохранить HDR10+ при перекодировании, проверить наличие динамических метаданных, подготовить JSON для x265, синхронизировать метаданные после точного изменения начала видеоряда и получить график динамики яркости. При этом особенно важно не путать статические параметры HDR10 — mastering display, MaxCLL и MaxFALL — с покадровыми HDR10+ данными.

Что именно делает HDR10Plus Tool

HDR10Plus Tool работает на уровне закодированного HEVC-потока и структурированных HDR10+ метаданных. В HEVC динамические данные HDR10+ передаются как зарегистрированные ITU-T T.35 сообщения внутри prefix SEI. Утилита умеет найти такие сообщения, разобрать полезную нагрузку ST 2094-40, связать её с кадрами и экспортировать в JSON. Обратная операция берёт JSON и создаёт подходящие SEI NAL units перед срезами видеокадров.

Это принципиально отличается от изменения яркости, тоновой кривой или цветовой гаммы самого изображения. При выполнении extract, inject или remove пиксельные данные кадра не пересчитываются видеокодером. Видеопоток переписывается на уровне NAL units, чтобы динамические сообщения были вынуты, заменены или удалены. Поэтому операция с корректным исходником не является перекодированием изображения и не должна сама по себе менять детализацию, шум, зерно или компрессионные артефакты.

Возможности удобно разделить на пять подкоманд:

• extract — поиск и выгрузка HDR10+ в JSON, одновременно с вычислением информации о сценах;
• inject — внедрение метаданных из JSON в сырой HEVC bitstream;
• remove — удаление HDR10+ сообщений из HEVC;
• plot — построение PNG-графика яркостных данных из HDR10+ JSON;
• editor — удаление диапазонов метаданных и дублирование кадровых записей для синхронизации.

Утилита не предлагает монтажную шкалу, окно предпросмотра или ручное рисование tone mapping curve мышью. Все команды задаются в терминале, а содержимое JSON при необходимости анализируется текстовым редактором или вспомогательными скриптами. Это ограничивает удобство для новичка, но делает программу предсказуемой для пакетных процессов и автоматизации.

HDR10+, ST 2094-40 и роль динамических метаданных

HDR10+ использует динамические метаданные, чтобы устройство воспроизведения получало описание яркостных характеристик материала не только один раз на весь фильм, а по ходу последовательности. В основе лежит SMPTE ST 2094-40, Application #4. Для HEVC эти данные упаковываются в SEI, а заголовочные поля ITU-T T.35 позволяют определить, что полезная нагрузка относится именно к HDR10+.

Практически важно понимать, что HDR10+ не заменяет базовые признаки HDR-потока. Видеоряд по-прежнему кодируется как HEVC Main 10 с соответствующими параметрами цветового пространства и передаточной функции, обычно BT.2020 и PQ. Статические HDR10 сведения, например mastering display metadata и MaxCLL/MaxFALL, остаются отдельными. HDR10Plus Tool занимается динамическим слоем ST 2094-40 и не является редактором всех возможных VUI/SEI параметров HEVC.

В JSON, который экспортирует программа, отражаются параметры HDR10+, связанные с конкретными кадрами: яркостные характеристики, распределения MaxRGB, значения MaxScl, целевая максимальная яркость дисплея и, для профиля с тоновой кривой, данные Bezier. Утилита также формирует индексы сцен, чтобы последовательность можно было использовать в рабочих процессах, ожидающих информацию о границах сцен.

Динамическая природа метаданных объясняет главное требование при переносе JSON между двумя версиями одного материала: кадры должны совпадать по содержанию и порядку. Если одно издание имеет дополнительный логотип, удалённый чёрный кадр, иной монтаж, другую частоту кадров или вставку в начале, метаданные перестают соответствовать изображению с точки рассчёта на конкретный frame index. Простое совпадение длительности в секундах здесь недостаточно.

Чем HDR10+ метаданные не являются

JSON HDR10+ нельзя рассматривать как LUT, универсальную карту яркости или файл, который автоматически улучшает HDR. Он описывает параметры, рассчитанные для конкретной последовательности изображения. Если взять метаданные от другого мастера, другой обрезки или монтажной версии, экран может применять тональное отображение в неподходящий момент. Даже при визуально похожих кадрах такая привязка должна подтверждаться точным сравнением кадров.

По той же причине команда inject не создаёт динамические метаданные из статического HDR10. Если JSON отсутствует, HDR10Plus Tool не выполняет анализ видеокадров и не генерирует creative intent. Для генерации HDR10+ с нуля нужен другой этап производства или инструмент анализа, который рассчитывает метаданные по изображению.

Командная модель и синтаксис

Базовая форма вызова состоит из имени исполняемого файла, глобальных параметров и подкоманды. Для просмотра доступных параметров используется стандартная справка командной строки. Глобальные флаги должны относиться ко всему запуску, тогда как параметры входа, выхода и диапазона кадров принадлежат конкретной подкоманде.

hdr10plus_tool [OPTIONS] <SUBCOMMAND>
hdr10plus_tool extract --help
hdr10plus_tool inject --help
hdr10plus_tool remove --help
hdr10plus_tool plot --help
hdr10plus_tool editor --help

Для многих команд вход можно передать либо позиционным аргументом, либо через -i/--input. Эти варианты взаимоисключающие: достаточно выбрать один стиль и применять его последовательно. Например, два вызова извлечения ниже равнозначны по смыслу:

hdr10plus_tool extract video.hevc -o metadata.json
hdr10plus_tool extract -i video.hevc -o metadata.json

У extract и remove символ - может обозначать поток со стандартного ввода, что удобно для связки с FFmpeg. У inject обработка устроена иначе: внедрение выполняется в сырой HEVC-файл и требует анализировать порядок кадров перед переписыванием потока, поэтому типичный сценарий использует файл на диске.

Если путь содержит пробелы, его нужно заключать в кавычки средствами оболочки. Сам HDR10Plus Tool не вводит специальный синтаксис для Windows-путей или POSIX-путей, но CMD, PowerShell, bash и zsh по-разному интерпретируют кавычки, обратные слэши и конвейер. При переносе готовой команды между оболочками следует проверять именно правила оболочки, а не менять параметры программы.

Проверка наличия HDR10+ через --verify

Глобальный флаг --verify нужен для быстрой проверки того, содержит ли вход динамические HDR10+ метаданные. Его удобно использовать до полного извлечения, особенно для больших файлов, когда нужен только ответ о наличии ST 2094-40. Если подкоманда extract запущена без выходного JSON, программа сама переходит к режиму проверки вместо обязательного полного экспорта.

hdr10plus_tool --verify extract video.hevc
hdr10plus_tool extract video.hevc

При работе с контейнером через FFmpeg типичная цепочка выбирает только нужную видеодорожку и выводит HEVC Annex B в stdout:

ffmpeg -i input.mkv -map 0:v:0 -c copy -bsf:v hevc_mp4toannexb -f hevc - | hdr10plus_tool --verify extract -

Ключевой параметр здесь — -map 0:v:0. В контейнере могут присутствовать вложенные обложки или дополнительные видео-треки; если не выбрать конкретный HEVC-поток, конвейер может передать не тот поток либо несколько потоков, после чего результат проверки становится бессмысленным. Проверка HDR10+ должна выполняться по той видеодорожке, с которой впоследствии будут извлекаться метаданные.

--verify не выполняет полноценную оценку качества HDR10+. Он сообщает о распознавании динамических метаданных. Наличие SEI ещё не доказывает, что значения корректны, что метаданные синхронизированы с монтажом и что конечный плеер отобразит профиль так, как ожидается. Для диагностики этих вопросов нужны извлечение JSON, анализ сцен и проверка итогового файла.

Извлечение HDR10+ в JSON командой extract

extract — центральная команда для сохранения динамических метаданных. Она читает HEVC, находит HDR10+ SEI, сопоставляет сообщения с кадрами, при необходимости приводит их к презентационному порядку и записывает JSON. Одновременно программа вычисляет сведения о сценах, поэтому итоговый файл содержит не только параметры каждого кадра, но и сводку границ сцен.

hdr10plus_tool extract video.hevc -o metadata.json

Для современной версии утилиты входом может быть не только сырой HEVC, но и MKV с HEVC-видеодорожкой. Это сокращает число шагов в простом случае:

hdr10plus_tool extract movie.mkv -o metadata.json

Тем не менее конвейер через FFmpeg остаётся полезным, когда нужно явно выбрать конкретную видеодорожку, предварительно обработать контейнер или встроить извлечение в существующий скрипт:

ffmpeg -i movie.mkv -map 0:v:0 -c copy -bsf:v hevc_mp4toannexb -f hevc - | hdr10plus_tool extract -o metadata.json -

Здесь FFmpeg не должен перекодировать видео: -c copy оставляет HEVC-данные как есть, а битстрим-фильтр переводит поток в формат Annex B, пригодный для последовательного чтения NAL units. На практике важно убедиться, что выбран именно HEVC, а не AV1, VP9 или иной видеокодек. Основная ветка HDR10Plus Tool работает с HDR10+ в HEVC; наличие HDR10+ как стандарта в других кодеках не означает, что конкретная команда сможет их разобрать.

Ограничение числа кадров через --limit

У extract есть параметр -l/--limit, который прекращает обработку после заданного числа кадров. Он полезен для диагностики начала потока, проверки подозрительного фрагмента или ускоренного получения небольшого JSON, когда полный фильм обрабатывать не требуется.

hdr10plus_tool extract video.hevc -o first_frames.json --limit 5000

Такой JSON отражает только обработанный участок и не должен бездумно использоваться для внедрения в полный видеопоток. Если затем передать укороченный список в inject, длина метаданных и видео не совпадёт, и утилита будет вынуждена применить правила компенсации длины. Для окончательного сохранения HDR10+ при перекодировании лучше извлекать полный набор метаданных.

Что происходит с порядком кадров

HEVC может кодировать кадры в порядке, отличающемся от порядка показа. Особенно заметно это при B-frames. HDR10Plus Tool пытается привести извлечённые метаданные к презентационному порядку, чтобы запись с индексом N соответствовала кадру, который зритель видит как N-й. Это важно для последующей передачи JSON в x265 и для корректного сопоставления сцен.

Именно поэтому автоматическая перестановка является нормальным режимом. Отключать её следует только для неправильно авторингованных источников, где HDR10+ SEI уже вставлены в ошибочной последовательности и дополнительное переупорядочивание ухудшит соответствие. Для такого случая существует --skip-reorder.

Когда нужен --skip-reorder и как распознать ошибочный порядок

--skip-reorder — не ускоритель и не универсальный способ починить ошибку. Это обходной режим для редких HEVC-файлов, в которых HDR10+ сообщения были последовательно вставлены в конечный поток без учёта разницы между decode order и presentation order. Если в таком источнике присутствуют B-frames, обычная перестановка может второй раз изменить порядок метаданных и привязать их к другим изображениям.

Признак, который можно проверить после извлечения, — структура SceneInfoSummary. Если список SceneFrameNumbers содержит подозрительно много сцен длиной по 1–3 кадра, а SceneFirstFrameIndex не совпадает с реальными монтажными склейками, метаданные могут находиться в неправильном порядке. При нормальном сценовом анализе соседние кадры одной сцены часто имеют одинаковый набор параметров, поэтому сцены обычно не распадаются на хаотичную последовательность микродиапазонов.

Порядок диагностики лучше строить так:

1. извлечь JSON обычной командой;
2. посмотреть сводку сцен и несколько известных точек монтажных склеек;
3. если сцены явно размазаны или состоят из одиночных кадров, повторить извлечение с --skip-reorder;
4. сравнить соответствие SceneFirstFrameIndex реальным кадрам;
5. использовать тот вариант, где динамические изменения привязаны к показанным кадрам.

Нельзя выбирать режим только по тому, какой JSON меньше или какой график визуально более гладкий. Цель — не косметическая форма данных, а сохранение правильной привязки метаданных к изображению. Если два источника имеют разный монтаж, --skip-reorder сам по себе не синхронизирует их.

Структура JSON, который создаёт программа

Файл HDR10Plus Tool организован в четыре верхнеуровневых блока: JSONInfo, SceneInfo, SceneInfoSummary и ToolInfo. Такая структура позволяет одновременно хранить покадровые значения, сведения о профиле и компактную сводку сцен.

Блок	Назначение	Что обычно содержит
JSONInfo	Общая характеристика набора	HDR10plusProfile, Version
SceneInfo	Основной массив метаданных	Запись для каждого кадра
SceneInfoSummary	Сводка сцен	SceneFirstFrameIndex, SceneFrameNumbers
ToolInfo	Служебная информация	Имя и версия инструмента

Внутри SceneInfo каждая запись получает SequenceFrameIndex, SceneId и SceneFrameIndex. Первый индекс указывает положение в общей последовательности. SceneId увеличивается, когда набор существенных метаданных меняется, а SceneFrameIndex отсчитывает кадры внутри текущей сцены начиная с нуля.

При вычислении сцен программа сравнивает соседние записи. Для Profile B учитывается изменение BezierCurveData; для обоих профилей сравниваются яркостные параметры, число окон и целевая максимальная яркость дисплея. Когда один из значимых блоков отличается, начинается новая сцена. Поэтому сводка сцен строится из самих метаданных, а не из анализа пикселей и не из списка I-frames.

LuminanceParameters

Блок LuminanceParameters включает AverageRGB, MaxScl и распределение яркостных значений. MaxScl содержит три компонента, а массивы DistributionIndex и DistributionValues должны иметь согласованную длину. При обратном преобразовании JSON в HDR10+ программа проверяет, что MaxScl содержит ровно три элемента и что индексы распределения соответствуют значениям.

Числа в JSON не следует интерпретировать как готовые значения для ручной замены без знания масштаба. Для яркостных величин в типичных HDR10+ JSON используется масштабирование, и при построении графика HDR10Plus Tool переводит соответствующие значения в нит, деля их на 10. Поэтому случайное умножение или деление полей может формально сохранить валидный JSON, но радикально изменить смысл динамических данных.

BezierCurveData и профили A/B

Для набора, определённого как Profile B, в JSON присутствует BezierCurveData с точкой колена KneePointX/KneePointY и массивом Anchors. Эти значения описывают творчески заданную тоновую кривую. Для Profile A такой блок отсутствует, и утилита формирует запись без данных Bezier.

Профиль всего JSON определяется на основании записей: если все кадры относятся к B, в HDR10plusProfile будет B; если все относятся к A — A; смешанная или некорректная ситуация не должна механически объявляться одним из нормальных профилей. Это одна из причин не редактировать строку профиля вручную отдельно от самих полей кадров.

Валидация метаданных и --skip-validation

По умолчанию HDR10Plus Tool валидирует распознанные данные на соответствие ожидаемому профилю и ограничениям. Это полезно, потому что наличие T.35 сообщения ещё не гарантирует корректность каждого поля. Если поток содержит значения вне допустимого диапазона или нетипичную комбинацию элементов, стандартная проверка может остановить извлечение или внедрение вместо того, чтобы молча записать сомнительные данные.

Глобальный --skip-validation отключает проверку профильного соответствия. Он нужен как диагностический инструмент для нестандартных или ошибочно авторингованных материалов, когда пользователь сознательно хочет извлечь содержимое SEI и изучить JSON. Пример:

hdr10plus_tool --skip-validation extract video.hevc -o metadata.json

Отключение проверки не делает неправильные значения правильными. Если извлечение работает только с --skip-validation, это сильный сигнал, что источник содержит нестандартные данные. Такой JSON следует анализировать отдельно, а не автоматически передавать в производственную цепочку. При повторном внедрении тот же вопрос валидации также остаётся актуальным.

Особенно осторожно нужно относиться к попыткам нормализовать поля на глаз. Например, высокая величина MaxRGB может быть следствием реально заданных метаданных, ошибки мастеринга или неправильной интерпретации. HDR10Plus Tool не знает художественного намерения и не может по одному подозрительному числу восстановить корректную тональную кривую.

Внедрение JSON в HEVC командой inject

inject принимает сырой HEVC-видеопоток и JSON с HDR10+ метаданными. В отличие от извлечения, где MKV может быть прочитан напрямую, внедрение рассчитано на raw HEVC. Если исходник находится в MKV или MP4, видеодорожку сначала обычно демультиплексируют без перекодирования.

ffmpeg -i input.mkv -map 0:v:0 -c copy -bsf:v hevc_mp4toannexb output.hevc
hdr10plus_tool inject -i output.hevc -j metadata.json -o injected_output.hevc

Внутри операция проходит в два этапа. Сначала программа анализирует HEVC и получает информацию о порядке кадров. Затем переписывает поток, вставляя HDR10+ SEI перед первым slice соответствующего decoded frame. Такая схема нужна, потому что индекс записи в JSON связан с порядком представления, а физические NAL units идут в порядке декодирования.

Если в исходном HEVC уже есть HDR10+ SEI, программа предупреждает, что они будут заменены. При переписывании она удаляет существующее сообщение ST 2094-40 из prefix SEI и вставляет новое, сохраняя другие SEI-сообщения, если они находились в том же NAL unit. Это существенно безопаснее, чем удалять весь prefix SEI целиком: рядом могут существовать другие служебные данные, не относящиеся к HDR10+.

По умолчанию, если -o не указан, используется имя injected_output.hevc. Для автоматизации всё же лучше задавать путь явно, чтобы не перезаписать результат предыдущего задания и не перепутать рабочие файлы.

Почему inject не принимает контейнер как обычный конечный результат

HDR10Plus Tool не является мультиплексором. Результат inject — HEVC elementary stream. Чтобы вернуть его в MKV или MP4 вместе со звуком, субтитрами, главами и вложениями, нужен отдельный этап mux. На нём важно заменить только исходную видеодорожку, не создавая лишнюю вторую видео-дорожку и не теряя нужные дорожки контейнера.

Для MKV это обычно делают средствами MKVToolNix или FFmpeg. Выбор мультиплексора не влияет на содержание HDR10+ SEI внутри HEVC, но ошибочная схема map может привести к тому, что в итоговый контейнер попадёт старый видеопоток вместо нового. Поэтому после mux имеет смысл проверять именно ту дорожку, которая воспроизводится по умолчанию.

Несовпадение длины видео и JSON при inject

Перед внедрением программа сравнивает количество кадров, найденных в HEVC, с числом записей SceneInfo в JSON. Идеальная ситуация — полное совпадение. Если длины различаются, HDR10Plus Tool не скрывает проблему: он печатает предупреждение и выбирает поведение в зависимости от того, какой поток длиннее.

Когда JSON короче видео, метаданные в конце дублируются, чтобы у каждого последующего кадра была запись. На уровне реализации для кадров за пределами массива используется последняя доступная запись. Это позволяет технически закончить переписывание файла, но не означает, что метаданные художественно корректны для добавленного участка.

Когда JSON длиннее видео, лишние записи в конце не используются. Это безопаснее, чем пытаться привязать их к отсутствующим кадрам, однако само предупреждение всё равно указывает на несинхронность источников. Если разница появилась из-за намеренного обрезания хвоста и начало совпадает покадрово, результат может быть ожидаемым. Если причина неизвестна, сначала нужно выяснить, где расходятся последовательности.

Warning: mismatched lengths. video 76277, HDR10+ JSON 80118
Metadata will be skipped at the end to match video length

Наиболее опасный случай — одинаковая общая длина при различии внутри монтажа. Например, из одного источника удалили 24 кадра в начале и добавили 24 других кадра в конце. Число кадров совпадает, предупреждения не будет, но все метаданные после точки изменения окажутся сдвинуты. Поэтому для переноса HDR10+ между релизами нужно сравнивать не только total frames, но и реальные точки синхронизации.

Как проверять синхронизацию до внедрения

Практичный способ — выбрать несколько монтажных склеек в начале, середине и ближе к концу, определить точные номера кадров в обоих источниках и убедиться, что смещение постоянно. Если оно равно, например, 96 кадрам на всём протяжении, JSON можно скорректировать удалением или дублированием соответствующего количества записей. Если смещение меняется по ходу фильма, потребуется несколько операций по разным диапазонам.

Ориентироваться только на секунды недостаточно. Для 23.976 fps одна секунда — не целое число кадров в буквальном математическом смысле, а монтажные версии могут начинаться не ровно на секунду. Разработчик прямо рекомендует определять фактическую кадровую разницу, а не угадывать её по длительности.

Удаление HDR10+ командой remove

remove очищает HEVC от сообщений ST 2094-40 HDR10+, не выполняя декодирование и повторное кодирование изображения. Команда полезна для диагностики поведения телевизора или плеера, подготовки базового HDR10-потока, сравнительного теста и случаев, когда динамические метаданные заведомо ошибочны и их нужно убрать перед дальнейшей обработкой.

hdr10plus_tool remove video.hevc -o hdr10plus_removed_output.hevc

Как и extract, удаление может получать HEVC через стандартный ввод:

ffmpeg -i input.mkv -map 0:v:0 -c copy -bsf:v hevc_mp4toannexb -f hevc - | hdr10plus_tool remove - -o cleaned.hevc

Важная деталь — программа удаляет именно HDR10+ сообщение из SEI, а не должна уничтожать любой prefix SEI целиком. Если внутри одного SEI NAL существуют другие сообщения, они сохраняются при переписывании. Поэтому удаление динамических метаданных не следует путать с тотальным stripping всех служебных данных HEVC.

После remove в видеопотоке могут оставаться статические HDR10 параметры: mastering display metadata, MaxCLL/MaxFALL и VUI. Это ожидаемо. Команда предназначена для HDR10+ ST 2094-40, а не для превращения HDR-видео в SDR и не для удаления всех HDR-признаков.

Зачем временно удалять HDR10+

• проверить, вызвано ли необычное тональное отображение именно динамическими метаданными;
• сравнить поведение одного HEVC-потока с HDR10+ и без него на одном устройстве;
• подготовить поток к повторному внедрению исправленного JSON;
• исключить старые HDR10+ SEI при создании гибридного рабочего файла;
• получить чистую базу для диагностики сторонних анализаторов.

Если изображение выглядит неправильно и после удаления HDR10+, причина может находиться в самом видеосигнале, статических параметрах HDR, цветовом управлении плеера или настройках дисплея. HDR10Plus Tool не может исправить ошибку, которая не связана с динамическими SEI.

Построение графика яркости командой plot

plot читает HDR10+ JSON и создаёт PNG-график, показывающий изменение выбранной оценки пиковой яркости по кадрам. Это один из самых удобных способов быстро увидеть, где происходят резкие изменения метаданных, насколько стабилен материал и нет ли выбросов, которые требуют дополнительной проверки.

hdr10plus_tool plot metadata.json -t "HDR10+ plot" -o hdr10plus_plot.png

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

Для подписи графика применяется -t/--title. Через -s/--start и -e/--end можно ограничить диапазон кадров, причём конечный индекс включается в выборку. Это удобно при разборе конкретной сцены или небольшого участка без построения всего двухчасового фильма.

hdr10plus_tool plot metadata.json -s 12000 -e 18000 -p histogram99 -o scene.png

Источники peak brightness

Параметр -p/--peak-source выбирает способ, которым HDR10Plus Tool получает число для вертикальной оси. Доступны четыре варианта:

Значение	Откуда берётся яркость	Когда полезно
histogram	Максимум из DistributionValues	Общий график по распределению, вариант по умолчанию
histogram99	Последнее значение распределения	Ориентир на верхний процентиль распределения
max-scl	Максимум из трёх MaxScl	Наблюдение максимальной компонентной оценки
max-scl-luminance	Расчёт по трём MaxScl с коэффициентами BT.2020	Сведение компонент к яркостной оценке

Для max-scl-luminance программа использует взвешенную комбинацию R, G и B с коэффициентами, соответствующими BT.2020, затем переводит масштаб данных в нит. Такой график отличается по смыслу от простого выбора максимальной компоненты. Сравнивать два графика следует только понимая, каким источником peak brightness они построены.

У histogram99 используется последнее значение массива распределения, которое в распространённых HDR10+ наборах соответствует верхнему процентилю, часто 99,98 %. Это не тождественно абсолютному максимуму. Разница между histogram и histogram99 может быть информативной, если в сцене присутствуют очень редкие яркие пиксели.

Как читать график без неверных выводов

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

Если после монтажа одна и та же сцена в JSON внезапно получает значения от другой сцены, график может показать резкий скачок в точке рассинхронизации. Однако одинаковая яркость соседних сцен способна скрыть ошибку. Поэтому визуализация дополняет покадровую синхронизацию, а не заменяет её.

Редактор метаданных: удаление и дублирование кадров

Подкоманда editor предназначена не для художественной правки MaxScl или Bezier curve, а для изменения длины и расположения кадровых записей. Она читает исходный HDR10+ JSON и отдельный JSON-конфиг с операциями remove и duplicate. На выходе создаётся новый файл метаданных с пересчитанной структурой сцен.

hdr10plus_tool editor metadata.json -j edits.json -o metadata_modified.json

Простейший конфиг для удаления первых 40 кадров:

{
  "remove": [
    "0-39"
  ]
}

Диапазон включительный: 0-39 означает 40 записей. Это важно при расчётах смещения. Если нужно удалить ровно 24 кадра в начале, диапазон будет 0-23, а не 0-24.

Операции удаления выполняются до дублирования. Это влияет на индексы последующих действий: если конфиг содержит оба типа операции, source и offset для дубликатов следует рассчитывать относительно состояния после удаления.

Дублирование метаданных

Операция duplicate копирует метаданные выбранного кадра и вставляет заданное число записей в нужную позицию. Структура операции содержит source, offset и length:

{
  "duplicate": [
    {
      "source": 1000,
      "offset": 1001,
      "length": 24
    }
  ]
}

source задаёт запись, которая служит шаблоном, offset — индекс вставки, length — количество добавляемых кадров. Такой приём подходит, когда целевой видеоряд содержит дополнительные повторяющиеся кадры, а метаданные для них логично продолжить значением соседней сцены. Но это не универсальный способ заполнять любой разрыв: если добавленные кадры содержат другое изображение, корректные HDR10+ параметры для них нельзя получить простым копированием.

Несколько диапазонов удаления

При удалении нескольких участков нужно учитывать, что после каждого удаления длина массива и последующие индексы меняются. Практически безопаснее перечислять независимые диапазоны от конца к началу, если они заданы в координатах исходного JSON. Тогда удаление более позднего участка не сдвигает номера кадров раннего участка до момента его обработки.

Например, если нужно убрать кадры 8202-143843 и 0-7983 из исходного набора, обработка большого позднего диапазона первой сохраняет валидность индексов раннего диапазона. Если сделать наоборот, второй диапазон может оказаться за пределами уже укороченного массива. Это особенно важно в скриптах, где диапазоны сформированы автоматически.

Практический сценарий: сохранение HDR10+ при перекодировании x265

Одна из основных задач — перекодировать изображение HEVC с другими параметрами, сохранив исходные динамические метаданные. Рабочая схема состоит из двух независимых потоков: HDR10Plus Tool извлекает JSON из оригинала, а x265 получает этот JSON при кодировании через параметр --dhdr10-info.

Сначала метаданные извлекаются:

hdr10plus_tool extract source.hevc -o metadata.json

Если оригинал находится в MKV, можно читать его напрямую либо использовать FFmpeg для выбора нужной дорожки. Затем x265 кодирует новый HEVC и получает metadata.json как Creative Intent Metadata. В x265 для этого предназначен --dhdr10-info <filename>. Дополнительный --dhdr10-opt оптимизирует вставку, ограничивая SEI кадрами, где информация меняется, и IDR-кадрами.

Передача JSON в x265 не освобождает от требования сохранить кадровую структуру. Если фильтры меняют частоту кадров, выполняют decimation, вставляют frames, удаляют заставку или делают монтаж, старый JSON перестаёт быть покадрово совместимым. Масштабирование разрешения само по себе не обязательно меняет количество кадров, но любые temporal-фильтры требуют особого внимания.

После кодирования полезно снова извлечь HDR10+ из нового HEVC и сравнить длину, scene summary и несколько контрольных точек. Это не нужно для каждого автоматического задания, если цепочка давно проверена, но является разумной диагностикой при настройке нового профиля кодирования.

Что делает --dhdr10-opt и почему извлечение может выглядеть иначе

x265 с оптимизацией HDR10+ может не повторять SEI буквально на каждом кадре: метаданные вставляются в ключевые точки, когда они меняются. HDR10Plus Tool умеет работать с такими потоками и при извлечении восстанавливать покадровую последовательность метаданных. Поэтому физическое количество SEI-сообщений в битстриме и количество записей в итоговом SceneInfo не обязательно нужно сравнивать как одно и то же число.

При диагностике важнее соответствие метаданных кадрам после развёртывания последовательности, а не частота повторения идентичных SEI. Это также объясняет, почему утилита хранит полную покадровую структуру JSON даже для длинной сцены с одинаковыми параметрами.

Практический сценарий: перенос HDR10+ между двумя версиями одного фильма

Перенос возможен только при доказанной идентичности изображений после компенсации монтажных различий. Типовой случай — WEB-DL содержит HDR10+, а Blu-ray-версия того же мастера имеет обычный HDR10. Пользователь хочет взять динамические метаданные из первой версии и добавить во вторую. Формально команды просты, но именно синхронизация определяет качество результата.

Сначала из источника HDR10+ получают JSON. Затем обе версии сравнивают покадрово. Если WEB-DL содержит, например, 96 дополнительных кадров перед первым общим кадром, эти 96 записей удаляют через editor. После этого проверяют несколько точек по всей длительности, чтобы убедиться, что смещение больше нигде не меняется.

Если частоты кадров отличаются — например, один источник 23.976 fps, другой 24.000 fps — простое удаление первых кадров не решает проблему. Со временем временная шкала разойдётся. То же относится к разным монтажным версиям, вставкам локализованного текста и различным студийным логотипам внутри фильма.

Когда синхронизация подтверждена, целевой HEVC демультиплексируют и выполняют inject. После этого поток мультиплексируют обратно в контейнер. Наличие предупреждения о несовпадающей длине — повод вернуться к сравнению, а не просто принять автоматически продублированный хвост.

Разрешение кадра само по себе не хранится как условие привязки в HDR10+ JSON в том смысле, который позволял бы автоматически запретить перенос с 3840×1600 на 3840×2160. Но различная геометрия изображения может означать другой мастер, другую обрезку или перерасчёт анализа. Поэтому одинаковое количество кадров — необходимое, но не достаточное условие.

Работа с MKV, MP4 и FFmpeg

Формат контейнера и формат видеопотока — разные уровни. HDR10Plus Tool занимается HDR10+ внутри HEVC, а MKV или MP4 отвечают за упаковку видеодорожки вместе со звуком и другими элементами. Поэтому часть задач можно выполнить напрямую с MKV при извлечении, но для внедрения и более сложного выбора дорожек полезно явно разделять demux, работу с метаданными и remux.

Наиболее универсальный способ получить raw HEVC из контейнера — FFmpeg с копированием потока:

ffmpeg -i input.mkv -map 0:v:0 -c:v copy -bsf:v hevc_mp4toannexb video.hevc

-map 0:v:0 выбирает первую видеодорожку. Это особенно важно для файлов с вложенной обложкой, дополнительным видео, альтернативной версией или другими дорожками, которые FFmpeg также может классифицировать как video. Если выбрать не тот stream, HDR10Plus Tool будет честно анализировать переданные данные, но результат не будет относиться к основному фильму.

При прямом pipe вместо файла команда выглядит так:

ffmpeg -i input.mkv -map 0:v:0 -c:v copy -bsf:v hevc_mp4toannexb -f hevc - | hdr10plus_tool extract -o metadata.json -

Указание -f hevc явно задаёт формат стандартного вывода. Битстрим-фильтр hevc_mp4toannexb нужен в ситуациях, где HEVC в контейнере хранится с length prefixes, а downstream-инструмент ожидает Annex B start codes. В MKV конкретное поведение может зависеть от входа, но явная схема делает конвейер более предсказуемым.

Почему нельзя просто скормить любой MKV команде inject

inject сначала определяет формат входа и допускает внедрение только в raw HEVC. Это связано с тем, что команда переписывает NAL units видеопотока, не занимаясь структурой контейнера, индексами, временными метками и другими дорожками. Если бы утилита принимала контейнер как выход, ей пришлось бы выполнять функции полноценного muxer, что выходит за её задачу.

Поэтому корректная цепочка выглядит как контейнер → raw HEVC → inject → raw HEVC → контейнер. С аудио и субтитрами ничего делать внутри HDR10Plus Tool не требуется: они остаются в исходном контейнере и добавляются обратно на этапе mux.

Повторное мультиплексирование без потери остальных дорожек

При сборке нового MKV проще всего рассматривать injected_output.hevc как замену старой видеодорожки. В MKVToolNix можно добавить новый HEVC вместе с исходным MKV, отключить старую видеодорожку и оставить аудио, субтитры, главы и вложения. В FFmpeg аналогичная операция требует аккуратного -map.

Ошибка на этом этапе часто маскируется под проблему HDR10Plus Tool: пользователь внедрил метаданные корректно, но затем случайно оставил в контейнере старый HEVC или сделал старую дорожку default. Проверять следует финальную активную видеодорожку, а не только наличие нового файла на диске.

Проверка результата после внедрения

После inject разумно проверить результат двумя независимыми способами: повторно запустить HDR10Plus Tool в режиме verify или extract и посмотреть сведения в анализаторе контейнера/потока, который умеет распознавать SMPTE ST 2094-40. Повторное извлечение особенно полезно, потому что проверяет данные тем же парсером, который будет работать с SEI в дальнейшем.

hdr10plus_tool --verify extract injected_output.hevc
hdr10plus_tool extract injected_output.hevc -o roundtrip.json

Если первый вызов обнаруживает HDR10+, а сторонний MediaInfo не показывает пометку Profile A/B, это ещё не всегда доказывает отсутствие метаданных. Разные анализаторы обновляют распознавание форматов в разное время и могут по-разному трактовать профиль. С другой стороны, если повторное извлечение не находит HDR10+, нужно проверять сам HEVC до этапа mux.

Полезно сравнить SceneInfo исходного и round-trip JSON. Буквальное совпадение текстовых файлов не всегда обязательно из-за форматирования и служебных полей, но количество кадров, профили, сценовая структура и значимые метаданные должны соответствовать ожидаемому сценарию.

Проверка на реальном HDR10+-совместимом телевизоре важна для финальной доставки, но визуальное впечатление не заменяет структурную диагностику. Дисплей может fallback-ить к базовому HDR10, и зритель не всегда заметит отсутствие динамического слоя. Поэтому лучше сначала доказать наличие метаданных в битстриме.

Ошибки File doesn't contain dynamic metadata

Сообщение об отсутствии динамических метаданных означает, что парсер не нашёл подходящее HDR10+ сообщение в переданном потоке. Причин несколько: источник действительно не содержит HDR10+, выбрана неправильная видеодорожка, в pipe ушёл другой кодек, метаданные потерялись при предыдущем remux/transcode либо поток записан в форме, которую текущий HEVC-парсер не распознаёт.

Порядок проверки:

1. убедиться по MediaInfo/ffprobe, что именно нужная видеодорожка заявлена как HEVC Main 10 и HDR10+;
2. явно выбрать её через -map 0:v:0 или другой корректный индекс;
3. вывести небольшой raw HEVC-фрагмент в файл и проверить его напрямую;
4. исключить перекодирование между исходником и тестом;
5. при подозрении на нестандартные метаданные повторить извлечение с --skip-validation.

Не следует считать строку HDR10 compatible в общих свойствах доказательством HDR10+. Обычный HDR10 не содержит динамических ST 2094-40 сообщений. Аналогично наличие Dolby Vision не гарантирует наличие HDR10+: два динамических формата могут сосуществовать, но один не подразумевает другой.

Ошибка Invalid input file type

Если утилита сообщает Invalid input file type, сначала нужно понять, какая подкоманда запущена и что ей передано. Для raw HEVC ожидается подходящий формат/расширение, а прямое чтение контейнера поддерживается не всеми операциями одинаково. inject требует raw HEVC; extract умеет работать с HEVC и MKV.

Переименование .m2ts в .hevc может иногда заставить старую логику определения формата трактовать файл иначе, но это плохой универсальный совет: M2TS является контейнером/транспортным форматом, а не просто HEVC с другим расширением. Надёжнее демультиплексировать нужную HEVC-дорожку средствами FFmpeg или другого demuxer и передать настоящий elementary stream.

Та же логика относится к MOV и MP4. Наличие HEVC внутри контейнера не делает весь файл raw HEVC. Если команда предназначена для elementary stream, контейнер нужно разобрать.

Ошибки разбора SEI и нестандартные значения

HDR10+ метаданные имеют строго определённую битовую структуру. Повреждённое SEI, неверный размер полезной нагрузки, неожиданное количество битов или значения вне допустимого диапазона могут привести к ошибке парсинга. В старых проблемных файлах встречались случаи, когда одна некорректная запись ломала обработку длинного фильма.

Современная схема диагностики начинается с проверки небольшого фрагмента вокруг места ошибки. Если --limit позволяет воспроизвести проблему на первых N кадрах, тест ускоряется. Если ошибка появляется далеко в фильме, полезно сначала вырезать небольшой GOP-совместимый фрагмент или демультиплексировать участок, сохраняя исходные SEI, а затем повторить анализ.

--skip-validation помогает, только когда проблема связана с проверкой соответствия профилю. Он не может исправить физически обрезанный SEI или произвольный битовый мусор. Если декодер не может прочитать поле, отключение логической валидации не восстановит отсутствующие биты.

Ошибка Condition failed: количество SEI не совпадает с количеством кадров

Один из характерных классов ошибок возникает, когда парсер обнаруживает число HDR10+ сообщений, не согласованное с числом кадров после анализа потока. Например, один дополнительный SEI на длинном фильме может нарушить внутреннее условие соответствия. Такое расхождение не следует автоматически игнорировать: нужно понять, является ли лишняя запись особенностью авторинга, ошибкой потока или результатом неверного demux.

Если проблема возникает только при pipe, полезно сохранить тот же HEVC в файл и повторить команду без конвейера. Это отделяет ошибку входного потока от поведения оболочки или FFmpeg. Если расхождение сохраняется на raw HEVC, источник действительно содержит структуру, которую парсер считает несогласованной.

Особенно важно не лечить это удалением случайного кадра из JSON после неудачного извлечения: если парсер не смог правильно сопоставить порядок, неизвестно, какой именно элемент лишний. Редактор полезен после успешного извлечения и подтверждённой синхронизации, а не как способ замаскировать неизвестную ошибку парсинга.

Ошибка Invalid PPS index и другие проблемы HEVC-структуры

HDR10Plus Tool использует HEVC-парсер, потому что для правильной привязки метаданных нужно понимать структуру кадров, SPS/PPS и порядок NAL units. Ошибка вида Invalid PPS index указывает уже не на JSON, а на то, что поток не может быть последовательно разобран в ожидаемом виде.

Причина может быть в повреждённом elementary stream, некорректном вырезании фрагмента, отсутствии нужных parameter sets перед точкой входа либо специфическом контейнерном преобразовании. Для теста стоит демультиплексировать поток заново с начала, не отрезая произвольные байты и не начиная с середины GOP. Если нужен короткий sample, его лучше создавать инструментом, который сохраняет необходимые заголовки HEVC.

Проблемы PPS не исправляются изменением HDR10+ JSON. Инъектору сначала нужен структурно читаемый HEVC, после чего он сможет определить точки вставки SEI перед slices.

Почему метаданные могут быть валидными, но визуально плохими

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

Если изображение выглядит чрезмерно ярким, контрастным или нестабильным, полезно выполнить три сравнения: исходник с HDR10+, тот же HEVC после remove, и анализ JSON/графика. Если проблема остаётся без HDR10+, динамические метаданные не являются единственной причиной. Если исчезает, можно локализовать подозрительные сцены по графику и кадрам.

Не стоит массово умножать все значения на коэффициент только потому, что максимум кажется слишком высоким. В HDR10+ разные поля имеют разные единицы, диапазоны и смысл. Правильная коррекция требует знания исходного мастеринга и спецификации, а не простой нормализации по 1000 нит.

Profile A и Profile B в практической работе

HDR10Plus Tool различает Profile A и Profile B при экспорте JSON. Для Profile A записи обходятся без BezierCurveData; для Profile B присутствует творчески определяемая Bezier tone-mapping curve. Программа вычисляет профиль по содержимому списка метаданных, а не по имени файла.

В Profile B блок кривой содержит knee point и anchors. При изменении Bezier-параметров между кадрами алгоритм вычисления сцен считает это сменой сцены. В Profile A такого сравнения нет, потому что кривой нет. Поэтому два файла с одинаковыми яркостными статистиками могут иметь разную сценовую структуру, если один содержит меняющиеся creative curves.

При переносе JSON в x265 профиль должен сохраняться за счёт содержимого метаданных. Ручное изменение HDR10plusProfile с A на B без добавления корректной кривой не создаст нормальный Profile B. Аналогично удаление только строки о профиле не превращит B в A, пока кадры содержат Bezier данные.

TargetedSystemDisplayMaximumLuminance

TargetedSystemDisplayMaximumLuminance описывает целевую максимальную яркость системы отображения в контексте динамических метаданных. Это не то же самое, что статическая максимальная яркость mastering display из HDR10. Поле участвует в описании условий, под которые рассчитано тональное отображение.

При чтении JSON следует учитывать масштаб значений, определённый форматом. Простое сравнение числа с нитами из интерфейса телевизора без пересчёта может вводить в заблуждение. HDR10Plus Tool кодирует/декодирует значение по правилам ST 2094-40 и JSON-представления, а пользователь обычно не должен менять его вручную при обычном извлечении/внедрении.

Если метаданные переносятся между двумя идентичными видеопоследовательностями, это поле сохраняют как часть creative intent. Если цель — создать новую HDR10+ мастер-метадату под другой дисплей, HDR10Plus Tool не выполняет такой творческий ремастеринг автоматически.

MaxScl, AverageRGB и распределение MaxRGB

MaxScl представляет три компонентных максимума. AverageRGB отражает среднюю характеристику MaxRGB, а LuminanceDistributions содержит пары индексов и значений для распределения. Эти данные позволяют описать яркостную структуру сцены более детально, чем один MaxCLL на весь файл.

При построении графика max-scl берётся максимум из трёх компонент. В режиме max-scl-luminance три значения сводятся через коэффициенты BT.2020. Поэтому два режима могут заметно расходиться для насыщенных цветных бликов, где одна компонента значительно выше других.

Массив DistributionIndex должен соответствовать массиву DistributionValues по длине. Если пользователь вручную удалит один элемент только из одного массива, обратное кодирование JSON должно завершиться ошибкой, потому что пары процентилей больше нельзя однозначно восстановить.

Внутренние ограничения на размер распределения также защищают от произвольных массивов. Это полезно при проверке JSON от сторонних источников: синтаксически корректный JSON ещё не обязательно представляет допустимую HDR10+ структуру.

Bezier curve: что можно понять из JSON

Кривая Bezier задаётся точкой колена и промежуточными anchors. Она описывает нелинейную часть tone mapping function, используемую при отображении сцены на целевой системе. В JSON значения представлены целыми числами в дискретном масштабе, который затем преобразуется в нормализованные параметры стандарта.

Изменение anchors вручную без визуальной системы мастеринга рискованно. Небольшое числовое изменение может менять форму кривой неинтуитивно, особенно в сочетании с knee point. HDR10Plus Tool умеет закодировать корректно сформированные значения, но не предоставляет интерактивный HDR-preview, по которому можно художественно оценить результат.

Для диагностики чаще полезно сравнивать, где кривые меняются, а не пытаться редактировать их. Если после переноса JSON scene boundaries совпадают, а BezierData сохраняется, это хороший структурный признак, что creative metadata не потеряна.

Что editor не умеет

Название editor легко понять слишком широко. На практике текущая команда предназначена для операций над кадровой последовательностью: удалить диапазоны и вставить дубликаты. Она не является универсальным редактором всех полей HDR10+ и не предоставляет команд вроде изменить MaxScl у кадров 100–200 или сдвинуть knee point на 5 %.

Если нужно изменить сами числовые поля, это делают вне встроенного редактора — например, программно преобразуют JSON с пониманием схемы — а затем используют HDR10Plus Tool для внедрения. Но такой процесс требует собственной валидации художественного и технического смысла изменений.

Сильная сторона встроенного editor — именно синхронизация: удалить лишний пролог, вставить недостающие повторные кадры, подогнать JSON к монтажно идентичному источнику. Для этой задачи ограниченный набор операций полезнее сложного универсального редактора.

Пайпы, стандартный ввод и особенности оболочек

В примерах часто используется символ |, чтобы FFmpeg отправлял HEVC напрямую в HDR10Plus Tool. Это экономит временный файл и удобно в пакетных сценариях, но добавляет зависимость от поведения shell. В bash и CMD бинарный stdout обычно передаётся как поток байтов, тогда как некоторые конфигурации PowerShell исторически могли создавать проблемы для бинарных конвейеров старых CLI-инструментов.

Если pipe вызывает странную ошибку, первый диагностический шаг — записать выход FFmpeg в video.hevc и запустить HDR10Plus Tool отдельно. Если отдельные команды работают, проблема находится в связке оболочки/pipe, а не в HDR10+ метаданных.

Для extract и remove streaming input естественен. Для inject нужен повторный анализ HEVC и запись нового файла, поэтому нормальный сценарий использует файл. Не стоит строить сложный pipe вокруг операции, которая по архитектуре должна знать полный порядок кадров и перечитывать вход.

Сценовая сводка и поиск рассинхронизации

SceneInfoSummary содержит два массива: первые кадры сцен и количество кадров в каждой сцене. Эти данные полезны не только для совместимости с другими инструментами, но и как компактная карта изменений HDR10+.

Если известна точная монтажная склейка на кадре 35210, можно проверить, начинается ли вблизи этого места новая запись scene summary. Не каждая визуальная склейка обязана менять HDR10+ параметры, поэтому совпадение не всегда один-к-одному, но массовое систематическое смещение всех изменений на десятки кадров указывает на проблему синхронизации.

Особенно показательна последовательность из множества сцен длиной 1–3 кадра на материале, где визуально длинные планы. Это может означать неправильный порядок метаданных при B-frames. В такой ситуации стоит сравнить обычное извлечение и вариант с --skip-reorder.

Автоматизация пакетной обработки

HDR10Plus Tool хорошо подходит для сценариев, где имена файлов и параметры заранее известны. Команды возвращают ошибку при невозможности разобрать данные, поэтому batch-скрипт может прерывать цепочку до кодирования, если JSON не получен. Это лучше, чем продолжать обработку и случайно выпустить обычный HDR10 вместо HDR10+.

Типовая автоматизация может состоять из следующих этапов:

1. получить сведения о входной видеодорожке и определить, нужен ли HDR10+ workflow;
2. запустить --verify extract для подтверждения динамических метаданных;
3. выполнить полный extract в временный JSON;
4. при необходимости применить editor с заранее рассчитанными диапазонами;
5. передать JSON кодеру либо выполнить inject в готовый HEVC;
6. проверить полученный elementary stream перед remux;
7. собрать конечный контейнер.

В скрипте полезно сохранять рядом с заданием исходный JSON и конфиг редактора. Тогда можно восстановить, какие кадры удалялись или дублировались, не анализируя итоговый HEVC задним числом. Сами файлы небольшими назвать нельзя: покадровый JSON длинного фильма может занимать значительный объём, особенно Profile B, поэтому временную директорию следует планировать с запасом.

Не стоит строить автоматическую логику, которая при любой ошибке добавляет --skip-validation и продолжает обработку. Такое поведение скрывает входы с сомнительными метаданными. Лучше помечать их как требующие ручной диагностики.

Имена файлов и повторяемость

Для массовой обработки удобно давать файлам роли в имени: source_hdr10plus.json, edits.json, synced_hdr10plus.json, video_clean.hevc, video_injected.hevc. Это снижает риск передать в inject исходный несинхронизированный JSON вместо исправленного.

Опция вывода должна задаваться явно во всех производственных скриптах. Имя по умолчанию удобно для разового запуска, но в цикле по каталогу несколько заданий будут претендовать на один и тот же injected_output.hevc.

Сочетание HDR10Plus Tool и FFmpeg без перекодирования

Самый безопасный принцип — чётко различать команды, где FFmpeg копирует видеодорожку, и команды, где он декодирует/кодирует. Если задача состоит только в извлечении, удалении или подготовке raw HEVC, должен использоваться stream copy. Любое непреднамеренное кодирование создаст новый битстрим и может изменить или отбросить динамические данные.

Для demux:

ffmpeg -i input.mkv -map 0:v:0 -c:v copy -bsf:v hevc_mp4toannexb video.hevc

Для прямого извлечения без временного файла:

ffmpeg -i input.mkv -map 0:v:0 -c:v copy -bsf:v hevc_mp4toannexb -f hevc - | hdr10plus_tool extract -o metadata.json -

Для удаления метаданных через pipe:

ffmpeg -i input.mkv -map 0:v:0 -c:v copy -bsf:v hevc_mp4toannexb -f hevc - | hdr10plus_tool remove - -o no_hdr10plus.hevc

При выводе обратно в контейнер HEVC уже содержит нужные SEI, поэтому FFmpeg не должен заново кодировать его. Нужен -c copy и корректная карта дорожек. Если конечный MP4 или MKV внезапно теряет HDR10+, полезно проверить промежуточный .hevc: это сразу показывает, произошло ли повреждение до или во время mux.

Сочетание с x265

x265 умеет принимать HDR10+ JSON через --dhdr10-info и вставлять dynamic tone mapping information в HEVC. Это один из естественных потребителей JSON, который создаёт HDR10Plus Tool. Если видео перекодируется с сохранением кадровой структуры, схема extract → x265 --dhdr10-info позволяет перенести динамические метаданные без отдельной пост-инъекции.

--dhdr10-opt у x265 сокращает повторение идентичной информации: SEI записываются на IDR и в точках изменения tone mapping. При последующем извлечении HDR10Plus Tool разворачивает эти изменения так, чтобы JSON снова имел покадровую структуру. Поэтому размер битстрима и количество физически записанных сообщений могут отличаться от сценария, где SEI присутствует перед каждым кадром.

Нельзя путать --hdr10/--hdr10-opt с --dhdr10-info. Первые относятся к HDR10-сигнализации и оптимизации кодирования HDR-контента; динамические HDR10+ метаданные поступают через отдельный JSON.

Если после кодирования анализатор не показывает HDR10+, но повторный inject говорит, что вход уже содержит HDR10+ SEI, стоит проверить распознавание сторонним анализатором и повторно извлечь JSON. Сам факт отсутствия строки в одном приложении не всегда означает отсутствие SEI.

Сочетание с dovi_tool и гибридными HDR-процессами

HDR10Plus Tool и dovi_tool решают соседние, но разные задачи. Первый работает с HDR10+ ST 2094-40, второй — с Dolby Vision RPU. В некоторых рабочих процессах оба набора динамических метаданных присутствуют в одном HEVC, а сторонние скрипты позволяют конвертировать данные между форматами или создавать гибридные потоки.

Наличие Dolby Vision не мешает по определению извлечь HDR10+, если HEVC содержит оба типа данных и поток корректно разбирается. Однако при demux и повторной сборке нужно не потерять второй динамический слой. Команда remove HDR10Plus Tool предназначена для HDR10+ и не должна рассматриваться как средство удаления Dolby Vision RPU.

Если цель — сделать Dolby Vision на основе HDR10+ JSON, это уже функция другого инструмента. HDR10Plus Tool предоставляет структурированные метаданные, но не генерирует RPU. Аналогично dovi_tool не заменяет прямой parser/injector ST 2094-40 для всех операций.

Ограничения программы

Первое ограничение — ориентация на HEVC. HDR10+ как технология может переноситься и в AV1, но основная HDR10Plus Tool работает с HEVC NAL/SEI. Нельзя взять AV1 IVF, переименовать его в HEVC и ожидать, что команды extract или inject поймут структуру OBU.

Второе ограничение — отсутствие генерации HDR10+ из изображения. Программа не анализирует кадры для создания нового SceneInfo. Ей нужен уже существующий HEVC с HDR10+ для извлечения либо готовый JSON для внедрения.

Третье — встроенный editor изменяет кадровую последовательность метаданных, но не предоставляет полноценный графический редактор всех полей ST 2094-40. Ручная творческая правка яркостных параметров выполняется внешними средствами.

Четвёртое — inject работает с raw HEVC, поэтому контейнер приходится собирать отдельно. Это не недостаток качества обработки, но добавляет этап в пользовательский workflow.

Пятое — перенос метаданных между разными релизами требует точного кадрового соответствия, которое программа не может доказать автоматически. Предупреждение о длине помогает обнаружить очевидное расхождение, но одинаковое число кадров не гарантирует синхронизацию.

Наконец, --skip-validation не является автоматическим repair mode. Если исходные метаданные повреждены, программа может позволить их разобрать для диагностики, но не знает, какими должны быть правильные значения.

Какие задачи HDR10Plus Tool решает лучше всего

Задача	Подходящая команда	Комментарий
Проверить наличие HDR10+	--verify extract	Быстрая проверка распознаваемого ST 2094-40
Сохранить HDR10+ перед перекодированием	extract	Полученный JSON можно передать x265
Добавить готовый JSON в HEVC	inject	Требуется raw HEVC и точное соответствие кадров
Удалить динамические метаданные	remove	Пиксели не перекодируются
Оценить изменение яркости по метаданным	plot	PNG по одному из четырёх peak-source
Убрать лишние кадры из JSON	editor remove	Диапазоны включительные
Добавить повторные записи метаданных	editor duplicate	Нужны source, offset и length

Если задача выходит за эти рамки — например, требуется визуальный HDR-grading, генерация новых метаданных из кадров, полноценный монтаж или работа со всеми дорожками контейнера, — HDR10Plus Tool становится частью цепочки, а не единственным приложением.

Сравнение HDR10Plus Tool с аналогами

У HDR10Plus Tool немного полных самостоятельных аналогов: многие программы с HDR10+ используют его как внутренний движок или вызывают те же операции через графическую оболочку. Поэтому ближайшие альтернативы отличаются не столько стандартом метаданных, сколько уровнем автоматизации и способом включения HDR10+ в общий видеопроцесс.

Программа	Лучше подходит для	Главное ограничение
HDR10Plus Tool	Точного extract/inject/remove/edit/plot HDR10+ в HEVC и JSON	Командный интерфейс и raw HEVC для inject
HDR-Multi-Tool	Пользователей, которым нужен GUI для извлечения HDR10+ и Dolby Vision из контейнеров	Для HDR10+ опирается на внешние инструменты, включая hdr10plus_tool
DDVT	Комплексных Dolby Vision/HDR10+ workflows, демультиплексирования, инъекции и гибридов	Набор скриптов шире по задаче и зависит от нескольких сторонних утилит
StaxRip	Полного процесса перекодирования с автоматизированным сохранением HDR-метаданных	HDR10+ является частью большого encoding workflow, а не отдельным низкоуровневым редактором
FastFlix	Графического кодирования HEVC/AV1 с подготовкой HDR10+ для энкодера	Ориентирован на перекодирование; для извлечения использует hdr10plus_tool
x265	Вставки готового HDR10+ JSON непосредственно во время HEVC-кодирования	Не предназначен для извлечения, удаления и покадрового редактирования существующих SEI

Практический выбор простой. Если нужен контроль на уровне HDR10+ JSON и HEVC без лишнего интерфейса, HDR10Plus Tool остаётся наиболее прямым вариантом. Если задача состоит в полном перекодировании с очередью, фильтрами, аудио и контейнером, удобнее StaxRip или FastFlix. HDR-Multi-Tool подходит тем, кому нужен более наглядный front-end для извлечения динамических метаданных. DDVT предпочтителен в сложных гибридных сценариях с Dolby Vision. x265 не заменяет parser/editor, зато естественно принимает уже подготовленный JSON во время кодирования.

ВидеоМАСТЕР в эту таблицу не включён, потому что его основной класс задач — пользовательское конвертирование и монтаж видео, а не извлечение и инъекция HDR10+ ST 2094-40 SEI с покадровым JSON. Сравнивать их как прямые аналоги было бы некорректно.

HDR-Multi-Tool как графическая оболочка

HDR-Multi-Tool предлагает графический интерфейс для разбора HDR10+ и Dolby Vision. Он принимает распространённые контейнеры, может ставить задания в очередь и скрывает часть командной рутины. Для пользователя, который не хочет вручную писать FFmpeg pipe и команды extract, это заметно проще.

Однако в HDR10+ части такая программа не превращает задачу в другой алгоритм: она использует hdr10plus_tool как зависимость. Поэтому при редкой ошибке конкретного SEI низкоуровневая диагностика всё равно часто возвращается к исходной CLI-утилите и её сообщениям.

Выбирать GUI имеет смысл ради удобства и очереди; выбирать HDR10Plus Tool напрямую — ради прозрачных параметров, скриптов и точного контроля входа/выхода.

DDVT для смешанных Dolby Vision и HDR10+ задач

DDVT объединяет множество сценариев: demux Dolby Vision layers/RPU, извлечение HDR10+, удаление динамических метаданных, инъекцию, построение графиков, задержки и гибридные сборки. Для пользователя, который постоянно работает с релизами, содержащими одновременно DV и HDR10+, такая оболочка может сократить количество ручных этапов.

При этом DDVT сам включает вызовы HDR10Plus Tool для HDR10+ операций. Это важно при сравнении: функционально он шире, но не является полностью независимым альтернативным parser ST 2094-40. Если нужна только одна операция extract или inject, исходная утилита проще и даёт меньше скрытых шагов.

StaxRip и FastFlix в роли автоматизаторов

StaxRip и FastFlix полезны, когда HDR10+ является одной частью большой задачи перекодирования. Они помогают выбрать энкодер, фильтры, контейнер и параметры, а динамические метаданные передаются по цепочке автоматически. Это снижает вероятность забыть JSON между этапами, но добавляет абстракцию над конкретными командами.

Для диагностики сложного файла всё равно полезно знать базовый hdr10plus_tool синтаксис. Если автоматизатор пишет ошибку Extract HDR10+ metadata, возможность вручную повторить FFmpeg → extract позволяет понять, проблема в исходнике, настройке программы или её wrapper-логике.

x265 как потребитель HDR10+ JSON

x265 ближе всего к HDR10Plus Tool по формату обмена, но решает другую часть процесса. Он не нужен, чтобы просто перенести SEI из одного HEVC в другой без перекодирования; зато при создании нового HEVC может сразу вставлять dynamic metadata из JSON.

Если новый видеопоток уже закодирован без HDR10+, inject позволяет добавить JSON постфактум. Если кодирование ещё предстоит, --dhdr10-info в x265 обычно логичнее: метаданные становятся частью результата за один проход.

Безопасная последовательность при исправлении рассинхронизации

Когда метаданные сдвинуты относительно видео, лучше не начинать с инъекции. Сначала нужно установить точную модель различий. В простейшем случае это постоянное смещение в N кадров; в более сложном — несколько вставок и удалений по фильму.

1. Выберите общий визуально уникальный кадр в начале и определите его точный индекс в обоих источниках.
2. Повторите сравнение после нескольких сцен и в конце фильма.
3. Если разница постоянна, примените одно удаление или дублирование.
4. Если разница меняется, найдите точку каждого изменения и составьте несколько операций.
5. После editor проверьте общее число записей и scene summary.
6. Только после этого запускайте inject или передавайте JSON в x265.

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

Как не перепутать HDR10+ с другими HDR-данными

В одном MediaInfo-отчёте могут одновременно встречаться Dolby Vision, SMPTE ST 2094 App 4, mastering display metadata, MaxCLL и MaxFALL. Они относятся к разным уровням. Для HDR10Plus Tool важен именно ST 2094-40/HDR10+. Статические поля HDR10 программа не экспортирует в свой JSON как замену динамическим данным.

Если после remove анализатор продолжает показывать BT.2020, PQ, mastering display и MaxCLL, это нормальное поведение: удалён только динамический слой. Если цель — изменить статические SEI/VUI, нужен инструмент, который поддерживает соответствующие HEVC metadata operations.

Dolby Vision RPU также может сосуществовать с HDR10+. Его наличие не определяется полем JSONInfo HDR10Plus Tool и не меняется встроенным editor. Поэтому гибридный поток следует проверять отдельно для каждого динамического формата.

Рекомендации по хранению и повторному использованию JSON

HDR10+ JSON фактически является покадровым описанием конкретной версии видео. Для архива важно хранить рядом сведения, к какому исходнику он относится: имя релиза, число кадров, частоту кадров и желательно контрольную информацию о монтаже. Иначе через несколько месяцев два похожих metadata.json легко перепутать.

Переименование файла JSON никак не влияет на его внутреннее содержимое. Можно использовать осмысленные имена вроде movie_source_23976_hdr10plus.json. Однако переносить один JSON между разными кодировками только по совпадению названия фильма нельзя. Даже версия с тем же разрешением и длительностью может иметь другое начало или отличаться одним кадром.

Если JSON редактировался командой editor, имеет смысл хранить и edits.json. Он намного компактнее и документирует, почему финальная последовательность отличается от исходной.

Пример полного workflow с извлечением, правкой и внедрением

Предположим, есть source_hdr10plus.mkv с нужными метаданными и target.mkv с идентичным фильмом, но в источнике метаданных обнаружены 48 лишних кадров перед первым общим кадром. После покадровой проверки смещение остаётся ровно 48 кадров до конца.

Шаг 1 — извлечь динамические метаданные:

hdr10plus_tool extract source_hdr10plus.mkv -o source.json

Шаг 2 — создать edits.json:

{
  "remove": [
    "0-47"
  ]
}

Шаг 3 — получить синхронизированный JSON:

hdr10plus_tool editor source.json -j edits.json -o synced.json

Шаг 4 — извлечь HEVC из целевого контейнера:

ffmpeg -i target.mkv -map 0:v:0 -c:v copy -bsf:v hevc_mp4toannexb target.hevc

Шаг 5 — внедрить метаданные:

hdr10plus_tool inject -i target.hevc -j synced.json -o target_hdr10plus.hevc

Шаг 6 — проверить элементарный поток:

hdr10plus_tool --verify extract target_hdr10plus.hevc

Только после успешной проверки имеет смысл возвращать поток в контейнер и переносить остальные дорожки. Если на шаге inject появляется предупреждение о другой длине, предполагаемое смещение было рассчитано неверно либо версии фильма отличаются ещё где-то.

Пример workflow для перекодирования с сохранением HDR10+

Если цель — уменьшить битрейт HEVC, а не просто внедрить метаданные, исходный JSON сначала сохраняют:

hdr10plus_tool extract source.mkv -o metadata.json

Далее декодированное видео поступает в x265, а metadata.json передаётся через --dhdr10-info. Конкретная команда кодирования зависит от источника, фильтров, глубины цвета и параметров качества; HDR10Plus Tool здесь не выбирает CRF, preset или VBV.

Если кодирование меняет только пространственное разрешение и сохраняет каждый входной кадр один-к-одному, кадровая структура JSON остаётся применимой. Если включены deinterlace, frame interpolation, decimation, inverse telecine или изменение fps, динамические метаданные требуется перерассмотреть — простой исходный JSON уже не соответствует новой временной последовательности.

После кодирования можно извлечь метаданные из результата и построить график, чтобы убедиться, что динамические изменения сохранились в ожидаемых местах.

Пример использования plot для локальной диагностики

Допустим, при просмотре около 42-й минуты замечен необычный скачок яркости. Сначала по частоте кадров переводят временную позицию в приблизительный frame index, затем уточняют его в плеере или редакторе. После этого строят график вокруг небольшой области:

hdr10plus_tool plot metadata.json -s 60000 -e 62000 -p histogram -t "problem area" -o problem.png

Если на графике виден одиночный экстремальный пик, проверяют соответствующий кадр и соседние записи JSON. Затем строят второй график с max-scl или histogram99. Если выброс присутствует только в одном источнике peak brightness, это помогает понять, какой компонент данных необычен.

Если же графики выглядят плавно, а изображение меняется резко, причина может находиться не в HDR10+ метаданных. Тогда стоит проверить сам PQ-видеосигнал, статические HDR параметры и настройки воспроизведения.

Частые вопросы о HDR10Plus Tool

Можно ли создать HDR10+ для обычного HDR10-фильма?

Нет, сама утилита не генерирует новые метаданные на основе анализа изображения. Она извлекает существующие ST 2094-40 данные, редактирует их кадровую последовательность, удаляет или внедряет готовый JSON. Для генерации с нуля нужен отдельный анализатор/мастеринговый процесс.

Можно ли внедрить JSON прямо в MKV?

Команда inject работает с raw HEVC. Из MKV нужно получить HEVC-видеодорожку, выполнить внедрение, затем собрать контейнер заново. Прямое чтение MKV относится к extract, а не превращает inject в muxer.

Почему после удаления HDR10+ файл всё ещё определяется как HDR?

Потому что HDR10Plus Tool удаляет динамические ST 2094-40 сообщения, но не переводит PQ-видео в SDR и не удаляет автоматически статические mastering display, MaxCLL/MaxFALL или BT.2020/PQ сигнализацию.

Можно ли использовать JSON от версии фильма с другим разрешением?

Само различие разрешения не является единственной проверкой, но важнее идентичность кадровой последовательности и мастера. Если одно видео просто пространственно масштабировано без изменения кадров и основано на том же мастере, временная привязка может совпадать. Если геометрия отражает другой кадринг или другой релиз, перенос требует дополнительной проверки.

Что делать, если JSON на несколько кадров короче?

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

Что делать, если JSON длиннее HEVC?

Лишние записи в конце будут пропущены. Если целевое видео намеренно короче только с хвоста, это ожидаемо. Если обрезка произошла в середине или начале, нужно редактировать JSON, иначе кадры после изменения будут сдвинуты.

Нужен ли --skip-reorder всегда?

Нет. Нормальный режим как раз выполняет корректное переупорядочивание. --skip-reorder нужен как обход для неправильно авторингованных потоков, где обычная логика даёт несогласованные scene boundaries из-за исходного порядка SEI.

Для чего --skip-validation?

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

Почему plot показывает значения выше яркости моего телевизора?

График отражает метаданные контента, а не физический максимум конкретного дисплея. Кроме того, разные peak-source рассчитываются из разных полей. Дисплей применяет собственное tone mapping с учётом своих возможностей.

Можно ли менять HDR10+ без перекодирования видео?

Извлечение, удаление и пост-инъекция в raw HEVC не требуют перекодировать пиксели. Но если нужно создать новые метаданные по изменённому изображению или выполнить монтаж видеоряда, отдельный видеопроцесс может потребоваться.

Почему MediaInfo не показывает Profile B после inject?

Сначала повторно извлеките HDR10+ самим HDR10Plus Tool. Если данные читаются, проблема может быть в распознавании или версии стороннего анализатора. Если не читаются, проверяйте intermediate HEVC и JSON. Также убедитесь, что после remux активна именно новая видеодорожка.

Можно ли использовать editor для изменения MaxScl?

Встроенный editor предназначен для удаления и дублирования кадровых записей. Для правки числовых полей нужен внешний JSON-процессинг с пониманием схемы и ограничений ST 2094-40.

Подходит ли программа для AV1 HDR10+?

Основные команды HDR10Plus Tool рассчитаны на HEVC. В AV1 HDR10+ переносится через metadata OBU, а не HEVC SEI, поэтому нужен инструмент, который понимает AV1 OBU-структуру.

Краткий справочник команд

Команда	Вход	Выход	Ключевые параметры
extract	HEVC или MKV с HEVC	JSON	-o, --skip-reorder, --limit
inject	raw HEVC + JSON	raw HEVC	-j, -o
remove	HEVC	HEVC без HDR10+ SEI	-o
plot	HDR10+ JSON	PNG	-p, -s, -e, -t, -o
editor	HDR10+ JSON + edits JSON	изменённый JSON	-j, -o

Глобально применяются --verify и --skip-validation, но смысл первого относится к проверке входа при извлечении; для inject и remove он не добавляет полезной операции.

Что учитывать перед использованием метаданных в финальном файле

Главный критерий — соответствие динамических данных конкретным кадрам. Правильный формат JSON, отсутствие ошибки в терминале и совпадение общего числа кадров важны, но этого недостаточно. При переносе между релизами нужно убедиться, что монтаж идентичен; при перекодировании — что temporal filters не изменили последовательность.

Второй критерий — валидность метаданных. Если приходится использовать --skip-validation, стоит зафиксировать это как особенность источника и не считать результат автоматически стандартным Profile A/B.

Третий критерий — целостность контейнерной сборки. Проверять нужно intermediate HEVC после inject и финальную видеодорожку после mux. Это разделяет проблемы HDR10+ и ошибки выбора дорожек.

Четвёртый критерий — осмысленное использование editor. Удаление и дублирование должны отражать реальные вставки/удаления кадров, а не служить способом просто уравнять две длины.

Итоговый рабочий подход

HDR10Plus Tool наиболее полезен там, где важна точность динамических метаданных и прозрачность каждого шага. Для сохранения HDR10+ достаточно извлечь JSON до перекодирования и передать его x265; для готового HEVC можно использовать post-injection; для диагностики доступны verify, remove и plot; для небольших монтажных различий — editor.

Главная зона риска находится не в синтаксисе команд, а в привязке метаданных к кадрам. Автоматическое дублирование или отбрасывание хвоста помогает завершить операцию при разной длине, но не заменяет проверку монтажа. Если два видео действительно совпадают покадрово, утилита позволяет перенести HDR10+ без повторного кодирования изображения. Если не совпадают, сначала нужно исправить временную структуру JSON или отказаться от переноса.

Для технической работы с ST 2094-40 программа даёт редкое сочетание низкоуровневых операций: извлечение, внедрение, удаление, визуализация и кадровая правка в одном CLI. Именно поэтому она удобна как самостоятельный инструмент и как основа более крупных HDR-процессов в FastFlix, StaxRip, HDR-Multi-Tool и DDVT.

Разбор edits.json: точные правила индексов

Файл конфигурации для editor кажется простым, но большинство ошибок возникает именно из-за индексов. Нумерация начинается с нуля. Диапазоны remove включают обе границы, поэтому количество удалённых записей вычисляется как end - start + 1. Диапазон 100-199 удаляет 100 кадров, а не 99.

Если удаляется единственный кадр, диапазон можно задавать как соответствующую позицию по синтаксису, который принимает редактор; при построении автоматических конфигов безопаснее всегда формировать однозначные диапазоны и отдельно считать ожидаемую итоговую длину. Это снижает риск off-by-one при преобразовании времени в кадры.

Операции duplicate применяются после всех удалений. Поле source указывает индекс метаданных, которые нужно копировать. offset задаёт место вставки, а length — количество новых записей. Если до этого из начала было удалено 48 кадров, старый source 1000 в исходном JSON уже не обязательно соответствует source 1000 в промежуточном массиве.

При нескольких удалениях от конца к началу легче сохранить исходные координаты. Например, нужно убрать два рекламных блока: 1000–1047 и 50000–50095. Если сначала удалить ранний блок, второй начнётся уже на 48 кадров раньше. Если сначала удалить поздний, ранние индексы пока не меняются. Поэтому нисходящий порядок диапазонов удобен для конфигов, рассчитанных по исходной шкале.

Редактор и SceneInfoSummary

После изменения длины недостаточно механически оставить старые SceneFirstFrameIndex и SceneFrameNumbers. HDR10Plus Tool формирует выходной JSON с учётом новой последовательности, поэтому scene summary соответствует результату. Это одна из причин предпочитать встроенный editor простому удалению строк в текстовом редакторе.

Если вручную вырезать элементы массива SceneInfo, но не обновить сводку и индексы SequenceFrameIndex/SceneFrameIndex, файл может выглядеть синтаксически нормальным, однако содержать внутренние противоречия. Встроенная команда снимает эту рутинную часть.

Диагностический чек-лист перед поиском бага HDR10Plus Tool

При ошибке полезно сначала исключить проблемы вокруг утилиты. Многие симптомы вызываются контейнером, неверно выбранной дорожкой, монтажным различием или не тем порядком кадров. Короткая последовательность проверок экономит время:

• входная видеодорожка действительно HEVC и действительно содержит HDR10+;
• при FFmpeg pipe явно указан правильный -map;
• для inject подготовлен raw HEVC, а не контейнер с другим расширением;
• JSON успешно читается и содержит непустой SceneInfo;
• число кадров JSON ожидаемо относительно видео;
• --skip-reorder не включён без причины;
• --skip-validation не используется как постоянное подавление ошибок;
• после inject проверяется промежуточный HEVC до remux;
• после remux активной стала новая видеодорожка;
• при переносе между релизами проверены несколько покадровых точек по всей длительности.

Если все эти условия выполнены, сообщение парсера уже намного информативнее: можно изолировать конкретный HEVC-фрагмент, JSON или тип SEI и искать проблему на уровне программы.

Как интерпретировать предупреждение о существующих HDR10+ SEI

При inject программа заранее анализирует вход и, обнаружив HDR10+ сообщения, сообщает, что они будут заменены. Это не ошибка и не запрет на продолжение. Предупреждение означает, что операция не будет просто добавлять второй независимый набор HDR10+ поверх первого.

Во время переписывания существующее ST 2094-40 сообщение удаляется. Если в том же SEI NAL есть другие сообщения, утилита сохраняет их и удаляет только нужную часть. Затем новый HDR10+ NAL вставляется перед slice. Такой подход позволяет обновить динамические данные, не уничтожая несвязанные SEI.

Если задача — убедиться, что старые данные полностью исчезли перед внедрением, можно отдельно выполнить remove, проверить файл и затем inject. Но в обычном случае двойной проход не обязателен: инъектор уже рассчитан на замену существующего HDR10+.

Почему одинаковый frame count не гарантирует правильный перенос

Представим два файла по 100000 кадров. Во втором после кадра 20000 удалено 24 кадра и перед финалом добавлено 24 других. Общая длина совпадает, но метаданные от первого файла начиная с 20000 будут соответствовать изображениям со сдвигом, а около конца снова случайно сойдутся по индексу. Ни проверка общей длины, ни предупреждение inject такую ошибку не обнаружат.

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

Точный перенос HDR10+ — это задача синхронизации метаданных с изображением. HDR10Plus Tool даёт инструменты для исправления известного смещения, но не заменяет сравнение исходников.

Когда лучше использовать remove, а когда inject

remove выбирают, если динамические данные нужно полностью исключить из HEVC либо подготовить чистую базу для сравнения. inject выбирают, когда есть готовый JSON и задача — заменить существующие либо добавить отсутствующие HDR10+ сообщения.

Если источник уже содержит HDR10+ и нужно заменить его на исправленную версию того же JSON, отдельное удаление не обязательно. Если же исследуется проблема воспроизведения и нужно получить контрольный файл тот же HEVC, но без HDR10+, remove даёт именно такой результат без перекодирования пикселей.

Для нового x265-кодирования post-inject тоже не всегда лучший вариант: если JSON готов заранее, проще передать его кодеру через --dhdr10-info. inject особенно ценен, когда HEVC уже создан и повторное кодирование нежелательно.

Когда plot действительно помогает

График особенно полезен в трёх ситуациях. Первая — поиск аномальных выбросов в метаданных. Вторая — сравнение двух вариантов JSON после reorder/skip-reorder. Третья — быстрая оценка того, совпадают ли точки изменения метаданных с ожидаемыми участками фильма.

При сравнении двух JSON нужно использовать одинаковый peak-source, одинаковый диапазон кадров и желательно одинаковый title scale. Иначе визуальные различия могут быть вызваны методом расчёта, а не метаданными.

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

Подход к редким нестандартным источникам

Некоторые диски и рипы содержат HDR10+ в необычном порядке или с данными, не проходящими строгую проверку. Для таких случаев в программе и существуют --skip-reorder и --skip-validation, но каждый флаг решает конкретную проблему. Первый меняет обработку порядка кадров; второй отключает профильную валидацию. Они не взаимозаменяемы.

Если обычный extract даёт странную сценовую структуру, но не ошибку, сначала исследуют reorder. Если программа прямо сообщает о недопустимом поле, рассматривают validation. Если парсер не может физически разобрать HEVC NAL/PPS, ни один из этих флагов не является подходящим лечением.

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