DoVi Tool помогает извлекать, проверять, редактировать, генерировать и возвращать RPU-метаданные Dolby Vision, а также разбирать и собирать HEVC-потоки с базовым и дополнительным слоями: для этого используются команды info, generate, editor, export, plot, convert, demux, mux, extract-rpu, inject-rpu и remove.

Главная особенность утилиты — работа именно с динамическими метаданными Dolby Vision и структурой HEVC, а не с обычным монтажом. Она умеет читать RPU, менять совместимость профиля, извлекать или внедрять RPU, разделять Base Layer и Enhancement Layer, собирать их обратно, выгружать служебные данные и строить графики уровней метаданных. Пиксельное кадрирование, монтаж по дорожкам, обработка звука и создание субтитров к этим операциям не относятся.

DoVi Tool особенно полезен в цепочках перекодирования HDR-видео, когда видеопоток кодируется отдельным энкодером, а Dolby Vision нужно сохранить или адаптировать отдельно. В таком процессе сначала проверяют профиль и RPU, затем при необходимости извлекают и редактируют метаданные, после чего возвращают их в HEVC. Для контейнерных операций обычно нужен внешний демультиплексор или FFmpeg, потому что сама утилита сосредоточена на RPU и HEVC.

Что именно обрабатывает DoVi Tool

Рабочая единица DoVi Tool — не проект видеомонтажа, а Dolby Vision RPU и HEVC-битстрим. RPU содержит динамические сведения, которые сопровождают видеокадры и влияют на Dolby Vision-обработку при воспроизведении. Утилита умеет разобрать такие данные, вывести сводку, показать структуру конкретного кадра, выгрузить выбранные уровни, изменить разрешённые поля и записать исправленный бинарный RPU. Если метаданные находятся внутри HEVC, часть операций можно выполнить непосредственно во время разбора потока.

Из этого следует важное ограничение: наличие слова video в примерах не превращает программу в универсальный конвертер. Она не предлагает кодеки для обычного перекодирования картинки, не меняет разрешение, частоту кадров или битрейт и не рисует фильтры поверх изображения. Когда требуется перекодировать HEVC, AV1 или другой видеоряд, эту задачу выполняет отдельный энкодер; DoVi Tool отвечает за Dolby Vision-часть и за специальные операции над HEVC-структурой, необходимые для переноса RPU или слоёв.

Такое разделение полезно при автоматизации. Можно подготовить чистый видеопоток внешним инструментом, извлечь RPU из исходника, при необходимости преобразовать совместимость метаданных, проверить число кадров и затем внедрить RPU в результат. Ключевая проверка — одинаковое соответствие кадров между метаданными и итоговым HEVC. Если монтаж изменил длительность, удалил кадры или создал другую структуру, RPU нельзя просто переносить без согласованного редактирования.

Как устроена командная работа

Основной синтаксис строится вокруг одной подкоманды. Сначала указывают исполняемый файл, затем при необходимости глобальные параметры и действие: анализ, экспорт, генерацию, редактирование или операцию над HEVC. У каждой подкоманды есть собственная справка. Для редких ключей это надёжнее памяти: параметры у разных действий отличаются, а некоторые глобальные опции специально не влияют на внедрение RPU.

Практически удобно разделять каталог на исходники, промежуточные RPU и итоговые HEVC. Тогда легко понять, какой файл был получен после extract-rpu, какой прошёл editor, а какой создан inject-rpu. Команда не ведёт библиотеку проектов и не хранит историю изменений, поэтому именование файлов фактически становится частью рабочего процесса. Перед перезаписью исходного RPU стоит сохранять копию: JSON-конфигурация редактора описывает изменение, но не заменяет исходные данные.

В Windows важна особенность PowerShell: если dovi_tool.exe лежит в текущем каталоге и не добавлен в PATH, исполняемый файл обычно вызывают с префиксом .\. Это не параметр DoVi Tool, а правило оболочки. В других оболочках применяется их обычный способ запуска. Ошибка вида команда не найдена поэтому ещё не означает, что архив повреждён: сначала проверяют расположение файла и способ обращения к нему.

С чего начинать проверку файла

Перед любым преобразованием разумно получить представление о метаданных. Команда info читает бинарный RPU и может печатать сводную информацию. В сводке полезны число кадров, профиль, версия DM, количество сцен и доступные уровни метаданных. Это быстрый контроль того, что извлечён именно RPU ожидаемого материала, а не файл нулевой длины, остаток от неудачной команды или данные от другого ролика.

Для точечной диагностики info умеет выводить JSON конкретного кадра. Индексация начинается с нуля: первый кадр имеет индекс 0. Это особенно важно, когда рядом используются монтажные номера, которые человек привычно считает с единицы. Ошибка на один кадр в Dolby Vision-метаданных заметна не как простой сдвиг таймкода в интерфейсе, а как применение чужих динамических значений к соседнему кадру, поэтому границы диапазонов нужно проверять намеренно.

Сводка не заменяет полный анализ качества картинки. Она показывает структуру и значения RPU, но не измеряет реальное изображение после декодирования и не оценивает художественную корректность тримов. Если задача состоит в том, чтобы подтвердить результат на конкретном телевизоре или плеере, после технической проверки метаданных нужен тест воспроизведения. DoVi Tool помогает исключить структурные ошибки, но не симулирует весь тракт отображения Dolby Vision.

Команда info: сводка и отдельный кадр

Режим summary полезен как первая контрольная точка до и после редактирования. Если количество RPU неожиданно изменилось, это сразу указывает на удаление, дублирование, несовпадение входа или неудачный сценарий. Дополнительные сведения о L5, L8 и L9 помогают понять, присутствуют ли активная область, творческие тримы и данные о первичных цветах мастер-дисплея. Наличие поля ещё не подтверждает его художественную правильность, но отсутствие ожидаемого уровня уже даёт направление поиска.

Вывод одного кадра в JSON нужен, когда требуется увидеть структуру блока без экспорта всего фильма. Так проще проверить начало сцены, кадр перед изменением и кадр после него. Если редактор меняет диапазон 0–39, полезно сравнить как минимум кадры 0, 39 и 40: первые два должны отражать заданное изменение, а следующий — остаться вне диапазона, если конфигурация не содержит глобального правила.

Для расследования проблем полезно сохранять текстовый вывод рядом с входным RPU. Это даёт проверяемую пару что было — что стало без догадок по имени файла. Особенно это важно для Level 5 и Level 6: нулевые смещения активной области и значения яркости могут быть совершенно легитимными, поэтому оценивать их нужно в контексте источника, а не по принципу ноль значит ошибка.

Что такое RPU в практическом смысле

RPU можно рассматривать как покадрово привязанный набор Dolby Vision-метаданных, но в нём есть и служебная структура, и разные уровни данных. Поэтому бинарный файл RPU нельзя безопасно править обычным текстовым редактором. DoVi Tool сначала разбирает его в структуры, проверяет допустимость значений и затем формирует корректный бинарный поток. Для человека удобным описанием изменений служит JSON, а не ручное редактирование байтов.

Не все уровни одинаково применимы к каждой версии метаданных. Документация разделяет CM v2.9 и CM v4.0: при генерации из XML для CM v2.9 поддерживаются L1, L2, L5 и L6, а CM v4.0 добавляет L3, L8, L9, L10 и L11. Это важно при переносе блоков: нельзя считать, что произвольный уровень можно безусловно добавить в любой RPU и получить совместимый результат.

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

Профили Dolby Vision и поддерживаемые входы

При извлечении RPU из HEVC заявлена поддержка профилей 4, 5, 7 и 8. Входом может быть сырой HEVC-битстрим с одним слоем и RPU, однодорожечный двухслойный поток BL+EL+RPU или отдельный Enhancement Layer с RPU. Кроме сырого HEVC, extract-rpu способен читать Matroska-файл, если в нём есть HEVC-видеодорожка. Это исключение не следует переносить на все команды: контейнерная поддержка зависит от конкретного действия.

Для практической обработки чаще всего встречаются сценарии Profile 7 с BL/EL/RPU и Profile 8.x с RPU в одном HEVC-потоке. Перед преобразованием полезно выяснить, есть ли Enhancement Layer и является ли он FEL или MEL, потому что выбор режима меняет судьбу маппинга. Особенно критичен переход из FEL-сценария к совместимому Profile 8.1: некоторые режимы намеренно убирают или нейтрализуют данные, которые нельзя считать эквивалентными полноценному двухслойному воспроизведению.

