VVenC позволяет кодировать видео в H.266/VVC, задавать баланс скорости и сжатия пресетами, работать с фиксированным QP и VBR, управлять многопоточностью, HDR/SDR-сигнализацией и структурой потока, а для сложных сценариев использовать двухпроходный контроль битрейта и расширенные параметры vvencFFapp.

Основной инструмент для повседневного кодирования — vvencapp: он принимает необработанный YUV или Y4M, формирует элементарный поток VVC и скрывает значительную часть внутренних настроек за пятью пресетами. Когда требуется тонко задавать параметры последовательности, VUI, структуру случайного доступа или исследовательские инструменты кодека, применяется vvencFFapp с конфигурационными файлами и расширенным набором опций.

Работа строится вокруг точно описанного входного сигнала. Для RAW YUV необходимо указать разрешение, частоту кадров и формат выборок; Y4M уже несёт часть этих сведений в заголовке. Поэтому успешное кодирование зависит не только от выбранного QP или битрейта, но и от корректной интерпретации исходных пикселей, цветовых характеристик, временной шкалы и параметров вывода.

Что именно делает VVenC

VVenC — программный энкодер стандарта H.266/VVC. Его задача — получить последовательность видеокадров и сжать её в VVC-битстрим. В типичном сценарии исходные кадры поступают как YUV 4:2:0 или Y4M, после чего энкодер выполняет межкадровый и внутрикадровый анализ, принимает решения о разбиении блоков и предсказании, применяет преобразование и квантование, петлевые фильтры и другие инструменты VVC, а затем записывает закодированные единицы доступа в файл.

Это важно отличать от функций монтажной программы или универсального конвертера. VVenC не предназначен для нарезки роликов по тайм-линии, микширования аудио, наложения титров, цветокоррекции фильтрами или сборки проекта из дорожек. Необработанное видео обычно подготавливают другим инструментом, а полученный VVC-поток при необходимости помещают в контейнер отдельным мультиплексором. Такое разделение делает энкодер удобным компонентом автоматизированной цепочки, но требует понимать, где заканчивается задача VVenC и начинается работа FFmpeg, MP4Box или иного инструмента обработки контейнеров.

В настройках есть два уровня. На первом пользователь выбирает пресет, QP либо целевой битрейт, частоту обновления, режим SDR/HDR, число потоков и несколько дополнительных параметров. На втором уровне доступны практически все длинные параметры экспертного приложения — непосредственно через vvencFFapp или строку --additional в vvencapp. Благодаря этому один и тот же энкодер подходит и для короткой команды, и для воспроизводимого исследовательского эксперимента с большим конфигурационным файлом.

vvencapp и vvencFFapp: какой исполняемый файл выбирать

vvencapp рассчитан на сценарии, где важны предсказуемые базовые параметры. Его пять пресетов уже содержат согласованный набор внутренних переключателей, а названия опций сделаны компактными: --input, --size, --fps, --preset, --qp, --bitrate, --threads. Для большинства кодирований это предпочтительная отправная точка, потому что менять сразу десятки низкоуровневых инструментов без необходимости обычно сложнее, чем подобрать подходящий пресет и режим контроля качества.

vvencFFapp — полнофункциональный экспертный интерфейс, построенный вокруг схемы конфигурации VTM. У него другие имена части параметров: например, вход задаётся как --InputFile, выход — как --BitstreamFile, целевой битрейт — как --TargetBitrate, а QPA — как --PerceptQPA. Существенно и то, что значения по умолчанию у двух приложений могут отличаться. Поэтому перенос команды не должен сводиться к механической замене имени исполняемого файла.

Для экспертного запуска используются готовые конфигурации из каталога cfg. Файлы randomaccess_faster.cfg, randomaccess_fast.cfg, randomaccess_medium.cfg, randomaccess_slow.cfg и randomaccess_slower.cfg соответствуют пяти пресетам случайного доступа. sequence.cfg содержит параметры конкретной последовательности, qpa.cfg включает перцептуальную адаптацию, а rc1p.cfg и rc2p.cfg используются для одно- и двухпроходного контроля скорости. Команда вида vvencFFapp -c randomaccess_medium.cfg -c sequence.cfg загружает несколько файлов последовательно, поэтому порядок и содержимое конфигураций имеют значение.

Как посмотреть доступные параметры

Краткая справка вызывается через --help или -h, а полный список — через --fullhelp. Второй вариант особенно полезен при работе с --additional и vvencFFapp, потому что показывает не только базовые настройки, но и экспертные параметры, зависимости и допустимые значения. При переносе старой командной строки разумно сверять именно вывод той сборки, которой будет выполняться кодирование: набор доступных опций может быть шире, чем список в краткой справке.

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

Подготовка входного видео

Нативный рабочий материал VVenC — последовательность YUV или поток Y4M. Обычный MP4, MKV или MOV нельзя просто передать в -i так же, как универсальному декодеру: сначала контейнер и сжатый исходный кодек должны быть декодированы в кадры. На практике эту роль часто выполняет FFmpeg, VapourSynth или другой внешний источник кадров. Такая схема полезна тем, что декодирование, фильтрацию и масштабирование можно выполнить до энкодера, не смешивая их с настройками VVC.

У RAW YUV нет полноценного самодостаточного заголовка. Сам файл представляет собой последовательность выборок, поэтому энкодеру нужно сообщить, как их трактовать. Минимально проверяют ширину и высоту, частоту кадров и формат — 8- или 10-битный 4:2:0. Если один из этих параметров ошибочен, кодирование может формально стартовать, но кадры будут прочитаны с неверными границами или временными характеристиками. Типичный визуальный признак неправильного размера или глубины — перемешанное изображение после декодирования результата.

Y4M удобнее, когда промежуточный поток можно сформировать с заголовком YUV4MPEG2. VVenC умеет извлекать из такого входа ключевое описание последовательности, поэтому для файла input.y4m достаточно значительно более короткой команды. При передаче Y4M через стандартный ввод нужно явно добавить --y4m, чтобы энкодер не считал поступающие байты обычным RAW YUV.

RAW YUV: обязательные параметры

Для 8-битного YUV 4:2:0 базовая форма выглядит так: vvencapp -i input.yuv -s 1920x1080 --fps 50/1 -o output.266. Параметр -s задаёт размер кадра, --fps — временную частоту дробью, а формат без дополнительной опции соответствует yuv420. Для 10-битного входа применяют --format yuv420_10 или краткую форму -c yuv420_10.

Не следует путать глубину входных выборок и внутреннюю глубину кодирования. В простом приложении параметр --internal-bitdepth управляет внутренней глубиной, тогда как --format описывает фактический расположенный на диске материал. Если 10-битный файл объявить 8-битным, чтение байтов станет неверным независимо от того, какая внутренняя глубина указана позже.

Y4M: меньше ручных описаний

Для Y4M базовый пример — vvencapp -i input.y4m -o output.266. Заголовок Y4M содержит сведения, которые для сырого YUV пришлось бы указывать вручную. Это снижает риск перепутать разрешение и частоту кадров и делает файл удобнее для обмена между этапами конвейера. Однако параметры цветовой сигнализации VVC всё равно стоит задавать осознанно: наличие пиксельных данных и знание размера кадра не заменяют корректной настройки SDR, HDR, VUI и диапазона.

При работе без промежуточного файла внешний декодер может писать Y4M в stdout, а VVenC читать stdin. В таком случае вход обозначают дефисом: -i -, дополнительно указывая --y4m. Это экономит место на диске, но влияет на доступность сценариев, которым нужен повторный проход по исходнику. Двухпроходное кодирование проще организовывать с входом, который можно гарантированно перечитать с теми же кадрами и временными метками.

Частота кадров и дробные значения

Для целого FPS можно использовать --framerate или -r. Если источник имеет 23.976, 29.97 или 59.94 кадра в секунду, точнее задавать отношение через --fps: например, 24000/1001, 30000/1001 или 60000/1001. Внутренне частота участвует не только в временной сигнализации, но и в вычислении выходного битрейта, поэтому ошибка здесь отражается на режиме rate control.

Альтернативой служит пара --framerate и --framescale, где второй параметр является знаменателем. Однопараметрическая запись --fps числитель/знаменатель обычно менее подвержена опечаткам. Для корректной временной базы важнее сохранить точное рациональное отношение, чем записать округлённое десятичное значение.

Если энкодер сообщает ошибку, связанную с TicksPerSecond и дробной частотой, не стоит подбирать произвольное большое число. Требование состоит в согласовании временной шкалы с frame rate/frame scale. Для стандартных телевизионных частот документация и диагностическое сообщение могут предложить подходящее значение; его следует применять вместе с точной дробью FPS.

Первое кодирование с vvencapp

Для проверки цепочки полезно начинать с короткого файла и минимального числа опций. Например: vvencapp --preset medium -i input.yuv -s 1920x1080 --fps 25/1 -q 32 -o test.266. Здесь явно заданы вход, геометрия, временная частота, пресет и QP. Если команда завершается успешно, можно добавлять QPA, цветовую сигнализацию, ограничения битрейта и остальные параметры по одному.

Во время старта VVenC печатает описание входа и ключевые параметры. В строке Real Format стоит проверить разрешение, формат выборок, FPS, SDR/HDR и число кадров. Затем выводятся сведения о режиме rate control, QPA, периоде обновления и конфигурации параллелизма. Эти строки удобнее воспринимать как фактическую расшифровку команды: если ожидается 10-битный вход, а журнал говорит yuv420p, проблему лучше исправить до длинного прогона.

После кодирования итоговая статистика показывает число кадров, средний битрейт, показатели PSNR для компонентов и общую скорость обработки. Эти значения полезны для проверки воспроизводимости и выявления грубых ошибок, но сами по себе не доказывают субъективное качество. В частности, одинаковый средний PSNR не означает, что два пресета или два способа распределения QP будут визуально идентичны.

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

Заголовок сообщает имя приложения и параметры сборки. Далее блоки CODING TOOL CFG, ENC. ALG. CFG, PRE-ANALYSIS CFG, FAST TOOL CFG, RATE CONTROL CFG и PARALLEL PROCESSING CFG раскрывают, какие группы инструментов реально активированы. Такой вывод особенно полезен при сравнении пресетов: он показывает, что пресет — не магическое число скорости, а связанный набор решений по инструментам кодека и алгоритмам поиска.

Сокращения вроде ALF, CCALF, SAO, MCTF, DMVR, GPM, MIP, ISP или AFFINE относятся к инструментам и стратегиям кодирования. Для обычной эксплуатации не требуется вручную регулировать каждый переключатель. Практически важнее заметить крупные вещи: какой CTU и пресет выбран, включена ли QPA, сколько потоков и параллельных кадров используется, активен ли rate control и какой тип обновления выставлен. Детальная расшифровка нужна, когда пользователь намеренно отходит от пресетов в экспертном режиме.

Строки по отдельным POC показывают тип изображения, temporal id, QP и объём данных кадра. Они помогают увидеть, насколько неравномерно распределяется битрейт и какие кадры оказываются дорогими. Но для длинного материала такой лог может быть очень объёмным, поэтому в автоматизированных сценариях полезно перенаправлять вывод в файл и анализировать итоговые строки отдельно.

Выходной файл и контейнер

Опция --output или -o записывает элементарный VVC-битстрим. Расширения .266, .h266 или .vvc часто используются для удобства, но сами по себе не превращают поток в медиаконтейнер. В таком файле нет обычной контейнерной структуры с несколькими дорожками, метаданными проекта и аудио.

Если конечная задача требует MP4 или другого контейнера, битстрим нужно передать совместимому мультиплексору. Это отдельная стадия, и её параметры не следует смешивать с битрейтом VVenC. Аналогично аудиодорожку кодируют и синхронизируют вне VVenC. При диагностике проблем воспроизведения полезно сначала проверить, декодируется ли сам элементарный поток совместимым VVC-декодером, и только затем разбирать контейнер.

Пять пресетов скорости и сжатия

VVenC предлагает faster, fast, medium, slow и slower. Они расположены по очевидной оси: быстрые пресеты сокращают вычислительную работу, более медленные тратят больше времени на поиск решений и стремятся получить более эффективное сжатие. Пресет medium выбран значением по умолчанию и обычно является разумной начальной точкой, если заранее не задана жёсткая цель по времени кодирования.

Выбор пресета не заменяет выбор QP или целевого битрейта. Пресет отвечает преимущественно за сложность поиска и набор быстрых эвристик, а QP и rate control — за компрессию и распределение битов. Поэтому команда с slower и очень высоким QP не становится автоматически качественной, а faster с низким QP может дать большой поток. Эти оси нужно настраивать отдельно.

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

Режим фиксированного QP

Параметр --qp принимает значения от 0 до 63, а значение по умолчанию — 32. Общая зависимость стандартная: снижение QP повышает точность квантования и обычно увеличивает битрейт, повышение QP уменьшает поток ценой большего искажения. Официальная документация указывает рабочий ориентир приблизительно от 21 до 47, но это не универсальная шкала качества: воспринимаемый результат зависит от разрешения, шума, движения, текстуры и выбранного пресета.

Фиксированный QP удобен для сравнения алгоритмов и серий кодирований, потому что не требует заранее угадывать целевой размер. Он также помогает быстро понять, как материал реагирует на VVC. Недостаток — размер результата не фиксирован: сложные сцены могут потребовать значительно больше битов, чем статичные, даже при одинаковом QP.

Пример vvencapp --preset medium -i input.yuv -s 1920x1080 --fps 50/1 -q 30 -o output.266 задаёт QP 30 и не включает rate control. В журнале это должно отражаться как режим QP, а не VBR. Если одновременно передать ненулевой --bitrate, смысл команды меняется: энкодер переходит к контролю скорости.

QPA и перцептуальная оптимизация

QPA — perceptual QP adaptation, перцептуально мотивированная адаптация параметра квантования. В vvencapp она включена по умолчанию и управляется --qpa. VVenC связывает эту оптимизацию с моделью XPSNR и может изменять распределение QP пространственно и во времени, чтобы эффективнее расходовать биты с точки зрения воспринимаемого качества.

Важно различать фиксированный базовый QP и полностью неизменный QP для каждого блока. Когда QPA включена, заданное значение служит основой, но энкодер адаптирует его. Если эксперимент требует чистого сравнения при жёстко одинаковом квантовании, QPA отключают осознанно. Для обычного субъективно ориентированного кодирования оставление QPA включённой обычно лучше соответствует назначению VVenC.

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

Constant Quality Factor и ограничение максимального битрейта

Документация VVenC выделяет режим Constant Quality Factor: заданный QP сочетается с перцептуальной оптимизацией и верхним ограничением битрейта. Практический пример — -q 27 --qpa 1 -m 5M. Такой подход полезен, когда основная цель — качество, но поток не должен иметь слишком большие пики.

--maxrate или -m задаёт приблизительное максимальное мгновенное значение. Допускаются человекочитаемые суффиксы вроде M, Mbps, k и kbps, а в режиме VBR можно выразить лимит множителем относительно целевого битрейта: например, -b 1Mbps -m 2x. Такие формы снижают риск ошибки с количеством нулей в длинной пакетной команде.

VBR и одно- или двухпроходный rate control

Ненулевой --bitrate включает контроль скорости VBR. В этом режиме VVenC стремится выдерживать заданный средний битрейт, перераспределяя биты между более простыми и более сложными участками. Это не жёсткий CBR: отдельные интервалы могут отличаться от среднего, а параметр --maxrate используется для ограничения пиков.

Однопроходный режим запускается с --passes 1 или -p 1. Он подходит, когда исходник должен быть прочитан один раз либо важна скорость обработки. Пример: vvencapp -i input.y4m -b 2M -m 5M -p 1 -o output.266. Частота кадров должна быть известна корректно, потому что rate control использует её при расчёте объёма данных на единицу времени.

Двухпроходный вариант задаётся -p 2. Если не указывать конкретный номер прохода, приложение может выполнить оба прохода последовательно за один запуск. Первый проход собирает статистику, второй использует её для более информированного распределения битов. Это удобно для файлового VoD-кодирования, где исходник доступен повторно и цена дополнительного чтения приемлема.

Раздельный запуск двух проходов

Когда проходы нужно выполнять в разные моменты или на разных этапах автоматизации, используются --pass и --rcstatsfile. Первый запуск может выглядеть как vvencapp -i input.y4m -b 2M -m 5M -p 2 --pass 1 --rcstatsfile stats.json -o output.266, второй — как та же команда с --pass 2. Файл статистики связывает два этапа и должен быть доступен второму запуску.

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

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

Ограничение максимального битрейта