DoVi Tool не является средством смены контейнерного Dolby Vision профиля одной кнопкой. Даже если RPU преобразован, итоговый MKV или MP4 должен быть собран внешним мультиплексором с корректным видеопотоком и конфигурационными данными. Поэтому сообщение анализатора контейнера об одном профиле до обработки и другом после неё оценивают вместе со структурой HEVC и RPU, а не как единственный критерий успеха.

Режимы преобразования RPU

Глобальный параметр mode определяет, как RPU переписывается при поддерживаемых операциях. Режим 0 выполняет разбор и повторную запись без целевого преобразования содержимого. Режим 1 делает RPU совместимым с MEL. Режим 2 предназначен для совместимости с Profile 8.1 и в случае Profile 7 FEL убирает эффект маппинга, переводя кривые яркостного и цветового маппинга в нейтральное состояние. Это не равно извлечению полноценного FEL в новую картинку.

Режим 3 используется для преобразования Profile 5 к совместимому Profile 8.1, а режим 4 — к Profile 8.4. Режим 5 также ориентирован на Profile 8.1, но сохраняет маппинг там, где это предусмотрено его логикой. Между режимами 2 и 5 поэтому нельзя выбирать по принципу более высокий номер лучше: они решают разные задачи и по-разному обращаются с mapping coefficients.

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

Почему Profile 7 FEL требует осторожности

Full Enhancement Layer может содержать информацию, роль которой шире одних динамических метаданных. Когда режим преобразования делает RPU совместимым с Profile 8.1 и удаляет маппинг, полученный однослайный результат не становится математическим эквивалентом исходной двухслойной композиции. DoVi Tool корректно выполняет заявленное преобразование метаданных и HEVC-структуры, но не запекает FEL в пиксели базового слоя.

Отсюда следует практический выбор: если важно сохранить визуальный вклад FEL, нужен отдельный процесс, способный декодировать и объединить соответствующие данные в изображение перед новым кодированием. Если же задача — получить совместимый однослайный поток с RPU, режимы DoVi Tool подходят для управления метаданными, но результат оценивают как новый профиль с собственными ограничениями.

Нельзя проверять такой сценарий только тем, что медиаплеер показывает значок Dolby Vision. Значок подтверждает распознавание формата, но не доказывает эквивалентность мастер-изображения. Для технической проверки полезны структура RPU, число кадров, наличие нужных уровней и корректный контейнер; для визуальной — контрольные сцены на целевом устройстве.

Параметр crop и Level 5

Глобальный crop относится к активной области Dolby Vision, а не к обрезке пикселей видеокадра. Он устанавливает смещения active area в ноль. Это нужно, когда в итоговом изображении уже нет полос, которые описывались прежними Level 5 offsets. Если воспринимать этот ключ как обычный crop-фильтр, можно ошибочно ожидать изменения разрешения или удаления чёрных полей из HEVC; сама картинка при этой операции не кадрируется.

Редактор предоставляет более гибкое управление Level 5: можно задавать пресеты смещений и применять их к диапазонам кадров. Если L5 отсутствует, механизм active_area способен вставить этот уровень. Для drop_l5 есть варианты удаления всех L5 или только блоков с нулевыми offsets, однако документация предупреждает, что такое удаление способно сделать RPU несоответствующим спецификации. Поэтому это не косметическая оптимизация размера файла.

Типичный сценарий — исправление двойных чёрных полос, когда пиксели уже были обрезаны при перекодировании, а метаданные продолжают сообщать старую активную область. Правильная цепочка состоит в извлечении или подаче HEVC, применении корректировки L5 и проверке результата. Нужно заранее подтвердить, что пиксельный crop действительно сделан; иначе обнуление offsets может ухудшить поведение отображения.

drop-hdr10plus и границы этой опции

Параметр drop-hdr10plus позволяет при записи HEVC игнорировать HDR10+ метаданные. Это узкая операция над сопутствующими динамическими данными и не означает преобразование HDR10+ в Dolby Vision. Если исходник одновременно содержит Dolby Vision RPU и HDR10+ служебные блоки, ключ помогает получить выход без HDR10+ там, где это требуется выбранной цепочкой.

Использовать drop-hdr10plus по умолчанию не стоит. Совместимость с конкретным устройством, контейнером и дальнейшими инструментами определяет, нужно ли сохранять HDR10+. Удаление метаданных — необратимая операция относительно конкретного выходного файла, поэтому исходник лучше не перезаписывать. После обработки полезно проверять уже результирующий HEVC или контейнер отдельным анализатором.

Функция также не меняет базовый HDR-сигнал в пикселях. Она отвечает за отсутствие HDR10+ метаданных при записи. Если задача требует тонмаппинга HDR10+ или перекодирования изображения, это работа другого инструмента. Такое разграничение важно во всей DoVi Tool: многие ключи звучат как видеопреобразования, но фактически относятся к структуре метаданных и битстрима.

start-code: четыре байта или Annex B

Параметр start-code управляет формой стартовых кодов при выводе HEVC. По умолчанию используется вариант four, а альтернативой служит annex-b. Разница относится к представлению NAL units в элементарном потоке и нужна для совместимости с последующим инструментом. Это не выбор контейнера и не настройка кодека: на выходе по-прежнему работает HEVC-битстрим.

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

При передаче данных через pipe особенно важно понимать формат границы между программами. DoVi Tool поддерживает потоковый BL для mux и примеры совместного использования с FFmpeg, однако не всякая подкоманда допускает одинаковый режим ввода. Документированный pipe для одной операции не является обещанием потоковой работы для всех остальных.

Извлечение RPU командой extract-rpu

extract-rpu создаёт бинарный RPU из совместимого HEVC или MKV с HEVC-видеодорожкой. Параметр limit ограничивает число обрабатываемых кадров и удобен для короткой диагностики: можно проверить начало материала, не проходя полный фильм. Но тестовый RPU, созданный с limit, нельзя затем внедрять как будто он покрывает весь ролик — его длина намеренно меньше.

После извлечения первая проверка — info summary. Число RPU должно быть правдоподобно относительно числа кадров видео, профиль — соответствовать ожидаемому источнику, а файл не должен быть пустым. В этой операции команда завершается ошибкой, если вход не содержит RPU, и удаляет частично созданный результат, чтобы не оставлять вводящий в заблуждение файл. Тем не менее автоматический скрипт должен проверять код завершения, а не только существование имени.

Для MKV прямое чтение удобно, когда нужна только видеодорожка Dolby Vision. Если контейнер сложный или требуется строгий контроль конкретного track, внешний демультиплексор остаётся полезным: он делает выбор дорожки явным. Важно не смешивать эту возможность с обработкой аудио и субтитров — extract-rpu их не редактирует и не переносит в новый контейнер.

Внедрение RPU командой inject-rpu

inject-rpu помещает RPU NAL units в уже закодированный HEVC-поток. Это центральный шаг после внешнего перекодирования, когда требуется вернуть Dolby Vision метаданные. На вход подаются HEVC и отдельный RPU, а на выходе получается новый HEVC. Глобальные параметры преобразования не действуют на саму операцию внедрения, поэтому нужное преобразование RPU выполняют заранее или используют соответствующую HEVC-операцию, где оно поддерживается.

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

Флаг no-add-aud отключает добавление AUD NAL units между кадрами. Использовать его стоит только когда понятны требования следующего этапа. Сам по себе AUD не связан с художественными Dolby Vision значениями, но влияет на структуру потока. После внедрения проверяют не только наличие RPU, но и то, принимает ли выход следующий мультиплексор или декодер.

Удаление RPU и Enhancement Layer

Подкоманда remove удаляет Enhancement Layer и RPU, оставляя Base Layer HEVC. По умолчанию выход называется BL.hevc. Это удобно, когда из двухслойного Dolby Vision источника нужен только базовый видеопоток для отдельной дальнейшей обработки. Команда не создаёт SDR и не выполняет тонмаппинг; она меняет состав HEVC-данных, а не преобразует яркостную характеристику картинки.

В сценариях через pipe Base Layer можно сразу передавать дальше, но цепочка должна быть продумана по обработке ошибок. Если предыдущая программа завершилась аварийно, следующая может получить неполный поток. Для важных задач безопаснее сохранять промежуточный BL и проверять его, а потоковую схему применять после того, как команды протестированы на коротком образце.

remove также полезен как диагностический инструмент: сравнение структуры исходного HEVC и чистого BL помогает отделить проблему декодирования базового слоя от проблемы Dolby Vision слоёв или RPU. Но визуальное сравнение должно учитывать, что плеер может по-разному обрабатывать HDR10 базу и Dolby Vision композицию.

Разделение BL и EL командой demux

demux разделяет однодорожечный двухслойный HEVC на Base Layer и Enhancement Layer. Это не контейнерный demux в общем смысле: команда не раскладывает MKV на видео, звук, субтитры и главы. Её задача — Dolby Vision слои внутри HEVC. Поэтому перед ней часто стоит внешний этап, который извлекает нужную видеодорожку из контейнера.

Опция el-only позволяет получить только Enhancement Layer, когда Base Layer уже доступен отдельно или не требуется. Обычный режим создаёт оба слоя. Для входа без ожидаемых EL NAL команда сообщает ошибку и удаляет частично записанные файлы. Это полезно для автоматизации: отсутствие EL не должно тихо восприниматься как пустой, но корректный результат.

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

Сборка BL и EL командой mux

mux выполняет обратную к demux операцию: интерливит Enhancement Layer в Base Layer HEVC. BL может поступать из файла или потока, что удобно в цепочках с FFmpeg. Для EL указывается отдельный файл. Команда работает на уровне HEVC и не создаёт MKV или MP4 с аудио, поэтому финальная упаковка остаётся отдельным этапом.

Опция remove-eos удаляет EOS/EOB NAL units из обоих слоёв, если они присутствуют. no-add-aud отключает добавление AUD. Опция discard при mux отбрасывает EL и позволяет получить результат с RPU без сохранения enhancement layer; это близко к сценарию внедрения RPU, но без предварительного отдельного извлечения. Выбор зависит от того, какие слои нужно сохранить в финальном HEVC.

При сочетании mux с mode можно одновременно преобразовать RPU. Например, переход к Profile 8.1 при отбрасывании EL требует понимать, что именно делает выбранный режим с маппингом. Такой комбинированный вызов удобен, но сложнее для диагностики. Если результат критичен, безопаснее сначала проверить каждый этап отдельно на небольшом фрагменте, а затем объединить команды в один проход.

convert: преобразование структуры HEVC и RPU

convert применяет выбранный режим преобразования RPU при обработке HEVC. В двухслойном материале параметр discard позволяет отбросить Enhancement Layer. Это средство именно для совместимости Dolby Vision структуры; оно не перекодирует базовый слой новым видеокодеком и не улучшает качество изображения. Поэтому скорость операции и размер выходного файла нельзя интерпретировать как работу обычного энкодера.

Перед convert полезно сохранить исходную сводку RPU, а после — извлечь или проанализировать результирующие метаданные снова. Так видно, изменился ли профиль и какие уровни остались. Для FEL особенно важно понимать последствия нейтрализации mapping в режиме 2. Если нужен другой подход к маппингу, режим 5 рассматривают отдельно, а не как безусловную замену.

Если команда завершается ошибкой разбора, сначала исключают повреждённый или неподходящий HEVC, затем проверяют выбранный mode. Не стоит менять сразу несколько ключей и повторять запуск: при таком подходе трудно понять, что именно исправило проблему и не появилось ли побочное изменение метаданных.

Генерация RPU из Dolby Vision XML

generate может построить бинарный RPU из экспортированного Dolby Vision XML метаданных. Для CM v2.9 поддерживаются уровни L1, L2, L5 и L6; для CM v4.0 к ним добавляются L3, L8, L9, L10 и L11. Поддерживаются тримы как на уровне shot, так и для отдельных кадров. Генератор пригоден для восстановления RPU из структурированных мастер-метаданных, когда XML действительно соответствует видеоряду.

Для Level 5 при XML-генерации требуются размеры canvas. Active area offsets имеют смысл относительно геометрии кадра, поэтому неправильные canvas width и height нельзя считать безобидным параметром. Значения должны соответствовать тому видеопотоку, в который RPU затем будет внедряться.

XML-источник не отменяет контроль длины. Метаданные сцен и кадров должны совпадать с видеопоследовательностью. После generate полезно выполнить info summary, проверить число RPU и выборочно посмотреть несколько кадров на границах сцен. Так обнаруживаются ошибки диапазонов до внедрения в длинный HEVC.

Генерация RPU из JSON-конфигурации

JSON-генератор создаёт RPU профиля 8.1 или 8.4. В конфигурации можно выбрать CM v2.9 или CM v4.0, указать длину, исходные минимальные и максимальные PQ, Level 5, Level 6, наборы метаданных по умолчанию, shots и индивидуальные frame_edits. Для Profile 8.1 Level 6 обязателен, потому что он несёт fallback-значения мастер-дисплея и световых уровней.

Profile 8.1 рассчитан на HDR10 base layer, тогда как Profile 8.4 использует HLG base layer со статическим reshaping. Это не переключатель художественного вида; профиль должен соответствовать реальной базе. Если взять HEVC с HDR10 и механически сгенерировать RPU для 8.4, конфигурационная формальность не сделает базу HLG. Сначала определяют характер исходного видеосигнала, затем выбирают профиль метаданных.

В генераторе есть default_metadata_blocks, shots и frame_edits. Блоки по умолчанию применяются ко всей последовательности, shot задаёт диапазон сцены, а frame_edits позволяют переопределить метаданные конкретных кадров внутри shot. Такая иерархия удобна для больших роликов, но повышает риск конфликтов. Конфигурацию лучше строить от общего к частному и проверять кадры в местах, где вступают в силу переопределения.

Генерация по HDR10+ и madVR

DoVi Tool умеет использовать HDR10+ JSON и измерения madVR как источник для генерации RPU. В таких сценариях динамические измерения помогают сформировать Level 1 и связанные данные, а дополнительные параметры определяют профиль и остальные блоки. Это не означает, что HDR10+ и Dolby Vision идентичны: инструмент переводит доступную структуру измерений в предусмотренный генератором формат RPU.

Для HDR10+ предусмотрены варианты выбора источника пикового значения, включая histogram, histogram99 и max-scl, а также настройка max-scl-luminance. Выбор влияет на то, какие измерения используются как основа. Универсального значения, подходящего любому мастеру, нет: если материал уже имеет проверенную Dolby Vision разметку, повторная генерация из другого набора измерений может изменить творческий результат.

После такой генерации особенно важно не ограничиваться успешным кодом завершения. Проверяют число кадров, сцены, Level 1, Level 5/6 и совместимость профиля с базой. Если RPU должен использоваться в воспроизводимом релизе, нужен тест на целевой цепочке. Генератор обеспечивает технический механизм, но не заменяет мастеринг и не принимает художественные решения за пользователя.

Редактор RPU и JSON-конфигурация

editor принимает бинарный RPU и JSON с изменениями. Диапазоны кадров отсчитываются с нуля и включают обе границы: запись 0–39 относится к первым сорока кадрам. Это правило распространяется на удаление и другие операции с диапазонами. При переносе таймкодов из монтажной программы нужно сначала перевести их в точные номера кадров, иначе граница сцены легко сместится.

Конфигурация может задавать mode, remove_cmv4, remove_mapping, min_pq, max_pq, active_area, удаление и дублирование RPU, scene_cuts, Level 6, Level 9, Level 11, Level 255 и перенос выбранных уровней из другого RPU. Наличие поля в схеме не означает, что его нужно заполнять. Минимальный JSON с одним целевым изменением проще проверить и безопаснее повторить.

Редактор сначала выполняет удаление кадров, а затем операции дублирования. Поэтому индексы после этих шагов нельзя мысленно трактовать как независимые. Если нужно одновременно убрать кусок и вставить повтор метаданных, планируют итоговую последовательность заранее и проверяют длину. Для сложного монтажа полезно сначала отредактировать копию RPU и сравнить summary до и после.

Ограничения --edit-config при HEVC-операциях

Ту же JSON-конфигурацию можно подключать глобальным edit-config во время некоторых HEVC-операций, но этот путь ограничен. Внутри HEVC нельзя редактировать active area для произвольных диапазонов — поддерживается только правило all. Там же не поддерживаются удаление или дублирование RPU, изменение scene cuts и замена уровней из второго RPU. Эти различия важно учитывать при переносе готовой конфигурации из отдельного editor.

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