В VBR параметр --maxrate предназначен для constrained VBR и ограничивает приблизительный пик. Официальная инструкция для режима rate control требует, чтобы максимум был как минимум примерно в 1,5 раза выше целевого среднего битрейта. Попытка задать слишком тесный потолок ограничивает свободу распределения битов и может вызвать ошибку проверки параметров или ухудшить достижимость цели на сложных сценах.

Практически -b 4M -m 8M означает иной сценарий, чем фиксированный QP: размер потока становится центральной целью, а качество адаптируется к бюджету. Если задача требует строго ограниченной полосы на коротком сегменте, кроме среднего значения приходится учитывать длину GOP, точки обновления, размер сегмента и поведение контейнера. VVenC управляет видеобитстримом, но не резервирует полосу для аудио и служебных данных контейнера.

Период обновления и тип точки случайного доступа

--refreshsec или -rs задаёт период обновления в секундах; базовое значение — одна секунда. --refreshtype выбирает тип обновления, среди базовых вариантов есть idr, cra и cra_cre. Эти настройки влияют на случайный доступ, структуру зависимостей между кадрами и накладные расходы на регулярные точки обновления.

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

Экспертный интерфейс использует --DecodingRefreshType и --RefreshSec. При чтении журналов нужно различать GOP size, intra period и фактический тип IRAP-картинки: эти понятия связаны, но не являются синонимами. Воспроизводимая конфигурация должна фиксировать их явно, если структура потока имеет значение для теста или упаковки.

Кодирование сегментов для DASH-подобного сценария

В официальной документации VVenC приведён специальный пример для chunk-based encoding. Для нескольких разрешений используется -rt cra_cre, одинаковый период обновления и экспертный параметр MaxPicSize, задающий максимальное разрешение, сигнализируемое в SPS. Например, 4K-, 1080p- и 720p-варианты могут быть настроены так, чтобы согласовать параметры, необходимые для переключения между представлениями.

MaxPicSize передаётся через --additional, например --additional MaxPicSize=3840x2160. Эта настройка не масштабирует изображение и не создаёт лестницу адаптивного стриминга автоматически. Каждое разрешение нужно подготовить и закодировать отдельно, а затем сегментировать и упаковать внешними средствами. VVenC отвечает за совместимый VVC-битстрим и его параметры обновления.

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

Профиль, уровень и tier

Опции --profile, --level и --tier управляют нормативной сигнализацией возможностей потока. В обычном случае значение auto позволяет энкодеру подобрать совместимые параметры. Ручное указание оправдано, когда целевая система предъявляет конкретные ограничения по декодированию или когда проводится тест на соответствие заранее заданному профилю доставки.

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

В экспертном приложении те же понятия представлены как --Profile, --Level и --Tier. При переносе параметров в FFmpeg-обёртку libvvenc нужно учитывать уже синтаксис FFmpeg: у неё есть собственные AVOptions для level и tier, а дополнительные параметры могут передаваться словарём vvenc-params.

SDR, HDR и VUI

VVenC умеет сигнализировать характеристики входного изображения. В простом интерфейсе --sdr и --hdr выбирают готовые режимы. Для SDR предусмотрены варианты BT.709, BT.2020 и BT.470BG; для HDR — варианты с PQ или HLG и соответствующими цветовыми первичными. Если выбран режим сигнала, VUI добавляется автоматически, когда это имеет смысл для заданных характеристик.

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

Аналогично параметр --sdr sdr_709 уместен для материала, который действительно соответствует BT.709. Если исходник был преобразован в BT.2020, но оставлена сигнализация BT.709, проблема будет проявляться уже при отображении, а не в синтаксической корректности VVC-потока.

Расширенные поля VUI через --additional

Экспертные параметры позволяют уточнить AspectRatioIdc, sample aspect ratio, ColourPrimaries, TransferCharacteristics, MatrixCoefficients, признак полного диапазона и расположение цветностных выборок. Они передаются либо напрямую в vvencFFapp, либо строкой --additional. Эти параметры нужны не каждому пользователю, но важны в вещательных, архивных и тестовых процессах, где метаданные должны точно соответствовать мастер-файлу.

VUI нельзя рассматривать изолированно от реального преобразования пикселей. Например, указание BT.2020 в ColourPrimaries не меняет коэффициенты матрицы уже подготовленного YUV. Поэтому типичный правильный порядок таков: сначала внешний фильтр переводит изображение в требуемое пространство и диапазон, затем VVenC получает уже соответствующий YUV, после чего параметры VUI описывают этот сигнал.

Цветовой диапазон и новые параметры сигнализации

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

Если подготовка выполняется FFmpeg, фиксируйте диапазон и матрицу на стадии преобразования и не полагайтесь на неявные догадки. Для архивной воспроизводимости полезно сохранять команду препроцессинга вместе с командой VVenC: по одному элементарному битстриму потом трудно понять, каким именно фильтром и диапазоном был сформирован исходный YUV.

Многопоточность: --threads

--threads или -t задаёт число потоков. В простом приложении значение по умолчанию зависит от размера: для материала не меньше 720p документация указывает восемь потоков, для меньшего — четыре. Это не означает, что максимальное число логических ядер всегда даёт лучший результат. Реальная масштабируемость зависит от пресета, разрешения, длины последовательности и доступных видов параллелизма.

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

Журнал PARALLEL PROCESSING CFG показывает итоговую конфигурацию. Если скорость неожиданно низкая, сначала проверьте, сколько потоков действительно активировано, и только потом меняйте кодековые инструменты. На небольших кадрах или коротких клипах накладные расходы параллельного планирования заметнее, поэтому больше threads не является универсальным рецептом.

mtprofile, IFP, WPP и tiles

--mtprofile auto включает автоматическую настройку многопоточности и может задействовать tiles, inter-frame parallelization и wavefront parallel processing в зависимости от количества потоков и размера кадра. Это удобнее ручного подбора всех механизмов, если задача состоит просто в эффективной загрузке процессора.

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

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

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

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

Проверять производительность следует на материале, похожем на реальную задачу. Десять кадров 320×240 не отражают поведение 4K-проекта, а синтетическая статичная сцена не отражает нагрузку сложного движения. При этом нельзя переносить чужие значения fps как гарантию: скорость зависит от конкретного процессора, компилятора, SIMD, пресета, битовой глубины и конфигурации многопоточности.

Экспертный режим vvencFFapp

Главное преимущество vvencFFapp — возможность описать кодирование конфигурационными файлами. Это удобно, когда параметров много и команда становится нечитаемой. В sequence.cfg задают характеристики исходной последовательности, а отдельный random-access файл определяет набор алгоритмических настроек пресета. Дополнительные конфигурации могут поверх них включать QPA или rate control.

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

В экспертном режиме доступны поля вроде SourceWidth, SourceHeight, InputBitDepth, InternalBitDepth, FrameRate, FramesToBeEncoded, FrameSkip, Tiles, TargetBitrate, MaxBitrate, NumPasses, RCStatsFile, DecodingRefreshType, Threads, VUI/HRD и SEI-параметры. Такой набор превращает vvencFFapp в инструмент для систематического исследования VVC, но одновременно повышает цену ошибки в конфигурации.

Параметр --additional в vvencapp

--additional даёт доступ к длинным параметрам экспертного приложения, не заставляя полностью переходить на vvencFFapp. Формат — пары имя=значение, разделённые двоеточиями. Например, можно передать --additional bitrate=1M:passes=1. Это удобно для одного-двух экспертных переключателей поверх знакомой команды vvencapp.

Есть важная особенность приоритетов: строка --additional разбирается после обычных аргументов. Поэтому она может переопределить значение, которое визуально стоит позже или раньше в командной строке. Официальный пример показывает, что сочетание обычного --bitrate=2M и --additional bitrate=1M:passes=1 приводит к использованию 1 Мбит/с из additional. При отладке нужно смотреть финальный лог, а не угадывать приоритет по расположению аргументов.

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

Инструменты кодирования в журнале

Строка CODING TOOL CFG перечисляет инструменты VVC, активированные выбранной конфигурацией. Там можно увидеть SAO, ALF, CCALF, TMVP, DQ, BDOF, DMVR, SBT, MIP, AFFINE, MMVD, GPM, LFNST, MTS, ISP, IBC и другие сокращения. Их конкретные комбинации различаются между пресетами и экспертными настройками.

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

FAST TOOL CFG показывает эвристики ускорения поиска. Более быстрые пресеты активнее ограничивают дорогие варианты, что и создаёт компромисс между временем и эффективностью сжатия. Поэтому попытка сделать faster таким же эффективным, как slower путём одного переключателя обычно не отражает реальной структуры пресета.

Как интерпретировать QP по кадрам

В подробном выводе рядом с POC указывается QP конкретного изображения. При включённой QPA и rate control значения могут меняться. Это нормальное поведение: цель адаптивного режима как раз состоит в том, чтобы не тратить одинаковое количество битов на кадры с разной сложностью и визуальной чувствительностью.

Среднее QP для I-, P- и B-категорий в финальной статистике помогает быстро увидеть распределение. Если один тест неожиданно имеет намного более высокий средний QP при том же целевом битрейте, нужно проверить длительность, FPS и фактический размер входа. Особенно подозрителен случай, когда bitrate кажется правильным, но частота кадров была указана вдвое неверно: бюджет на кадр тогда интерпретируется иначе.

PSNR в итоговой статистике

VVenC может печатать PSNR по Y, U, V и агрегированное значение. Это полезная техническая метрика для контролируемых тестов, где исходные и реконструированные выборки сопоставимы. Но PSNR не заменяет перцептуальную оценку: он чувствителен к среднеквадратичной ошибке и не моделирует все особенности человеческого зрения.

QPA специально ориентирована на воспринимаемое качество, поэтому сравнение только по обычному PSNR способно недооценить её пользу. Для внешней оценки можно декодировать VVC обратно в YUV и применить отдельные метрики. Сам VVenC не является универсальной системой VMAF-оценки; в официальных обсуждениях разработчики рекомендуют выполнять декодирование и измерение отдельными инструментами.

Кодирование из stdin

Вместо имени файла -i - заставляет vvencapp читать стандартный ввод. Для RAW-потока нужно дополнительно задать разрешение, FPS и формат. Для Y4M добавляют --y4m. Такой интерфейс позволяет соединить VVenC с декодером или фильтровальным процессом без гигантского промежуточного YUV-файла.

Принципиальная команда выглядит так: внешний инструмент выдаёт кадры в stdout, символ канала передаёт их в vvencapp -i -, а VVenC пишет VVC в файл. Если генератор кадров завершится с ошибкой, VVenC может получить укороченный поток, поэтому в автоматизации проверяют код возврата обеих частей конвейера, а не только наличие выходного файла.

Пайп особенно удобен для одноразового fixed-QP или single-pass кодирования. Для двухпроходного режима требуется повторяемый доступ к тем же кадрам; если источник нельзя надёжно перезапустить идентично, промежуточный Y4M или воспроизводимый скрипт кадров будет безопаснее.

Пайп из FFmpeg в vvencapp

FFmpeg можно использовать только как декодер и преобразователь пикселей, оставляя кодирование VVC самому vvencapp. Типовой поток Y4M формируется с нужным pix_fmt и передаётся через stdout. На стороне VVenC указываются -i - --y4m, пресет, QP и имя выходного VVC-файла.

Преимущество схемы — поддержка почти любого входного контейнера и кодека, которые умеет читать FFmpeg, а также фильтров масштабирования, кадрирования, деинтерлейса и преобразования цветов до VVenC. Недостаток — два процесса и необходимость точно согласовать формат пикселей. При 10-битном Y4M важно получить именно тот формат, который ожидает vvencapp, и объявить его как yuv420_10.

Не стоит смешивать в одном пайпе неявные преобразования цвета. Лучше явно задать требуемый формат и, при необходимости, параметры colorspace в FFmpeg, а затем столь же явно сообщить VVenC SDR/HDR и VUI. Тогда цепочка легче воспроизводится и диагностируется.

Использование libvvenc через FFmpeg

Если конкретная сборка FFmpeg скомпилирована с libvvenc, кодирование можно запускать непосредственно через -c:v libvvenc. Доступность проверяют командой списка кодеков и справкой ffmpeg -h encoder=libvvenc. Обёртка предоставляет основные параметры VVenC — preset, QP, субъективную оптимизацию, level, tier и словарь дополнительных настроек.

У FFmpeg-обёртки есть собственное ограничение по входному пиксельному формату: документация FFmpeg указывает 10-битные цветовые пространства для входа libvvenc, а распространённый список возможностей показывает yuv420p10le. При этом внутренняя глубина кодирования может быть 8 или 10 бит. Поэтому команда, работающая напрямую с vvencapp на 8-битном YUV, не обязана переноситься в libvvenc без преобразования формата.

-vvenc-params принимает пары key=value, разделённые двоеточиями. Через него можно передать параметры VVenC, которые не вынесены в отдельные AVOptions FFmpeg. Пример смысловой настройки — зафиксировать intra period, тип обновления, POC0 IDR и внутреннюю глубину. Полный допустимый набор всё равно следует сверять с --fullhelp соответствующей версии VVenC.

Когда удобнее vvencapp, а когда FFmpeg с libvvenc

vvencapp лучше, когда важен прямой контроль над поведением VVenC, чистая воспроизводимость эксперимента и доступ к его собственному журналу. Он также естественен для тестовых YUV/Y4M-последовательностей, где контейнерная обвязка не нужна. Сборка FFmpeg с libvvenc удобнее, когда необходимо в одном процессе декодировать исходник, фильтровать, кодировать звук и упаковывать результат.

Эти два пути используют один энкодерный движок, но интерфейсы не идентичны. Значения по умолчанию, формат входа и способ передачи продвинутых параметров могут различаться. Поэтому нельзя считать два результата эквивалентными только потому, что в обоих командах написано preset=medium и одинаковый QP. Для корректного сравнения фиксируют весь набор параметров и формат кадров, поступающих в библиотеку.

Библиотека VVenC для собственного приложения

Проект предоставляет C API. Типичная последовательность работы состоит из инициализации vvenc_config, создания vvencEncoder, открытия энкодера с конфигурацией, подготовки vvencYUVBuffer и vvencAccessUnit, последовательной передачи кадров через vvenc_encode, а затем flush до получения всех задержанных единиц доступа.

Буферы YUV содержат указатели, размеры и stride для трёх плоскостей. В примере документации stride входного изображения в байтах делится пополам, потому что интерфейс VVenC работает с 16-битными выборками в памяти. Временная метка кадра передаётся через cts и признак её валидности. Эта часть особенно важна для интеграции с медиасистемой, где временные метки формируются не из простого номера кадра.

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

Проверка результата декодером

Самый надёжный базовый тест VVC-файла — декодировать его стандартно совместимым декодером и сверить длительность, число кадров, размер и визуальное содержимое. Для пары инструментов Fraunhofer обычно используется VVdeC, но это отдельный продукт: VVenC кодирует, а VVdeC декодирует. Их не следует смешивать в описании возможностей одного приложения.

Если декодированный YUV выглядит повреждённым, сначала проверяют описание исходника, а не параметры VVC. Типичная ошибка — 10-битный YUV передан как 8-битный или перепутано разрешение. Если битстрим декодируется, но цвета неверны, далее проверяют диапазон, матрицу, primaries и transfer characteristics. Если декодер вообще не принимает поток, только тогда имеет смысл разбирать профиль, level, тип обновления и совместимость версии декодера со стандартом.

Практический сценарий: качественное файловое кодирование

Для мастер-файла без жёсткого требования к размеру удобна схема декодирование/фильтрация → Y4M → vvencapp с QP и QPA. Стартовой точкой может быть medium или slow, затем QP подбирают по коротким репрезентативным фрагментам. Если визуальная цель достигнута, весь материал кодируют с теми же настройками.

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

Практический сценарий: заданный средний битрейт

Когда задача формулируется как получить примерно 4 Мбит/с, используют VBR. Для офлайн-файла предпочтителен двухпроходный режим, если дополнительное время допустимо. Целевой битрейт задают через -b, разумный максимум — через -m, а QPA оставляют включённой, если нет специальной причины отключить перцептуальную адаптацию.

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

Практический сценарий: серия разрешений

Для 4K, 1080p и 720p сначала создают три входных последовательности одинаковой временной структуры. Затем каждому разрешению назначают собственный bitrate или QP, сохраняя согласованный refresh period. Если потоки предназначены для переключаемой доставки, дополнительно используют настройки вроде cra_cre и общего MaxPicSize, как в официальном примере chunk-based encoding.

Размерирование лестницы не является функцией VVenC: энкодер не анализирует исходник и не предлагает автоматически набор представлений. Эту логику строит внешний процесс. Зато VVenC позволяет сделать сами VVC-потоки предсказуемыми по структуре, что важно для последующей упаковки.