Для простой глобальной операции, например обнуления active area для всего потока или применения mode, edit-config во время HEVC-обработки может быть удобен. После выполнения всё равно проверяют выход, потому что успешный запуск подтверждает синтаксис и разбор, но не гарантирует, что выбранная логика соответствует исходному материалу.

Удаление CM v4.0 и mapping coefficients

remove_cmv4 удаляет из RPU CM v4.0 расширения, включая уровни L3, L8, L9, L10 и L11, а также связанные DM v2 данные и L254 согласно логике редактора. Это существенное изменение структуры, а не очистка лишних тегов. Если downstream-устройство или рабочий процесс опирается на эти уровни, после удаления оно уже не получит соответствующую информацию.

remove_mapping отдельно удаляет polynomial/MMR mapping coefficients. Такой флаг применяют только в тех сценариях, где точно понятна цель преобразования. Mapping связан с преобразованием между слоями и профилями; бездумное удаление может изменить смысл RPU. Для обычной проверки или экспорта метаданных этот ключ не нужен.

После удаления CM v4.0 полезно сравнить info summary и экспорт уровней. Если задача состояла в получении более простого совместимого набора метаданных, ожидаемые CM v4.0 уровни должны исчезнуть, а базовые данные остаться согласованными. При неожиданном исчезновении большего объёма информации сначала проверяют исходный RPU и конфигурацию, а не пытаются компенсировать результат дополнительными добавляющими флагами.

Level 6: мастеринг и fallback-поля

Level 6 содержит значения, связанные с mastering display и световыми характеристиками: максимальную и минимальную яркость мастер-дисплея, MaxCLL и MaxFALL. В editor существующий L6 можно заменить, а при отсутствии — создать. В generator для Profile 8.1 этот уровень обязателен. Числа должны происходить из достоверного мастеринга или измерений, а не подбираться по экрану пользователя.

MaxCLL и MaxFALL не являются настройками яркости телевизора. Это метаданные контента. Указание удобных или круглых значений может сделать файл структурно валидным, но фактически недостоверным. Поэтому при переносе RPU между версиями одного видео сверяют, что базовое HDR10 представление и L6 не противоречат друг другу.

Если исходный RPU уже содержит L6 и нет конкретной причины менять его, разумнее оставить значения как есть. Редактор позволяет замену, но сама доступность функции не является рекомендацией. В автоматическом пайплайне полезно выводить L6 до и после, чтобы случайная конфигурация не перезаписала метаданные сразу у десятков файлов.

Level 9 и Level 11

Level 9 описывает primaries мастер-дисплея. Редактор может заменить существующий L9, но операция имеет эффект только когда RPU уже поддерживает CM v4.0 структуру. Значение должно соответствовать допустимому перечислению, а не произвольной строке. Это поле не перекрашивает пиксели: оно меняет метаданные, которыми описывается мастеринг.

Level 11 содержит сведения о типе контента, whitepoint и reference mode flag. Для content_type определены категории Cinema, Games, Sports и User generated content. Это служебная классификация Dolby Vision метаданных, а не жанр в медиатеке. Если исходное значение неизвестно, придумывать категорию ради заполнения JSON не следует.

И L9, и L11 требуют особой осторожности при переносе между RPU. Если целевой RPU не содержит CM v4.0, простая замена может не сработать. Экспериментальная возможность переноса CM v4.0 расширений существует, но документация предупреждает о рисках совместимости. Для обычного восстановления лучше сохранять структуру, соответствующую исходным метаданным.

Перенос уровней из второго RPU

source_rpu позволяет использовать второй бинарный RPU как источник выбранных metadata levels. Для этого указывают абсолютный путь и список rpu_levels. После прохода remove длины обоих RPU должны совпадать. Такое требование защищает от очевидного сдвига, но одинаковая длина сама по себе не доказывает, что кадры действительно соответствуют друг другу.

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

При использовании source_rpu нельзя выполнять перенос прямо через ограниченный HEVC edit-config: эта возможность относится к полному editor. После замены удобно экспортировать только затронутые уровни в CSV или JSON и сравнить их с источником. Такой контроль значительно быстрее, чем изучать полный сериализованный RPU.

Экспериментальный перенос CM v4.0

allow_cmv4_transfer разрешает перенос уровней CM v4.0, включая L3, L8, L9, L10, L11 и L254, в RPU, который изначально был CM v2.9. При этом целевая структура фактически преобразуется к CM v4.0 и получает служебный L254. Документация подчёркивает, что это не обычный путь и возможны проблемы воспроизведения, особенно если не перенесены необходимые тримы L8.

Параметр add_cmv4_default_metadata также относится к продвинутым операциям: он добавляет набор стандартных CM v4.0 расширений, если их нет. Он помечен как unsafe и способен отключать часть CM v2.9 метаданных. Это инструмент для конкретной технической задачи, а не способ автоматически повысить качество RPU.

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

Scene cuts, удаление и дублирование кадров метаданных

Полный editor умеет менять scene_refresh_flag для заданных кадров или диапазонов, удалять RPU и дублировать метаданные выбранного кадра в указанной позиции. Эти операции нужны, когда видеомонтаж изменил последовательность кадров, но они не выполняют сам монтаж HEVC. Пользователь должен точно воспроизвести в RPU те же структурные изменения, которые уже произошли с видеорядом.

При удалении нескольких диапазонов важно помнить порядок и включённые границы. После удаления индексы последующих кадров сдвигаются. Дублирование выполняется после прохода удаления, поэтому source и offset нужно понимать в контексте уже изменённой последовательности. Для сложного EDL автоматический генератор JSON надёжнее ручного набора десятков диапазонов, но его результат всё равно проверяют на нескольких контрольных точках.

Scene cuts должны отражать реальные границы сцен метаданных. Искусственная установка флага на каждом кадре не является универсальным способом исправления. Если исходная разметка сцен доступна через export, её можно сравнить с монтажным списком и целенаправленно изменить только затронутые места.

Экспорт RPU в JSON, scenes и Level 5

export по умолчанию может сериализовать список RPU в JSON. Это подробное представление удобно для программного анализа, но для повседневной проверки часто слишком объёмно. Параметр data позволяет выбрать конкретные продукты экспорта: полный all, список кадров с scene_refresh_flag и Level 5 в формате JSON-конфигурации для editor.

Экспорт Level 5 особенно полезен для переноса active area: вместо ручного переписывания offsets можно получить структуру, которую понимает редактор. После экспорта всё равно проверяют диапазоны, потому что разные части фильма могут иметь разные полосы. Автоматическое применение одного глобального crop к материалу с меняющимся aspect ratio может быть неверным.

Список scenes даёт номера кадров, где начинается новая сцена по метаданным. Его удобно сопоставлять с результатом генерации или монтажа. Это не таймлайн с миниатюрами, но для скриптов такой список зачастую полезнее: он однозначно указывает индексы и позволяет строить проверки без графического интерфейса.

Экспорт отдельных metadata levels

Отдельная функция export позволяет выгружать выбранные extension metadata levels. Уровни задаются в формате level1, level2 и так далее, а выход может быть CSV или JSON. Для большого фильма это удобный способ сравнить определённый класс данных без сериализации всех полей каждого RPU.

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

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

Графики plot и что на них смотреть

plot создаёт PNG-график из RPU. Доступны типы L1, L2, L8, L8-saturation и L8-hue. Для L2 и L8 задаётся target nits из предусмотренного набора 100, 300, 600, 1000, 2000 или 4000. Можно ограничить диапазон стартовым и конечным кадром; конечный индекс включается. Это помогает изучать конкретную сцену вместо всего фильма.

Для творческих trim-графиков можно выбрать параметры slope, offset, power, chroma, saturation, ms, а для L8 также mid и clip. График не редактирует данные и не показывает финальный кадр; это визуализация числовых метаданных. Его удобно использовать для поиска мест, где трим резко изменился, после чего соответствующий кадр рассматривают через info.

Не стоит оценивать качество Dolby Vision только по гладкости кривой. Резкий переход может совпадать со сценой и быть полностью ожидаемым, а визуально неправильный трим может иметь плавные числа. plot ускоряет навигацию по метаданным, но художественную оценку оставляет пользователю и реальному воспроизведению.

Что DoVi Tool не делает с изображением