Практический сценарий: исследовательское сравнение

Для сравнения пресетов или алгоритмов лучше использовать фиксированный набор кадров, точный FPS и явно заданный QP. Отключать QPA стоит только тогда, когда эксперимент требует именно этого; иначе сравнивается конфигурация, отличающаяся от типичного пользовательского режима. Все параметры, влияющие на многопоточность и структуру потока, фиксируют одинаково.

Если сравнивается качество при одинаковом битрейте, логичнее использовать двухпроходный rate control и затем декодировать результаты для внешних метрик. Для сравнения вычислительной стоимости сохраняют wall-clock время, средний fps и аппаратную конфигурацию, не смешивая результаты разных процессоров в одну шкалу.

Как диагностировать ошибку открытия входного файла

Сообщение open input file failed означает проблему до кодирования: процесс не смог открыть путь или поток данных. Проверяют существование файла, права чтения, рабочий каталог и кавычки вокруг путей с пробелами. Для относительного пути важно помнить, что он отсчитывается от текущего каталога оболочки, а не от каталога, где находится vvencapp.

Если вход идёт через stdin, обычного имени файла быть не должно: используется -i -. Пустой канал может возникнуть, если предыдущая команда завершилась раньше VVenC. В скриптах полезно отдельно запускать генератор YUV/Y4M и проверять его код возврата. Наличие созданного .266 ещё не означает, что в него записано ожидаемое число кадров.

Ошибка Input resolution not set

RAW YUV не сообщает собственную геометрию, поэтому отсутствие размера приводит к ошибке параметров в экспертном режиме и к неверному чтению в других ситуациях. В vvencapp задают -s WIDTHxHEIGHT; в vvencFFapp можно использовать --Size либо отдельные --SourceWidth и --SourceHeight. Для Y4M размер обычно считывается из заголовка.

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

Неверная битовая глубина: один из самых частых источников повреждения

Для простого приложения базовые форматы входа — yuv420 и yuv420_10. Если 10-битный planar YUV прочитать как 8-битный, VVenC будет группировать байты неправильно. Сам процесс может не остановиться, потому что для программы это просто последовательность данных; ошибка проявится в содержимом кадра.

Обратная проблема — объявить 8-битный файл десятибитным. Поэтому выбор --format должен происходить из реального результата декодирования/фильтрации, а не из предполагаемой глубины исходного MP4. Видеофайл может быть 10-битным, но внешний фильтр уже преобразовал его в 8-битный YUV, и тогда VVenC нужно описывать именно результат фильтра.

Параметр --internal-bitdepth решает другую задачу. Он не исправляет неправильно прочитанный вход. Если требуется 8-битное внутреннее кодирование из корректно поданного материала, эту настройку задают дополнительно и проверяют в журнале IBD и описании internal format.

Когда частота кадров указана неправильно

При fixed-QP кодировании неверный FPS не обязательно меняет сами пиксели, поэтому ошибка может остаться незамеченной до воспроизведения или упаковки. В rate control последствия серьёзнее: средний битрейт выражается в битах в секунду, а значит бюджет на кадр вычисляется из частоты. Если реальный источник 25 fps, а задано 50, модель скорости работает с неверной временной шкалой.

Для NTSC-подобных частот не стоит округлять 23.976 до 24 или 29.97 до 30, когда важна синхронизация с аудио или точная длительность. --fps 24000/1001 и аналогичные дроби позволяют сохранить исходное отношение. Y4M уменьшает риск, потому что частота находится в заголовке, но при формировании самого Y4M она тоже должна быть корректной.

Почему output.266 не открывается обычным проигрывателем

Элементарный VVC-поток требует декодера, понимающего H.266/VVC. Само расширение файла не добавляет поддержку в проигрыватель. Кроме того, часть медиаплееров ожидает VVC внутри контейнера и может не уметь корректно определять сырой поток. Поэтому сначала проверяют наличие VVC-декодера, затем при необходимости помещают битстрим в поддерживаемый контейнер.

Если задача — проверить именно работу энкодера, проще декодировать поток специализированным VVC-декодером в YUV и сравнить число кадров. Если этот тест проходит, а медиаплеер не воспроизводит файл, проблема уже не в базовой валидности кодирования, а в поддержке декодера, демультиплексора или контейнерной упаковке.

Двухпроходный режим выдаёт ошибку на втором проходе

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

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

Maxrate слишком близок к target bitrate

Если constrained VBR настроен как -b 4M -m 4.1M, энкодеру почти не остаётся возможности перераспределять биты на сложные эпизоды. Для VVenC официальная рекомендация требует заметного запаса: maximum bitrate должен быть не менее примерно 1,5 от целевого. Значение -m 2x удобно тем, что автоматически сохраняет пропорцию при изменении -b.

При доставке по сети реальный допустимый пик может зависеть не только от видеопотока. Аудио, контейнер и протокольные накладные расходы добавляются позже. Поэтому maxrate VVenC нельзя напрямую приравнять к общей пропускной способности канала без запаса на остальные компоненты.

Почему целевой битрейт не получается абсолютно точно

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

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

Слишком медленное кодирование 4K

Для 4K стоимость поиска решений резко растёт. Первый способ ускорения — выбрать faster или fast, второй — убедиться, что многопоточность действительно активна, третий — проверить формат входа и внутреннюю битовую глубину. В официальных обсуждениях встречается пример, где неверная комбинация десятибитного исходника и параметров внутренней глубины одновременно давала неправильное описание входа и искажала представление о скорости.

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

CPU загружен не на 100%

Неполная загрузка не всегда означает ошибку. Между задачами кодирования существуют зависимости, и не вся работа распараллеливается. Небольшое разрешение, короткая последовательность, медленный пресет или определённая структура GOP могут ограничивать число одновременно доступных задач. mtprofile auto помогает подобрать tiles, IFP и WPP без ручной настройки.

Для диагностики сравнивают несколько длительных запусков с разным числом потоков. Если переход с 8 на 16 даёт минимальный прирост, дальнейшее увеличение может быть бессмысленным. Следует также следить за пропускной способностью памяти и конкуренцией других процессов: насыщение одного ресурса способно удерживать CPU ниже формальных 100%.

Старый x86-процессор и ошибка illegal instruction

Современные сборки VVenC для x86/x86-64 требуют как минимум SSE4.1. Если бинарник собран с более новыми SIMD-инструкциями, на старом CPU возможен аварийный запуск ещё до обработки кадра. В таком случае параметры энкодера не помогут: нужна сборка, совместимая с набором инструкций процессора, либо более новое аппаратное обеспечение.

Сам заголовок VVenC обычно показывает активный SIMD-режим, например SSE4.2 или AVX2. Это полезная диагностическая информация при сравнении двух систем. Нельзя ожидать одинаковой скорости от бинарников, использующих разные SIMD-оптимизации, даже при одном и том же номере пресета.

VUI и цвета выглядят неправильно после декодирования

Если геометрия и битовая глубина верны, но изображение слишком контрастное, выцветшее или имеет неверные оттенки, проверяют полный/ограниченный диапазон, матрицу YUV↔RGB, цветовые первичные и transfer characteristics. VVenC передаёт сигнализацию, но не угадывает, как именно внешний инструмент подготовил пиксели.

Для HDR дополнительно важна корректность PQ или HLG и выбранных первичных. Нельзя просто взять SDR BT.709 YUV и пометить его как HDR10_2020. Так получится битстрим с противоречивой семантикой: декодер будет корректно следовать метаданным, но отображать не то, что предполагалось.

Проблемы с profile, level и tier

Если ручное значение не принимается, сначала запускают --fullhelp и смотрят допустимый синтаксис. В старых обсуждениях встречаются ошибки вида Error parsing option profile при передаче формы, которую конкретный интерфейс не понимает. Это хороший пример того, почему нельзя без проверки копировать параметры из другого энкодера или старого скрипта.

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

Потеря кадров при остановке собственного приложения

При работе через C API нельзя прекращать процесс сразу после передачи последнего входного кадра. Энкодер имеет внутреннюю задержку, поэтому нужно перейти в фазу flush и вызывать vvenc_encode без нового YUV-буфера до установки признака завершения. Только после этого освобождаются encoder, YUV buffer и access unit.

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

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

Параметр --frames позволяет ограничить объём входа, а --frameskip — пропустить начальные кадры. В экспертном интерфейсе им соответствуют --FramesToBeEncoded и --FrameSkip. Это удобно для тестовых фрагментов без физического создания отдельного YUV-файла.

Для сравнений важно использовать одинаковый диапазон кадров. Если один пресет кодирует первые 300 кадров, а другой — 300 кадров после пропуска 1000, метрики и время нельзя сопоставлять как одну сцену. В скрипте диапазон лучше хранить вместе с остальными параметрами эксперимента.

Размер кадра и внутреннее дополнение

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

Тем не менее устройство воспроизведения или контейнерный профиль может иметь собственные ограничения. Если поток кодируется и декодируется VVC-совместимым декодером, но конкретный аппаратный проигрыватель его не принимает, нужно проверять требования этого проигрывателя, а не искусственно приписывать ограничение VVenC.

Монохромный и нестандартный chroma format

Простой vvencapp ориентирован на YUV 4:2:0 8/10 бит. Экспертный интерфейс имеет более широкие настройки формата, однако экспериментальные или редкие режимы не следует считать равноценными базовому пути без проверки конкретной сборки. Исторически поддержка 4:0:0 находилась именно на стороне full-featured app и требовала осторожности.

Если задача требует 4:2:2, 4:4:4 или монохромного кодирования, правильный подход — сверить vvencFFapp --fullhelp, построить короткий тест и декодировать его целевым декодером. Для обычного каталога видео безопаснее исходить из официально документированного простого формата 4:2:0.

Lossless и QP 0: что не нужно обещать

QP 0 в vvencapp не следует автоматически описывать как гарантированно lossless для любой цепочки. Даже если квантование сведено к минимуму, исходное преобразование RGB→YUV, subsampling 4:2:0, ограничение битовой глубины и другие этапы могут уже быть необратимыми. Для настоящей побитовой сохранности важно рассматривать всю цепочку, а не только число QP.

В vvencFFapp встречается экспертный CostMode lossless, но его использование нужно подтверждать конкретной конфигурацией и форматом. Для пользователя, которому нужен гарантированно без потерь архив, безопаснее сначала сформулировать требование к цветовой модели и сравнить декодированные выборки, а не ориентироваться на слово lossless в одной опции.

Почему VVenC не нужен контейнерный bitrate для аудио

Параметры --bitrate и --maxrate относятся к видеопотоку VVC. Если итоговый MP4 должен занимать определённый размер, аудиобитрейт и служебные расходы нужно вычесть из общего бюджета до расчёта цели VVenC. То же относится к нескольким аудиодорожкам, субтитрам и дополнительным данным.

Например, если доставка ограничена общей полосой 5 Мбит/с, нельзя автоматически передать -b 5M энкодеру и затем добавить 256 кбит/с аудио. Видеобюджет должен быть меньше общего. Точный запас зависит от контейнера и протокола и рассчитывается вне VVenC.

Пакетная обработка нескольких файлов

Для очереди кодирования полезно отделить параметры, зависящие от входа, от общего профиля. Разрешение, FPS, битовая глубина и SDR/HDR извлекаются для каждого файла отдельно; пресет, режим QP/VBR и политика refresh могут быть общими. После подготовки декодированный поток передаётся VVenC, а результат именуется так, чтобы по имени можно было восстановить профиль задания.

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

Как строить воспроизводимые команды

Хорошая команда явно фиксирует всё, что влияет на интерпретацию входа и результат: путь, размер, FPS, формат, preset, QP или bitrate, QPA, refresh, цветовую сигнализацию и число потоков, если производительность является частью теста. Значения по умолчанию удобны для ручного запуска, но в долгоживущем скрипте лучше записывать критичные параметры явно.

Для экспертных конфигураций хранят сами cfg-файлы. Если используется --additional, строку не следует собирать из случайного порядка словаря без логирования: приоритет переопределений имеет значение. Финальную команду записывают в лог перед запуском, а конфигурационный вывод VVenC оставляют рядом.

Как выбирать QP на практике

Нет универсального значения QP, которое всегда соответствует высокому качеству. Шумная камера, анимация, спортивное видео и экранная графика реагируют по-разному. Рациональная методика — выбрать несколько коротких сцен, закодировать сетку QP, декодировать результаты и найти уровень, на котором артефакты становятся заметными именно для целевого просмотра.

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

Как выбирать пресет на практике

Если материал кодируется один раз для длительного хранения, время часто дешевле дискового пространства, поэтому slow или slower могут быть оправданы. Для регулярной пакетной обработки medium обычно проще балансировать. Для быстрых прототипов и большой очереди fast или faster уменьшают время и позволяют сначала проверить весь технологический процесс.

Решение следует принимать по отношению время на один час контента / размер при выбранном качестве, а не по названию пресета. На новом CPU разница может восприниматься иначе, чем на старом. Поскольку VVenC активно использует SIMD и многопоточность, аппаратная платформа непосредственно влияет на экономику выбора.

Как выбирать между fixed QP и VBR

Fixed QP удобен, если качество важнее размера и каждый материал должен получать столько битов, сколько ему нужно. VBR удобен, если размер, средняя полоса или профиль доставки должны быть предсказуемыми. CQF-подобный вариант с QP, QPA и maxrate занимает промежуточное положение: основная цель остаётся качественной, но пиковый поток ограничивается.

Нельзя сказать, что один режим лучше всегда. Архивный мастер, VoD-рендиция и научный тест имеют разные критерии. Правильный режим определяется тем, какая величина является ограничением: воспринимаемое качество, средний bitrate, пик bitrate или воспроизводимость конкретного QP.

Сохранение временных меток через библиотеку

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

Если приложение само упаковывает access units в контейнер, оно должно корректно обработать задержку декодирования и порядок представления. VVenC предоставляет закодированные единицы доступа, но логика контейнера и синхронизации остаётся ответственностью интегратора.

Как не перепутать VVenC и VVdeC

Названия похожи, но назначения противоположны. VVenC — encoder: получает несжатые кадры и создаёт H.266/VVC. VVdeC — decoder: получает VVC-битстрим и восстанавливает кадры. Скриншот, дистрибутив или параметр VVdeC нельзя выдавать за интерфейс VVenC, даже если оба продукта разработаны Fraunhofer и часто используются вместе.

При поиске готовых Windows-архивов встречаются наборы, где оба исполняемых файла лежат рядом. Это допустимо как сторонний пакет инструментов, но в описании кандидата нужно явно указывать, что внутри присутствует не только VVenC. Для редакционной публикации предпочтительнее отдельный пакет VVenC, если он доступен.

Что VVenC не делает

• не декодирует произвольные MP4, MKV и MOV как универсальный медиаплеер;
• не монтирует клипы на тайм-линии и не управляет дорожками проекта;
• не кодирует аудио и не смешивает его с VVC;
• не выполняет сам по себе масштабирование, деинтерлейс и художественные фильтры;
• не создаёт автоматически адаптивную лестницу из нескольких разрешений;
• не заменяет контейнерный мультиплексор и сервер упаковки DASH/HLS;
• не гарантирует, что любой существующий проигрыватель умеет декодировать H.266/VVC.

Эти ограничения не являются недостатками архитектуры как таковой: VVenC специально сосредоточен на видеокодировании. В полноценном медиапроцессе его соединяют с декодером/фильтрами на входе, контейнерным инструментом на выходе и VVC-декодером для контроля результата.

Сильные стороны VVenC в реальной работе

Первая сильная сторона — пять готовых пресетов, которые избавляют пользователя от ручной настройки большого числа внутренних инструментов. Вторая — QPA на основе перцептуальной модели XPSNR. Третья — одно- и двухпроходный VBR с ограничением максимального битрейта. Четвёртая — развитая многопоточность и автоматический mtprofile.

Для инженерной работы особенно полезна двойная модель интерфейса: короткий vvencapp и экспертный vvencFFapp. Можно начать с простой команды, а при необходимости постепенно открыть VUI, SEI, HRD, параметры random access, tiles и низкоуровневые инструменты, не меняя сам энкодерный движок.

Ограничения, которые нужно учитывать до начала проекта

Главное пользовательское ограничение — отсутствие собственного графического интерфейса: параметры вводятся в командной строке либо конфигурационных файлах. Второе — узкий набор нативных входных форматов, ориентированный на YUV/Y4M; для обычных медиафайлов требуется внешний декодер. Третье — сложность экспертного режима, где большое число взаимосвязанных опций требует понимания стандарта и тщательной проверки.