Утилита не имеет таймлайна, окна предпросмотра, инструментов обрезки по времени, склейки клипов или пиксельного crop. Параметры active_area описывают Dolby Vision Level 5 и не меняют сами пиксели. Также отсутствуют цветовые фильтры, стабилизация, шумоподавление, масштабирование, изменение частоты кадров и обычная коррекция экспозиции. Эти действия выполняются до или после работы с RPU другим ПО.

Нет и внутренних настроек видеокодека вроде CRF, bitrate, preset, GOP или аппаратного GPU-кодирования. DoVi Tool может быстро переписывать HEVC-структуру, но это не энкодинг картинки. Если итоговый файл меньше или больше, причина связана со слоями и служебными данными, а не с настройкой качества компрессии.

Такое ограничение полезно: программа не скрывает за одной кнопкой несколько независимых преобразований. Пользователь может отдельно контролировать энкодер и отдельно Dolby Vision метаданные. Недостаток — необходимость уверенно работать с несколькими инструментами и промежуточными файлами.

Аудио, субтитры и контейнеры

DoVi Tool не редактирует аудиодорожки и субтитры. Команды HEVC работают с видеобитстримом и Dolby Vision слоями. После обработки звук, субтитры, главы и вложения возвращают в MKV или другой контейнер внешним мультиплексором. Это особенно важно при сценарии извлечь из MKV — обработать — собрать: промежуточный HEVC не обязан содержать остальные дорожки.

Прямое чтение MKV в extract-rpu служит удобством для извлечения метаданных и не превращает программу в универсальный Matroska-редактор. Для выбора дорожек, копирования attachments и управления флагами контейнера по-прежнему применяют предназначенные для этого средства. В рабочей инструкции полезно называть каждый этап по его реальной функции, чтобы не ожидать от DoVi Tool сохранения того, что он вообще не обрабатывает.

При финальном mux контейнера следует проверить, что видеодорожка распознаётся как ожидаемый Dolby Vision профиль, а аудио и субтитры соответствуют исходной версии. Ошибка на этом этапе может быть не связана с RPU: неправильный track order, язык или default flag относятся к мультиплексору, а не к DoVi Tool.

Очередь, пакетная обработка и автоматизация

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

Надёжный batch-сценарий сначала анализирует вход, записывает summary и останавливается, если профиль или число кадров не соответствует ожиданию. Затем выполняется преобразование, после которого снова запускается проверка. Код завершения каждой команды должен учитываться явно. Простая проверка выходной файл существует недостаточна, особенно если скрипт может увидеть старый результат от предыдущего запуска.

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

GPU и производительность

DoVi Tool не предлагает выбор GPU, CUDA, Quick Sync, VideoToolbox или другого аппаратного энкодера, потому что не кодирует изображение. Скорость зависит от чтения и записи битстрима, разбора RPU, сложности операции и накопителя. На длинном HEVC значительная часть времени может уходить на последовательный ввод-вывод.

Если рабочая цепочка включает x265, NVEncC, QSVEncC или другой энкодер, GPU-настройки находятся в нём, а DoVi Tool подключается к готовому HEVC. Это позволяет менять видеокодер без смены логики RPU, пока сохраняется точное кадровое соответствие. При ускорении энкодера особенно важно не включить незаметно frame interpolation или изменение fps.

Пайпы уменьшают число временных файлов в тех операциях, где они поддерживаются, но усложняют повторную диагностику. При первой настройке процесса полезнее сохранить BL, EL или RPU, проверить их, а затем оптимизировать ввод-вывод. Производительность не должна достигаться ценой невозможности понять, на каком этапе испортилась структура.

Ошибки разбора и пустой результат

Сообщение об ошибке разбора означает, что ожидаемая структура не была полностью прочитана. Причиной может быть неподходящий вход, повреждение, обрезанный файл или конкретная комбинация режима и метаданных. Не следует автоматически считать любой HEVC с HDR Dolby Vision-совместимым входом: extract-rpu ожидает RPU, demux — Enhancement Layer, а разные подкоманды проверяют разные сущности.

Если после editor получается нулевая длина метаданных, сначала возвращаются к исходному RPU и минимальной конфигурации. В публичном отчёте о проблеме встречался случай, где после применения режима и active area лог показывал Final metadata length: 0. Это достаточный повод не заменять исходный файл и проверять длину после каждой сложной правки. В автоматизации нулевой выход должен считаться ошибкой даже при наличии созданного файла.

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

Ошибка failed to fill whole buffer

Сообщение failed to fill whole buffer указывает на то, что парсер не получил ожидаемый объём данных для продолжения разбора. Это не рекомендация увеличить системный буфер или память. В одном из реальных отчётов ошибка возникала при extract-rpu с режимом 1 для конкретного HEVC, тогда как извлечение без режима проходило. Такой пример показывает, что режим преобразования может выявить проблему, которой нет при простом чтении.

Диагностика начинается с запуска без mode, затем с info над извлечённым RPU. Если исходное чтение исправно, а ошибка появляется только при преобразовании, проблема локализуется в этой ветке. Если же без режима вход тоже не разбирается, сначала проверяют сам HEVC и способ его извлечения из контейнера.

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

Проверка результата после каждой операции

Минимальная проверка состоит из трёх пунктов: команда завершилась успешно, выход имеет ненулевой размер, info сообщает ожидаемую структуру. Для операций над HEVC дополнительно извлекают RPU из результата или анализируют контейнер после mux. Если менялась длина метаданных, количество RPU должно соответствовать заранее рассчитанному числу кадров.

При изменении Level 5 сравнивают offsets на контрольных кадрах; при изменении L6 — значения яркости; при переносе уровней — экспорт соответствующих blocks; при смене mode — профиль и mapping. Такой предметный контроль лучше универсальной фразы файл открывается. Плеер может проигрывать и структурно неправильный файл, игнорируя часть данных.

Для воспроизводимого сценария полезно хранить checksum исходного RPU и JSON-конфигурацию рядом с логом. Тогда можно точно повторить операцию и доказать, что исходные метаданные не менялись. Сам DoVi Tool не ведёт такую историю, поэтому её организует пользователь.

Безопасная работа с исходниками

DoVi Tool способен переписать структуру метаданных достаточно глубоко, поэтому исходный RPU и исходный HEVC лучше считать неизменяемыми. Все операции направляют в новые файлы. Это не из-за риска для системы, а из-за качества материала: ошибка в диапазоне или профиле может стать заметна только после финального mux и проверки на устройстве.

JSON-конфигурацию стоит хранить под отдельным именем, отражающим задачу: например, исправление L5, преобразование profile или перенос levels. Так проще увидеть, что именно применялось. Если один большой JSON одновременно меняет mode, active area, L6 и scene cuts, проверять его значительно труднее и откатывать частичные изменения невозможно без повторного запуска от исходника.

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

Windows, macOS и Linux

Готовые пакеты доступны для x64 Windows, ARM64 Windows, универсального macOS, x64 Linux и ARM64 Linux. На Windows это ZIP с исполняемым файлом; отдельный мастер установки не является частью такого релиза. Архитектуру выбирают по системе: x64 и ARM64 — разные бинарные сборки. На macOS универсальный пакет рассчитан на обе основные архитектуры.

На Linux релизные сборки используют musl, а при самостоятельной сборке документация упоминает fontconfig для стандартной поддержки шрифтов в графиках. Есть вариант сборки с внутренним шрифтом. Эти сведения относятся прежде всего к построению бинарника; пользователю готового архива важнее соответствие архитектуре и право файла на выполнение.

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

Что делать, если команда не найдена

На Windows сначала убеждаются, что архив распакован и dovi_tool.exe действительно находится в текущем каталоге. В PowerShell вызов файла из текущего каталога обычно начинается с .\. Если программа расположена в другом месте, указывают полный путь или добавляют каталог в PATH. Эти способы эквивалентны по функциям DoVi Tool; разница только в том, как оболочка находит бинарник.

На macOS и Linux проверяют разрешение на выполнение и путь. Если оболочка сообщает permission denied, это другая проблема, чем не найден файл. Не следует искать сторонний установщик, чтобы решить вопрос PATH: ошибка оболочки исправляется на уровне окружения, а не заменой программы.

После успешного запуска достаточно открыть общую справку и справку одной подкоманды. Это подтверждает, что исполняемый файл работает до обработки большого HEVC. Если даже --help не запускается, сначала решают проблему бинарника или системы и только потом анализируют Dolby Vision данные.

Как читать сообщения команды и логи

CLI выводит этапы вроде parsing, converting, editing и writing. Они полезны не как декоративный прогресс, а как указание, где остановилась операция. Если ошибка возникает сразу на parsing, JSON ещё мог не применяться. Если проблема появляется после converting или editing, вход уже разобран и поиск сужается к преобразованию.

В логах длинных задач стоит сохранять stderr и stdout. Тогда можно сопоставить код завершения с конкретным сообщением. В пакетной обработке это позволяет автоматически отделить файлы, где нет RPU, от файлов с ошибкой записи или некорректной конфигурацией. Объединять все случаи в один статус не получилось невыгодно для диагностики.

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

Работа с длинными файлами и диапазонами

RPU полнометражного фильма может содержать сотни тысяч кадров, поэтому ручная проверка каждого невозможна. DoVi Tool даёт инструменты для выборочной диагностики: summary, frame JSON, экспорт сцен и графики диапазона. Рациональный подход — сначала глобальные показатели, затем границы сцен и только потом проблемные кадры.

В editor диапазоны включительны, а в plot конечный frame также включается. Это упрощает сопоставление, но требует аккуратности при расчёте длины: диапазон 100–199 содержит сто кадров. Если список получен из другой системы с полуинтервальными диапазонами, его нельзя переносить напрямую без преобразования.

При больших RPU полезно избегать полного JSON-экспорта без необходимости. Экспорт отдельных levels или scenes быстрее читать и легче сравнивать. Полный all используют, когда нужна структура каждого блока или программная обработка всех метаданных.

Как различать метаданные и видеоконтент

Одна из типичных ошибок — ожидать, что изменение RPU само исправит пиксельную проблему. Например, active area сообщает, где находится полезное изображение, но не вырезает полосы. Level 6 описывает яркостные характеристики, но не меняет закодированные значения PQ. Profile conversion меняет совместимость метаданных, но не перекодирует базовый слой.

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

Такое разделение делает DoVi Tool сильным специализированным инструментом: он предоставляет точные операции там, где видеоредактор обычно скрывает детали. Но пользователь должен осознанно построить полный pipeline из декодирования, возможной обработки пикселей, кодирования, Dolby Vision метаданных и контейнеризации.

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

Программа	Лучше подходит для	Главное ограничение
DoVi Tool	Точной CLI-работы с RPU, BL/EL и HEVC Dolby Vision	Нет графического монтажа и контейнерной сборки с аудио
DoVi_Scripts	Готовых сценариев Dolby Vision вокруг набора внешних утилит	Рабочий процесс зависит от нескольких компонентов
DDVT	Автоматизации demux, RPU и гибридных Dolby Vision операций	Это оболочка над внешними инструментами, а не единый парсер
HDR-Multi-Tool	Графической очереди HDR10+ и Dolby Vision задач	Для низкоуровневой обработки опирается на dovi_tool и другие утилиты
DoViBaker	Запекания Dolby Vision обработки в видеокадры через AviSynth	Решает задачу обработки изображения, а не полноценного редактирования RPU/HEVC

Если требуется непосредственно разобрать или переписать RPU, извлечь его из HEVC, внедрить обратно либо разделить BL и EL, DoVi Tool даёт самый прямой низкоуровневый путь. DoVi_Scripts и DDVT удобнее там, где нужен готовый многошаговый workflow, HDR-Multi-Tool — когда важна графическая очередь, а DoViBaker — когда цель состоит в переносе Dolby Vision обработки в сами пиксели. Эти программы пересекаются по области HDR, но не являются одинаковыми заменами: выбор определяется тем, что именно должно измениться — метаданные, HEVC-слои, автоматизация или изображение.

Практические сценарии работы

Сохранить Dolby Vision после перекодирования HEVC

Сначала из исходного Dolby Vision видеопотока извлекают RPU и получают summary. Видеоряд затем перекодируют внешним HEVC-энкодером без изменения порядка кадров, частоты и геометрии. После кодирования сверяют число кадров и внедряют исходный или заранее преобразованный RPU в новый HEVC.

Главный риск — незаметное изменение кадровой последовательности энкодером или фильтрами. Если использовалась обрезка чёрных полос, вместе с ней нужно проверить Level 5. Если менялся профиль совместимости, преобразование RPU делают до inject-rpu и отдельно сохраняют результат.

После внедрения снова извлекают RPU из полученного HEVC, проверяют длину и профиль, а затем собирают контейнер с аудио и субтитрами внешним мультиплексором.

Получить Profile 8.1 из Profile 7 без EL

Исходный Profile 7 сначала анализируют, чтобы понять тип Enhancement Layer. Для перехода к однослайной совместимости используют режим, рассчитанный на Profile 8.1, и при необходимости отбрасывают EL. При FEL нужно учитывать, что mode 2 нейтрализует mapping и не переносит визуальный вклад FEL в пиксели BL.

Если важна максимальная близость к двухслойному мастеру, одних метаданных недостаточно; требуется отдельная обработка изображения. Если цель — совместимый однослайный HEVC с Dolby Vision RPU, проверяют профиль результата, L5/L6 и отсутствие неожиданного EL.

Финальный файл тестируют на целевом плеере и отдельно проверяют HDR10 fallback базового слоя. Значок Dolby Vision сам по себе не подтверждает эквивалентность FEL.

Исправить active area после физического crop

Сначала убеждаются, что чёрные полосы действительно удалены из пикселей нового видеоряда. Затем экспортируют или анализируют Level 5 исходного RPU. Если вся последовательность после crop имеет полную активную область, offsets можно обнулить глобально; при меняющемся формате используют диапазонные presets редактора.

Ошибка состоит в применении метаданных crop к видео, где полосы остались. DoVi Tool не меняет изображение и не способен проверить это визуально, поэтому решение основывают на реальном геометрическом преобразовании, выполненном раньше.

Контроль включает кадры до и после смены aspect ratio, summary и тест воспроизведения. Если полосы появляются только на части сцен, проверяют диапазоны L5, а не повторяют глобальный crop.

Извлечь только RPU из MKV

Если MKV содержит HEVC Dolby Vision видеодорожку, extract-rpu может прочитать контейнер напрямую. Это сокращает один шаг, когда не нужен отдельный HEVC. После извлечения сразу выполняют summary и убеждаются, что профиль и число кадров соответствуют ожидаемому треку.

В контейнере с несколькими видеодорожками или необычной структурой удобнее сначала явно демультиплексировать нужный track внешним инструментом. Аудио, субтитры и главы DoVi Tool при прямом чтении MKV не обрабатывает.

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

Разделить BL и EL для диагностики

Из контейнера получают подходящий HEVC, затем demux создаёт Base Layer и Enhancement Layer. Такой разбор полезен, когда нужно отдельно изучать EL, использовать BL в энкодере или проверить, присутствует ли ожидаемая двухслойная структура.

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

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

Создать RPU из Dolby Vision XML

При наличии мастер-XML используют generate и задают параметры, необходимые источнику. Для Level 5 важны canvas width и height, а поддерживаемые metadata levels зависят от версии CM. Shots и frame trims должны соответствовать видеопоследовательности.

После генерации проверяют профиль, длину и несколько сцен. Если XML относится к другому кадрированию или монтажу, технически успешная генерация не делает метаданные подходящими для текущего HEVC.

RPU внедряют только после подтверждения соответствия. Финальный контейнер и звук собираются отдельными средствами.

Сгенерировать Profile 8.1 RPU из JSON

В JSON задают профиль 8.1, версию CM, длину и Level 6, который обязателен для такого профиля. Level 5 можно задать явно; при отсутствии генератор добавляет нулевые offsets. Метаданные по умолчанию дополняются shots и точечными frame_edits.

Нельзя подставлять произвольные MaxCLL, MaxFALL и mastering luminance только ради прохождения валидации. Эти числа должны описывать реальный мастер или выбранную базу. Ошибочная конфигурация может быть синтаксически правильной, но содержательно неверной.

Перед внедрением экспортируют или просматривают несколько RPU и проверяют границы shots. Это особенно важно при длинном JSON с многочисленными переопределениями.

Перенести один metadata level из другой версии RPU

Полный editor позволяет указать source_rpu и список уровней для замены. Сначала добиваются одинаковой длины после любых remove операций и подтверждают покадровое соответствие двух источников. Затем переносят только действительно нужный level.