Также нужно учитывать экосистему воспроизведения VVC. Даже идеально созданный поток бесполезен, если конечное устройство или программа не имеют совместимого H.266-декодера. Поэтому перед массовым транскодированием стоит подтвердить требования целевой цепочки — от контейнера до декодирования и отображения HDR.

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

Программа	Лучше подходит для	Главное ограничение
VVenC	Офлайн-кодирования VVC, исследований, VoD и интеграции libvvenc	Командная работа и сырой YUV/Y4M как основной вход
VTM	Эталонных экспериментов, проверки инструментов стандарта и исследований VVC	Референсный энкодер значительно менее ориентирован на производственную скорость
uvg266	Открытого VVC-кодирования с собственным CLI и библиотечным интерфейсом	Проект прямо позиционирует поддержку как развивающуюся, набор возможностей отличается
Spin Enc Live	Коммерческого серверного real-time кодирования VVC для живой доставки	Ориентирован на коммерческую live-инфраструктуру, а не на свободный офлайн CLI
xin26x	Экспериментов с открытым универсальным энкодером, включающим H.266/VVC	VVC — лишь одна из целей проекта, экосистема и документация меньше

Для воспроизводимых офлайн-задач VVenC обычно удобнее VTM, потому что предлагает готовые speed/quality-пресеты, rate control и оптимизированный многопоточный код, сохраняя доступ к экспертным настройкам. VTM логичнее выбирать, когда критична близость к референсной модели стандарта и скорость не является практическим требованием.

uvg266 — наиболее прямой открытый конкурент по классу: это тоже программный VVC-энкодер с командной строкой. Выбор между ними зависит от конкретных поддерживаемых инструментов, требуемого API, производительности на целевой платформе и совместимости битстрима с используемым декодером. Сравнивать нужно на одном наборе источников и одинаковой методике качества.

Spin Enc Live решает другой производственный сценарий внутри того же класса кодека — реальное время и серверная доставка. Если задача состоит в живом потоке с коммерческой поддержкой, такой продукт ближе к требованиям, чем офлайн slower. Если нужно автоматизировать научные и VoD-прогоны с доступным исходным кодом, VVenC практичнее.

xin26x интересен как развивающийся открытый энкодер нескольких современных стандартов, однако для пользователя, которому нужен именно хорошо документированный VVC-процесс с five presets, QPA и интеграцией libvvenc, VVenC имеет более прямой путь. Финальный выбор всё равно должен опираться на проверку реальных потоков, а не на названия пресетов разных программ: одинаковое слово medium у разных энкодеров не означает одинаковой сложности или качества.

VVenC и VideoМАСТЕР — не прямые аналоги

Универсальный видеоконвертер с графическим интерфейсом и VVC-энкодер решают задачи разного уровня. VVenC — кодековый движок и CLI для H.266/VVC; конвертер обычно ориентирован на открытие популярных контейнеров, выбор формата и подготовку готового файла. Поэтому включать VideoМАСТЕР в таблицу прямых VVC-энкодеров было бы некорректно, если он не предоставляет тот же класс H.266-кодирования и экспертных параметров.

Практический выбор простой: если требуется именно исследовать или автоматизировать VVC с QP, QPA, rate control, VUI и экспертными cfg, нужен VVC-энкодер. Если цель — обычное преобразование пользовательских роликов между распространёнными форматами, нужен универсальный конвертер. Эти сценарии пересекаются только на уровне общего слова конвертация видео.

Рабочий алгоритм настройки VVenC с нуля

1. Определить реальный формат исходника: разрешение, FPS, 8/10 бит, SDR/HDR и цветовые характеристики.
2. Подготовить короткий Y4M или RAW YUV без скрытых преобразований.
3. Запустить vvencapp с preset medium и фиксированным QP.
4. Проверить Real Format, bit depth, FPS и цветовую сигнализацию в журнале.
5. Декодировать тестовый VVC и убедиться, что геометрия, длительность и цвета верны.
6. Подобрать QP или перейти к VBR, если нужен целевой bitrate.
7. Сравнить соседние пресеты по времени и качеству на репрезентативных сценах.
8. Настроить refresh, maxrate и VUI под требования доставки.
9. Только после этого переносить параметры в пакетный скрипт или FFmpeg/libvvenc.
10. Сохранять лог, команду и при двух проходах отдельный rcstats для каждого задания.

Такой порядок локализует ошибки. Если начать сразу с длинной экспертной строки, при неправильном цвете или bitrate придётся проверять десятки параметров одновременно. Минимальный тест делает очевидным, какой именно новый шаг изменил поведение.

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

Архивный профиль обычно строят от качества. Сначала выбирают 10-битный или 8-битный путь в соответствии с исходником и целевой экосистемой, затем корректно фиксируют цветовую сигнализацию. После этого на нескольких сценах сравнивают medium, slow и slower при одинаковом QP с включённой QPA.

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

Как подготовить профиль для VoD

Для VoD чаще нужен заданный средний bitrate и контролируемые пики. Здесь подходят два прохода, QPA и maxrate с достаточным запасом. Refresh period согласуют с длительностью сегментов, а для переключаемых представлений проверяют режим cra_cre и MaxPicSize.

Каждая рендиция кодируется из входа соответствующего разрешения. VVenC не генерирует 720p из 1080p сам, поэтому scaling выполняется до энкодера. После кодирования внешний упаковщик формирует сегменты и манифесты. Видеобитрейт VVenC выбирают с учётом того, что контейнер и аудио добавят свой объём.

Как подготовить профиль для скорости

Если приоритет — время, начинают с faster или fast, оставляя mtprofile auto. Излишне большое число потоков не задают без измерения. В пакетной системе сравнивают одну задачу на всех ядрах и несколько задач с ограниченным --threads; второй вариант нередко лучше использует сервер.

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

Сборка VVenC из исходников

Проект использует CMake. Поддерживаются Windows с Visual Studio, Linux с GCC и macOS с Xcode/Clang. В репозитории есть Makefile-обёртка для типовых целей: release, debug, shared-варианты и локальная установка. Команда make install-release создаёт статически связанное release-приложение в каталоге установки.

При чистом CMake создают отдельный build-каталог, выбирают Release и запускают сборку. Это важно для производительности: debug-сборка предназначена для разработки и не должна использоваться как эталон скорости энкодирования. При интеграции библиотеки выбирают static или shared в соответствии с архитектурой приложения и требованиями лицензирования/развёртывания.

Работа с конфигурационными файлами

Формат cfg удобен тем, что параметр и значение видны по строкам. Для последовательности задают размер, FPS, глубину, число кадров и путь к входу; в random-access конфигурации — инструменты кодирования и структура. В отдельном файле можно хранить rate control, чтобы один и тот же sequence.cfg использовать с fixed QP и VBR.

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

Когда использовать --additional, а когда cfg

Одна-две дополнительные настройки — хороший случай для --additional. Например, VUI-поле или MaxPicSize можно добавить к привычной команде без отдельного файла. Если же строка содержит десяток пар через двоеточие, читать и сопровождать её становится трудно.

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

Как понимать preset medium как базовую точку

medium не означает среднее качество. Это средняя точка по скорости/эффективности среди пяти пресетов. Качество по-прежнему задаётся QP или бюджетом bitrate. Поэтому выражение medium quality технически неточно: при QP 20 medium может дать очень высокое качество, а при QP 50 — сильно сжатое изображение.

Такая терминология важна при создании интерфейса-оболочки. Ползунок Качество: faster/fast/medium... вводит пользователя в заблуждение. Корректнее разделять Скорость/эффективность пресета и Качество/битрейт как независимые параметры.

Почему QPA не равно обычному AQ из другого энкодера

У разных кодеков и энкодеров свои алгоритмы адаптивного квантования. Нельзя переносить настройку AQ strength из x265 и искать прямой численный эквивалент в VVenC. QPA в VVenC связана с его собственным перцептуальным моделированием и XPSNR. Сопоставлять следует итоговое качество, а не значения параметров с похожими названиями.

Если мигрируется профиль HEVC→VVC, стартуют с базовых пресетов VVenC и тестовой сетки QP/bitrate, а не с попытки переводить каждую x265-опцию один к одному. Это снижает риск построить конфигурацию, которая противоречит оптимизациям самого VVenC.

Разбор строк I, P и B в итоговой статистике

Финальный лог может показывать количество кадров по типам и средний bitrate/QP для каждой группы. В random-access конфигурации P-кадры могут отсутствовать, а основная масса межкадровых изображений будет относиться к B. Это не ошибка само по себе: типы зависят от GOP-структуры и алгоритма.