Перенос всех доступных уровней на всякий случай разрушает преимущество точечной правки и может незаметно заменить корректные данные. CM v4.0 уровни требуют дополнительного внимания к структуре целевого RPU.

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

Синхронизировать RPU после вырезанного фрагмента

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

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

Контрольные кадры берут по обе стороны каждого стыка. В финальном HEVC RPU должен начинать новую сцену именно там, где начинается соответствующее изображение.

Синхронизировать RPU после дублированных кадров

Операция duplicate копирует метаданные source frame и вставляет заданное число RPU в offset. Она применяется после прохода удаления. Такой механизм подходит для детерминированного повторения кадров, когда известно, какие изображения были продублированы.

Он не является универсальной коррекцией новой частоты кадров. При сложной интерполяции создаются новые изображения, которым старые RPU могут не соответствовать. В таком случае повторение ближайшего metadata frame — техническое приближение, а не подтверждённый мастеринг.

После duplicate сравнивают итоговую длину с видео и проверяют точки входа и выхода из вставки. Ошибка на один кадр затем сдвинет все последующие метаданные.

Построить график L1 для поиска переходов

Из исходного RPU строят L1 plot на всём фильме или на выбранном диапазоне. График помогает увидеть сцены с резкими изменениями brightness metadata и найти номера кадров для дальнейшего анализа.

Резкий скачок сам по себе не ошибка: он может совпасть с монтажным переходом. Поэтому найденный участок сравнивают со списком scenes и выводом info для конкретных кадров. Для L2/L8 дополнительно выбирают целевую яркость и интересующие trim параметры.

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

Удалить Dolby Vision данные и оставить BL

Когда нужен только Base Layer, remove удаляет EL и RPU и создаёт BL.hevc. Это удобно для последующего HDR10-процесса или диагностики базовой картинки. Операция не преобразует HDR в SDR и не делает тонмаппинг.

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

Если результат выглядит иначе при воспроизведении, это ожидаемо: плеер больше не применяет Dolby Vision путь. Сравнивать нужно с HDR10 fallback, а не требовать идентичности DV-композиции.

source_min_pq и source_max_pq в генераторе

В JSON-генераторе source_min_pq и source_max_pq задают исходные границы PQ, если их нужно переопределить. Когда они не указаны, значения могут выводиться из Level 6. Эти параметры относятся к описанию источника метаданных и не являются настройками чёрной и белой точки дисплея пользователя.

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

Если цель состоит только в воспроизведении существующего мастер-RPU, менять source_min_pq и source_max_pq не нужно. Минимальное количество вмешательств снижает риск того, что технически допустимая конфигурация изменит поведение тонального отображения.

Default metadata blocks, shots и frame_edits

Генератор разделяет общие и локальные данные. default_metadata_blocks относятся к последовательности в целом, shots задают набор метаданных для сцен, а frame_edits позволяют заменить блоки для конкретного кадра внутри shot. Такая модель удобна, когда большая часть материала использует общие настройки, а отдельные сцены требуют собственных значений.

Для HDR10+ и madVR источников порядок shots имеет особое значение: метаданные сопоставляются со сценами в порядке списка, а отсутствующие или лишние shots могут быть проигнорированы. Поэтому перед генерацией нужно удостовериться, что анализ источника и JSON описывают одну и ту же последовательность сцен.

Крупный конфигурационный файл лучше проверять по слоям. Сначала генерируют базовый вариант, затем добавляют shots, затем frame_edits. После каждого этапа сравнивают длину и несколько кадров. Такой процесс быстрее обнаруживает конфликт, чем разбор результата, где одновременно задействованы десятки уровней и сотни переопределений.

Автоматическое добавление Level 5

В генераторе Level 5 является опциональным; если он не задан, могут использоваться offsets, равные нулю. В editor active_area также способен вставить L5, если этого уровня не было. Эти две возможности удобны, но не означают, что нулевая активная область всегда является правильным описанием видео.

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

При переменном aspect ratio отсутствие корректной покадровой или сценовой разметки L5 особенно заметно. В таком материале предпочтительнее сохранить или восстановить исходные диапазоны active area, а не применять одно глобальное правило ко всему фильму.

drop_l5: почему это не очистка мусора

В editor поле drop_l5 может удалять все Level 5 блоки или только блоки, у которых все offsets равны нулю. Документация отдельно предупреждает, что такой результат может не соответствовать спецификации. Следовательно, уменьшение количества метаданных само по себе не является достоинством.

Опция может быть полезна в экспериментальном или строго определённом workflow, где downstream-компонент ожидает конкретную структуру. Для обычного исправления active area безопаснее редактировать offsets, сохраняя требуемый Level 5, чем удалять блок полностью без необходимости.

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

Level 6 при редактировании и генерации

Редактор Level 6 умеет заменить значения существующего блока или создать его, если блока не было. Это полезно при восстановлении согласованных fallback-данных, но требует точных чисел: max_display_mastering_luminance, min_display_mastering_luminance, MaxCLL и MaxFALL не должны браться из настроек телевизора или из субъективного впечатления.

При генерации Profile 8.1 наличие Level 6 является обязательным условием конфигурации. Если мастер-данные отсутствуют, лучше сначала определить достоверный источник значений, чем подставлять произвольные числа ради создания файла.

После изменения L6 важно сравнить итог с базовым HDR10 слоем и контейнерным анализом. Непротиворечивость метаданных между уровнями и самой базой важнее того, что каждый отдельный JSON-параметр синтаксически допустим.

Особенности Level 9

Level 9 относится к mastering display primaries. Редактор может заменить это значение только в RPU, где уже присутствует структура CM v4.0. Если целевой RPU остаётся CM v2.9, одно добавление поля level9 в конфигурацию не превращает его автоматически в CM v4.0.

Параметр принимает значение из определённого перечисления, а стандартный вариант редактора связан с DCI-P3 D65. Менять primaries следует только когда известно, какие primaries описывают исходный мастер. Это метаданные о мастер-дисплее, а не команда по преобразованию цветового пространства пикселей.

После замены Level 9 имеет смысл проверить summary, который умеет показывать соответствующие primaries, и при необходимости экспортировать уровень. Если картинка требует реального преобразования gamut, его выполняют до кодирования другим инструментом.

Особенности Level 11

Level 11 содержит content type, whitepoint и reference mode flag. Значения content type имеют определённые категории, включая Cinema, Games, Sports и User generated content. Эти категории не должны выбираться по названию файла или жанровой метке медиатеки.

Как и Level 9, замена L11 рассчитана на CM v4.0 RPU. Если структура отсутствует, сначала нужно понимать, зачем вообще требуется её создавать. Экспериментальные функции переноса CM v4.0 существуют, но сопровождаются предупреждениями, поэтому рутинной нормализацией их считать нельзя.

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

Level 255 и служебные расширения

Схема editor допускает работу с Level 255 как с расширенным блоком. Это низкоуровневая возможность для пользователей, которые понимают структуру Dolby Vision метаданных. В повседневной задаче извлечения, конвертации профиля или исправления active area заполнять Level 255 не требуется.

Отдельно в CM v4.0 присутствуют служебные extension blocks, включая L254, которые участвуют в структуре переноса и добавления CM v4.0. Их нельзя воспринимать как произвольное поле для пользовательской заметки: значения имеют спецификационный смысл.

Если цель не формулируется в терминах конкретного metadata level, безопаснее не менять эти блоки. DoVi Tool предоставляет доступ, но ответственность за смысл данных остаётся на конфигурации пользователя.

Флаг remove-eos при mux

remove-eos удаляет EOS/EOB NAL units из BL и EL во время mux, если такие элементы присутствуют. Это структурная настройка HEVC, полезная для определённых цепочек совместимости. Она не влияет на творческие Dolby Vision значения и не меняет сами кадры.

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

После изменения NAL-структуры проверяют, что выход целиком читается декодером и что количество RPU соответствует длине. Успешный mux не освобождает от проверки конечного контейнера.

Флаг no-add-aud

В mux и inject-rpu доступен no-add-aud, который запрещает добавлять Access Unit Delimiter NAL units между кадрами. AUD относится к структуре HEVC access units, а не к содержанию RPU. Поэтому включение или отключение этого флага не должно использоваться как способ исправления неверного профиля или Level 5.

Если downstream-инструмент предъявляет конкретные требования к AUD, режим выбирают в соответствии с ними. В противном случае лучше придерживаться штатного поведения команды и не добавлять лишних различий между тестами.

При сравнении двух результатов важно помнить, что бинарные файлы могут различаться из-за AUD, оставаясь одинаковыми по динамическим метаданным. Для анализа Dolby Vision в таком случае сравнивают извлечённый RPU, а не только полный checksum HEVC.

Флаг discard и судьба Enhancement Layer

discard используется в операциях, где требуется отбросить Enhancement Layer. В mux это позволяет не сохранять EL при сборке, а в convert — формировать результат без дополнительного слоя согласно выбранной логике. Такой шаг особенно важен при подготовке однослайного варианта.

Отбрасывание EL необратимо для конкретного выходного файла: информацию слоя нельзя восстановить из BL и RPU. Поэтому оригинальный двухслойный HEVC сохраняют. Для FEL нужно отдельно учитывать, что визуальный вклад enhancement layer не превращается автоматически в пиксели базового слоя.

Если пользователь сомневается, нужен ли EL, полезно сначала сделать demux и изучить структуру, а затем принять решение. Экономия места не должна быть единственным критерием, когда цель — сохранить максимально близкое к источнику Dolby Vision представление.

Параметр limit как инструмент диагностики

extract-rpu может остановиться после заданного числа кадров с помощью limit. Это удобно для быстрой проверки начала большого файла, воспроизведения ошибки на коротком диапазоне или теста синтаксиса команды. Уменьшенный RPU создаётся намеренно и не соответствует полной длительности.

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

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

Невалидный вход и частичные файлы

При extract-rpu вход без RPU должен завершаться ошибкой, а при demux вход без Enhancement Layer также считается невалидным для заявленной операции. Поведение с удалением частично записанных файлов важно для автоматизации: наличие старого результата в каталоге не должно маскировать ошибку нового запуска.

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

Если вход невалиден только для одной команды, это не обязательно означает повреждение видео. Например, однослайный Profile 8 может быть корректным, но не содержать EL для demux. Ошибка тогда говорит о неверно выбранной операции, а не о качестве HEVC в целом.

Проверка CM v2.9 и CM v4.0 после преобразований

После операций remove_cmv4, переноса levels или добавления CM v4.0 важно заново определить структуру RPU. Не следует судить о ней только по имени конфигурации. Summary и экспорт показывают, какие уровни фактически присутствуют после записи.

Если целевой workflow требует CM v2.9, отсутствие L3/L8/L9/L10/L11 после удаления ожидаемо. Если нужен CM v4.0, наоборот, проверяют присутствие необходимых extension metadata и не полагаются на один служебный блок.

Такая проверка особенно важна при комбинировании mode и editor. Две операции могут быть каждая допустима по отдельности, но вместе дать структуру, отличную от ожидаемой. Минимальные пошаговые тесты позволяют увидеть момент изменения.

Согласование RPU с новым энкодом

Самый надёжный новый encode для повторного использования RPU сохраняет кадры один к одному: тот же порядок, то же число кадров и та же геометрия, если Level 5 остаётся неизменным. Параметры компрессии, битрейт или аппаратный энкодер могут отличаться, пока не меняют временную структуру.

Фильтры deinterlace, decimate, frame interpolation, trim, splice и resize требуют отдельной оценки. Resize может не менять число кадров, но влияет на геометрию active area; trim и splice меняют индексы; интерполяция создаёт новые кадры. Нельзя объединять все эти случаи под формулой видео такое же по длительности.

Перед inject-rpu целесообразно получить независимое число кадров от нового HEVC и сравнить с RPU. После внедрения повторное извлечение подтверждает, что метаданные действительно прошли в выходной поток.

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

Можно ли DoVi Tool использовать как обычный видеоконвертер?

Нет. Команды convert и mux работают со структурой Dolby Vision RPU и HEVC, но не предоставляют настройки кодека, разрешения, битрейта или качества. Для перекодирования изображения нужен отдельный энкодер.

Есть ли предпросмотр кадра?

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

Обрезает ли crop чёрные полосы?

Нет. Этот параметр обнуляет Dolby Vision active area offsets в Level 5. Пиксели HEVC не обрезаются, а разрешение кадра не меняется.

Можно ли работать с MKV напрямую?

extract-rpu умеет читать MKV с HEVC-видеодорожкой. Остальные контейнерные задачи, включая перенос аудио и субтитров, выполняются внешними средствами.

Что проверять после extract-rpu?

Ненулевой размер RPU, код завершения, число кадров, профиль и summary. Для важного материала полезно проверить несколько конкретных кадров через info.

Можно ли внедрить RPU после изменения fps?

Прямое внедрение безопасно только при сохранённом покадровом соответствии. Изменение fps, decimate или интерполяция требуют отдельного решения по синхронизации метаданных.

Зачем нужен Level 5?

Он содержит active area offsets. Эти данные описывают активную область кадра и важны, когда геометрия или чёрные полосы меняются между исходником и результатом.

Что делает Level 6?

Он содержит fallback-поля mastering display и световые значения, включая MaxCLL и MaxFALL. В генерации Profile 8.1 этот уровень обязателен.

Можно ли удалить CM v4.0?

Да, editor имеет remove_cmv4, но это удаляет целую группу расширенных метаданных. Использовать операцию следует только с понятной целью и проверкой результата.

Можно ли добавить CM v4.0 в CM v2.9 RPU?

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

Чем mode 2 отличается от mode 5?

Оба могут использоваться для совместимости с Profile 8.1, но по-разному обращаются с mapping. Mode 2 нейтрализует mapping для соответствующего сценария, тогда как mode 5 рассчитан на его сохранение.

Нужен ли GPU?

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

Есть ли очередь заданий?

Встроенной графической очереди нет. Серии файлов обрабатывают скриптом оболочки, проверяя каждый код завершения и summary.

Можно ли редактировать аудио?

Нет. DoVi Tool не меняет аудиодорожки, их кодек, громкость или синхронизацию.

Можно ли перенести субтитры?

Нет. Субтитры возвращают в финальный контейнер внешним мультиплексором.

Почему output может быть пустым?

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

Что означает индекс 0?

Это первый кадр. Диапазоны редактора начинаются с нуля и включают обе границы.

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

Только если доказано покадровое соответствие. Даже одинаковая длительность не гарантирует одинаковый монтаж.

Зачем экспортировать scenes?

Чтобы получить индексы кадров с scene_refresh_flag и сопоставить границы сцен с генерацией, монтажом или диагностикой.

Что лучше сохранить для повторяемости?

Исходный RPU, JSON-конфигурацию, лог команды и контрольную сводку. Такой набор позволяет повторить обработку без догадок.

Итоговый порядок проверки

Надёжный процесс строится от анализа к минимальному изменению: определить профиль и структуру входа, сохранить исходный RPU, проверить summary, выбрать ровно одну необходимую операцию, выполнить её в новый файл и снова проверить метаданные. Только после этого RPU внедряют в HEVC или собирают BL/EL, а финальный контейнер формируют внешним мультиплексором.

Для задач с перекодированием дополнительно подтверждают неизменность кадровой последовательности. Для crop проверяют реальную геометрию изображения и Level 5, для Profile conversion — назначение mode и mapping, для переноса levels — соответствие второго RPU, для генерации — происхождение мастер-данных. Такой контроль предотвращает ошибки, которые иначе обнаруживаются только при воспроизведении готового фильма.

Отдельная проверка нужна после любого шага, который меняет не только содержимое RPU, но и структуру HEVC. Сначала сравнивают количество кадров и профиль Dolby Vision, затем смотрят summary и нужные уровни метаданных, после чего проверяют, что выбранный контейнерный мультиплексор не изменил порядок видеокадров. Если результат предназначен для дальнейшего кодирования, RPU лучше сохранить как отдельный контрольный файл: так можно повторно внедрить те же метаданные без повторного извлечения и отличить ошибку энкодера от ошибки конфигурации DoVi Tool. Для автоматизированной цепочки полезно также сохранять код завершения команды и не заменять успешную проверку простым фактом существования выходного файла.

DoVi Tool особенно силён тогда, когда его используют по назначению: как точный инструмент для Dolby Vision RPU и HEVC, а не как замену видеоредактору или энкодеру. Командный интерфейс требует дисциплины, зато оставляет каждое преобразование явным, воспроизводимым и проверяемым по метаданным.