Для пользователя полезно смотреть на количество I/IRAP относительно refresh period и на то, насколько дороги ключевые точки. Если каждые несколько кадров формируется дорогое обновление, общий bitrate возрастает. Но менять структуру только ради числа I без учёта требований случайного доступа нельзя.

Как фиксировать цвет в автоматизированном пайплайне

Полезно хранить набор полей как единый профиль: pixel format, bit depth, full/limited range, primaries, transfer, matrix, chroma location и SDR/HDR mode. Внешний декодер/фильтр преобразует кадры согласно этому профилю, а VVenC сигнализирует соответствующие значения. Любое расхождение становится видимым на уровне конфигурации.

Для HDR дополнительно сохраняют параметры mastering display и content light level, если они используются в проекте. VVenC имеет средства SEI для такой информации в экспертной конфигурации, но передавать случайные значения нельзя: они должны происходить из реальных метаданных мастера.

Почему VVenC подходит для автоматизации

Все основные параметры задаются текстом, процесс возвращает код завершения, а журнал можно перенаправлять. Это делает VVenC естественным компонентом shell-, PowerShell- и Python-скриптов. Нет необходимости автоматизировать клики по окнам или хранить скрытое состояние GUI.

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

Параметры, которые стоит логировать всегда

• размер и точный FPS входа;
• yuv420 или yuv420_10 и internal bit depth;
• preset;
• QP либо target/max bitrate и число проходов;
• QPA;
• refresh type и refresh period;
• SDR/HDR и ключевые VUI-поля;
• threads, mtprofile и ручные параметры параллелизма;
• номер сборки и SIMD, который печатает приложение;
• итоговые frames, bitrate, fps и время.

Этого набора обычно достаточно, чтобы через несколько месяцев понять, почему два файла были закодированы по-разному. Для исследовательского эксперимента добавляют полный вывод CODING TOOL CFG и копии cfg.

Частые ошибки в командной строке

Симптом	Вероятная причина	Что проверить
Искажённая картинка	Неверные размер или bit depth RAW YUV	-s, -c, фактический вывод декодера
Неправильная длительность	Округлённый или ошибочный FPS	--fps N/D, заголовок Y4M
Bitrate сильно отличается	Неверный FPS, короткий тест, разные passes	Real Format, target/maxrate, rcstats
Второй проход падает	Нет статистики или параметры изменены	--rcstatsfile и идентичность команд
CPU почти не масштабируется	Мало параллельной работы или oversubscription	threads, mtprofile, число процессов
Цвета не те	Несогласованы range/primaries/matrix/transfer	препроцессинг и VUI
Файл не играет	Нет VVC-декодера или ожидается контейнер	декодирование raw .266 специализированным декодером
Option parsing error	Опция из другого интерфейса или неверное значение	--fullhelp текущего исполняемого файла

Минимальные команды для основных режимов

Fixed QP для RAW YUV: vvencapp -i input.yuv -s 1920x1080 --fps 25/1 --preset medium -q 32 -o output.266. Для 10 бит добавляется -c yuv420_10. Для Y4M размер и FPS обычно можно не повторять: vvencapp -i input.y4m --preset medium -q 32 -o output.266.

Однопроходный VBR: vvencapp -i input.y4m -b 2M -m 5M -p 1 -o output.266. Двухпроходный VBR: та же команда с -p 2. Для явного разделения проходов добавляются --pass 1/--pass 2 и общий --rcstatsfile.

Y4M из канала: внешний генератор пишет Y4M в stdout, а VVenC запускается как vvencapp -i - --y4m --preset medium -q 32 -o output.266. Эти примеры следует воспринимать как каркас, а не как универсальный профиль качества.

FAQ по VVenC

Можно ли передать в vvencapp обычный MP4?

Напрямую интерфейс ориентирован на RAW YUV и Y4M. MP4 сначала декодируют внешним инструментом, после чего кадры передают в файл или pipe. Альтернатива — использовать FFmpeg, собранный с libvvenc, где декодирование контейнера и вызов библиотеки находятся в одной команде.

Какой preset использовать впервые?

medium — разумная базовая точка и значение по умолчанию. Если кодирование слишком медленное, сравнивают fast; если размер при требуемом качестве важнее времени, сравнивают slow. QP или bitrate при этом настраивают отдельно.

Какой QP даёт хорошее качество?

Единого числа нет. Диапазон 21–47 упоминается в документации как область, где можно получать полезные результаты, но конкретное значение выбирают по материалу. Для одного источника QP 32 может быть достаточным, для другого заметно хуже ожидаемого.

QPA нужно включать?

В vvencapp QPA включена по умолчанию и предназначена для улучшения субъективного качества. Отключать её имеет смысл, если нужен специально контролируемый эксперимент или требуется сравнить именно поведение без перцептуальной адаптации.

Что лучше: QP или bitrate?

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

Зачем два прохода?

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

Можно ли делать два прохода через pipe?

Технически второй проход требует повторно получить ту же последовательность. Если источник в pipe можно гарантированно воспроизвести идентично, это возможно организовать внешним скриптом; для надёжности проще использовать файл Y4M/RAW или воспроизводимый источник кадров и отдельный rcstats.

Почему в выводе много непонятных сокращений?

VVenC показывает активные инструменты VVC и быстрые алгоритмы поиска. Большинство из них не нужно менять вручную. Для повседневной работы достаточно контролировать preset, QP/VBR, QPA, refresh и параллелизм.

VVenC сам создаёт MP4?

Базовый CLI пишет VVC-битстрим. Для контейнера нужен мультиплексор либо FFmpeg с libvvenc, который может сразу упаковать закодированное видео. Аудио также обрабатывается отдельно.

Чем vvencFFapp отличается от vvencapp?

vvencFFapp предоставляет экспертный набор параметров и cfg-схему VTM. vvencapp — более простой интерфейс с пятью пресетами и основными настройками. Через --additional простой интерфейс может получить доступ ко многим длинным опциям экспертного режима.

Нужно ли вручную задавать threads?

Не обязательно. Значения по умолчанию и mtprofile auto подходят для первого запуска. Ручное число потоков полезно в пакетной системе, где нужно разделить CPU между несколькими процессами.

Почему slow не всегда вдвое лучше medium?

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

Можно ли считать QP 0 полностью lossless?

Нет, если рассматривать всю цепочку. Уже преобразование в YUV 4:2:0 может быть необратимым. Для строгого lossless нужно проверять экспертный режим, формат и равенство декодированных выборок, а не только число QP.

Как проверить, что VVC-файл исправен?

Декодировать его совместимым VVC-декодером, проверить число кадров и визуальное содержимое, а при строгом тесте сравнить метрики или хеш декодированных кадров. Воспроизведение одним конкретным медиаплеером — менее надёжный критерий, потому что его поддержка VVC может быть ограничена.

Подходит ли VVenC для live?

Энкодер имеет быстрые пресеты и развитую многопоточность, но основной акцент официального описания — эффективное real-world VVC-кодирование, особенно VoD/offline. Для жёсткого real-time сценария нужно измерять задержку на целевом оборудовании и сравнивать с решениями, специально ориентированными на live.

Как понять, что HDR сигнализируется правильно?

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

Что означает .266?

Это распространённое расширение элементарного H.266/VVC-потока. Оно не определяет контейнер и не гарантирует поддержку проигрывателем. Аналогично могут встречаться .h266 и .vvc.

Можно ли использовать VVenC как библиотеку?

Да. Проект предоставляет C API с конфигурацией, YUV-буферами, access units, функцией кодирования, инициализацией проходов и flush. На этой основе построена, в частности, интеграция libvvenc в мультимедийные системы.

Итоговый подход к работе

VVenC лучше всего раскрывается, когда процесс разбит на понятные этапы: точная подготовка YUV/Y4M, короткий тест vvencapp, проверка интерпретации входа, выбор preset и QP/VBR, корректная сигнализация цвета, затем упаковка и декодирование результата. Такой порядок позволяет использовать сложный стандарт VVC без необходимости сразу погружаться во все экспертные опции.

Для большинства задач достаточно простого приложения и пяти пресетов. Экспертный vvencFFapp, --additional, VUI/SEI/HRD и низкоуровневые coding tools нужны тогда, когда существует конкретное требование — исследование, адаптивная доставка, проверка соответствия или интеграция в собственный код. При таком подходе параметры остаются управляемыми, а результат легче воспроизводить и диагностировать.