VVenC — подробный обзор видеокодировщика Fraunhofer для работы с VVC

VVenC сжимает видеокадры в H.266/VVC и предоставляет контроль над пресетом, квантованием, битрейтом и параллельной обработкой. Это программный кодировщик Fraunhofer, а не видеоредактор с монтажной шкалой и не универсальный конвертер, который самостоятельно открывает любой MP4. Его самостоятельные приложения принимают подготовленные YUV-данные и создают сжатый видеопоток; декодирование исходного ролика, обработку звука и упаковку результата в контейнер выполняют другие компоненты.

Задать вопрос фотографу

Андрей Фёдоров

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

Задать вопрос

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

Что представляет собой VVenC

Полное название продукта — Fraunhofer Versatile Video Encoder. Его разрабатывают Fraunhofer Heinrich-Hertz-Institut, HHI, и участники проекта VVenC. Реализация написана на C++, а для подключения к другим программам предоставляется библиотека с интерфейсом на C. Публичный проект содержит исходный код, конфигурации, средства сборки и два консольных приложения.

Стандарт VVC определяет способ представления сжатого видео, а кодировщик выбирает, как использовать его инструменты для конкретного материала. Пресет, структура кадров и управление квантованием относятся именно к реализации. Поэтому «поддержка H.266» у двух программ ещё не означает одинаковые настройки, быстродействие или одинаковые файлы на выходе.

Не следует путать VVenC с VVdeC. Первый создаёт поток VVC, второй декодирует его обратно в изображения. VTM — отдельное тестовое программное обеспечение VVC, а x265 кодирует другой стандарт, H.265/HEVC. Эти названия встречаются в одних технических обсуждениях, но обозначают разные инструменты. Сторонняя графическая оболочка, использующая libvvenc, также не становится отдельной официальной редакцией VVenC.

Текущий статус, платформы и установка

Проект доступен и развивается. В стабильной версии 1.14.0 добавлено управление диапазоном видеосигнала в консольных приложениях, улучшено автоматическое включение VUI и расширены оптимизации для ARM с использованием NEON и SVE.

Основной способ распространения — исходный код в публичном репозитории fraunhoferhhi/vvenc на GitHub. Для Windows предусмотрена сборка средствами Visual Studio, для Linux — GCC, для macOS — Clang/Xcode. Сборка использует CMake 3.13 или новее; поддерживаются GCC 5 и новее, а также Visual Studio 2017 и новее. Это требования к инструментам компиляции, а не обещание, что любая старая операционная система или любой процессор запустят конкретный готовый пакет.

На x86/x86-64 необходима поддержка SSE4.1. Для ARM используются собственные пути оптимизации; Apple Silicon не следует оценивать по требованиям к x86-инструкциям. Совпадение архитектуры важно и для библиотеки, и для программы, которая её подключает: ARM64-библиотека и x86-64-приложение не образуют рабочую пару только потому, что находятся в одной папке.

На macOS доступна установка через Homebrew командой brew install vvenc. Формула содержит vvencapp и vvencFFapp; Homebrew также предоставляет пакеты для Linux. Готовую сборку выбирают под свою систему и архитектуру.

При самостоятельной сборке есть существенная деталь: установка полного экспертного приложения по умолчанию отключена. За неё отвечает параметр CMake VVENC_INSTALL_FULLFEATURE_APP=ON. Поэтому ситуация, когда библиотека и vvencapp установлены, а vvencFFapp не находится, сама по себе не означает повреждение пакета. Условия упаковки дистрибутива и настройки сборки нужно различать.

Для длительного кодирования нужна конфигурация Release: скорость отладочной сборки не характеризует производительность рабочего кодировщика. Версия проверяется командой vvencapp –version, базовая справка — vvencapp –help.

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

Интерфейс: терминал, конфигурация и журнал вместо окон

vvencapp: компактное управление основными параметрами

В простом приложении пользователь задаёт источник, место сохранения и параметры сжатия одной командой. Справка разделена на General Options, Input Options, Output Options и Encoder Options. Это логические группы текстового интерфейса, а не панели рабочего окна. Названия параметров и сообщения англоязычные; здесь нет отдельного переключателя языка графического меню.

Группа ввода описывает файл и свойства кадров. В группу вывода входит имя битового потока. Настройки кодирования определяют пресет, QP, управление битрейтом, число потоков и структуру обновления изображения. Общие параметры отвечают за справку, версию и подробность сообщений. Команда vvencapp –fullhelp открывает расширенный перечень настроек, когда базовой справки недостаточно.

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

Изображение в процессе расчёта не показывается. Сохранение результата задаётся заранее через -o, а не через диалог «Экспорт». Просмотр закодированного материала требует отдельного декодера или проигрывателя. Такая организация удобна для повторяемых запусков, но требует дисциплины: ошибочно указанное имя назначения не исправляется последующим выбором папки в окне.

vvencFFapp: экспертные настройки без платной надстройки

Полное приложение предоставляет более подробный доступ к конфигурации. Оно читает текстовые файлы параметров через -c; отдельные настройки источника и кодирования можно хранить раздельно. В комплекте есть, например, sequence.cfg и randomaccess_medium.cfg. Первый описывает последовательность, второй — конфигурацию кодирования с произвольным доступом.

Готовые файлы конфигурации нельзя считать автоматическими профилями для любого видео. В sequence.cfg заданы конкретные имя источника, размеры, частота кадров и число кадров. Перед использованием эти значения приводят в соответствие материалу. В экспертном приложении также доступен ReconFile: сохранение реконструированных кадров в raw YUV для анализа результата, а не создание ещё одного готового фильма со звуком.

Короткие параметры двух приложений не взаимозаменяемы. В vvencapp параметр -c обозначает формат пикселей, -b — битрейт, -o — сжатый выходной поток. В vvencFFapp -c подключает конфигурационный файл, -b задаёт BitstreamFile, а -o — ReconFile. Копирование команды с заменой только имени исполняемого файла меняет смысл операции.

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

libvvenc: вариант для встраивания

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

Импорт и экспорт: какие данные действительно поддерживаются

Raw YUV и YUV4MPEG2

Самостоятельные приложения работают с несжатой последовательностью YUV либо с её представлением YUV4MPEG2, обычно имеющим расширение .y4m. Raw YUV не содержит обычного описания файла: ширину, высоту, частоту и способ размещения пикселей необходимо знать заранее. Расширение .yuv само по себе не сообщает кодировщику, где заканчивается кадр и сколько байтов занимает одна компонента.

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

Ролики MP4, MOV, MKV и другие сжатые источники сначала декодируют внешним инструментом либо обрабатывают через интеграцию libvvenc. Нельзя переименовать MOV в YUV и получить пригодный вход. Аналогично программа не открывает RAW-фотографии как фоторедактор и не выполняет проявку сенсорных данных: на вход требуются уже сформированные пиксели.

Разрядность и цветовая дискретизация

В vvencapp 1.14.0 доступны обозначения yuv420, yuv420_10, yuv420_10_packed, а также монохромные yuv400 и yuv400_10 с вариантами названий gray и gray10. Для обычного цветного видео основной рабочий формат — 4:2:0. Поддержка терминов 4:2:2 или 4:4:4 в отдельных перечислениях исходного кода не означает, что текущий кодировщик принимает такие изображения как штатный внутренний формат.

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

Обычный планарный 10-битный YUV и упакованный 10-битный YUV — разные способы хранения. В первом случае отсчёт обычно занимает 16-битное слово; во втором десятибитные значения упакованы плотнее. Названия NV12 и P010 также не являются синонимами перечисленных планарных форматов. Совпадающие разрешение и разрядность недостаточны: важны порядок компонент и физическое размещение данных.

Параметр –internal-bitdepth задаёт внутреннюю разрядность кодирования, 8 или 10 бит. По умолчанию используется 10-битное кодирование. Поэтому 8-битный вход и 10-битный выход — допустимая комбинация, а не доказательство неверного распознавания источника. Однако расширение разрядности не создаёт отсутствующие оттенки исходной записи и не превращает SDR-материал в HDR.

При подготовке 10-битного источника не следует вставлять промежуточный 8-битный файл «для совместимости»: он уменьшает точность до запуска кодировщика. Разрядность проверяют на каждом звене, а не только у конечного потока.

Выходной поток и контейнер — разные результаты

Основной результат самостоятельного приложения — элементарный поток VVC. Расширение .266 удобно показывает его назначение; переименование в .mp4 не добавляет структуру MP4. Контейнер создаётся мультиплексором, который помещает закодированное видео и другие дорожки в согласованную файловую структуру.

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

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

Основные функции сжатия и их практический смысл

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

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

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

Для первичной оценки выбирают medium и несколько значений QP на одном фрагменте, затем сравнивают соседние пресеты. Остальные параметры сохраняют. Название faster означает положение внутри линейки VVenC, а не обязательную работу быстрее воспроизведения.

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

QPA: адаптация квантования к восприятию

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

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

Временная обработка и структура кадров

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

В конфигурациях присутствует MCTF — временная фильтрация с компенсацией движения. Она работает с соседними кадрами в процессе подготовки к сжатию. Её нельзя приравнивать к самостоятельному художественному шумоподавителю с просмотром «до/после», ретуши или восстановлению изображения нейросетью. Для материала, где фактура и зерно являются частью авторского решения, результат оценивают в движении, а не только по одному стоп-кадру.

Интервал обновления задаётся, в частности, через –refreshsec; тип обновления — через –refreshtype. GOP и интервал точек произвольного доступа связаны, но не обозначают одно и то же. Более частые независимые точки нужны для определённой организации доступа и сегментов, однако их выбор следует согласовывать со всей системой доставки, а не менять ради абстрактного «ускорения».

Для сегментирования предусмотрен режим idr_no_radl, использующий IDR без ведущих изображений. Это техническая настройка структуры потока, а не встроенный сервис DASH. Создание сегментов, манифеста и нескольких вариантов качества остаётся задачей внешних инструментов. Наличие подходящего режима обновления только помогает построить такую цепочку.

QP, VBR и CQF: три разных способа управлять результатом

Базовый QP — когда размер заранее не фиксирован

Параметр -q задаёт базовый уровень квантования от 0 до 63; стандартное значение — 32. При отсутствии целевого битрейта такой способ позволяет исследовать качество конкретного материала без привязки к заранее установленному размеру. Снижение QP уменьшает грубость квантования, повышение усиливает её. Зависимость итогового объёма от содержания при этом сохраняется.

Значение QP нельзя переносить из другого кодировщика как универсальную оценку качества. VVenC с QP 30 и x265 с CRF 30 не обязаны сохранять одинаковую детализацию. Различаются модели управления, предсказание и адаптация. Для выбора настройки нужны одинаковый исходник и одинаковые условия просмотра; совпадение чисел не делает сравнение равным.

Малый QP сам по себе не гарантирует архивную копию, идентичную оригиналу. Для точного сохранения исходных отсчётов проверяют всю цепочку преобразований и реконструкцию, а не объявляют профиль «без потерь» из-за одного параметра.

VBR — когда важен целевой средний битрейт

Параметр -b включает управление битрейтом. Число задаётся в битах в секунду, поддерживаются суффиксы: например, -b 2M означает 2 000 000 бит/с. Режим VBR распределяет данные по последовательности с учётом её сложности; это не обязательное выделение одинакового числа байтов каждому кадру.

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

Доступны один и два прохода. При -p 1 кодирование не требует предварительного полного прохода по файлу, но использует анализ будущих кадров; «однопроходный» не означает «без задержки». При -p 2 данные первого прохода используются для управления следующим. В vvencapp при активном управлении битрейтом стандартным выбором являются два прохода.

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

Ограничение битрейта и Constant Quality Factor

Через -m задаётся приблизительное ограничение мгновенного битрейта. В сочетании с VBR оно ограничивает всплески, но не превращает выход в строго постоянный поток данных. При одновременном задании среднего и максимального битрейта предел должен быть не ниже полутора целевых средних значений. Например, сочетание -b 2M и -m 5M соответствует этому требованию.

В режиме CQF, Constant Quality Factor, объединяются базовый QP, перцептивная адаптация и ограничение максимального битрейта без заданного среднего. Конфигурация вида -q 30 –qpa 1 -m 5M задаёт именно такую логику: ориентир по квантованию сохраняется, но свобода увеличивать поток ограничена. Этот режим нельзя считать буквальным аналогом параметра CRF из другого кодировщика.

Цвет, HDR и зерно: что нужно настроить до запуска

VVenC поддерживает обозначение SDR и HDR-сигналов. Среди вариантов есть –sdr sdr_709 для SDR BT.709, а также –hdr pq_2020 и –hdr hlg_2020 для соответствующих HDR-представлений с основными цветами BT.2020. Параметры описывают входной сигнал и влияют на связанную конфигурацию; выбирать их следует по характеристикам материала, а не по желанию сделать картинку «богаче».

В версии 1.14.0 диапазон обозначается через –range. Основные варианты — limited и full; также предусмотрено unknown. Неверная интерпретация ограниченного диапазона как полного или наоборот меняет отображение чёрного, белого и полутонов. Установка нужного признака не исправляет автоматически пиксели, уже некорректно преобразованные на предыдущем этапе.

Основные цвета, передаточная характеристика, матрица и диапазон — разные свойства. Для кадров, выгруженных из камеры или монтажной системы, одного названия «HDR» недостаточно. Например, выбор PQ не заменяет сведения о цветовом охвате и параметрах мастеринга. Экспертные настройки предусматривают параметры MasteringDisplayColourVolume и MaxContentLightLevel, но их нельзя заполнять произвольными числами по шаблону от другого фильма.

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

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

Есть экспериментальный анализ плёночного зерна, включаемый через –fga, с формированием соответствующих SEI-данных. Он требует включённой MCTF и интервала внутрикадрового обновления больше одного кадра. Использование описания зерна требует согласованного поведения декодера и отдельной оценки результата. QPA, MCTF и анализ зерна не являются генеративной ретушью или ИИ-восстановлением кадров.

Производительность, память и параллельная работа

Расчёт выполняется на центральном процессоре. Оптимизации SSE4.1, NEON и SVE относятся к процессорным инструкциям, а не к видеокарте. Наличие мощного GPU само по себе не ускоряет libvvenc как аппаратный NVENC-кодировщик. Внешний инструмент способен использовать GPU на другом этапе обработки, но это не меняет вычислительную модель VVenC.

Число рабочих потоков задаётся через -t. Автоматические значения зависят от разрешения и не означают безусловное использование всех логических процессоров системы. Параметр –mtprofile управляет согласованным применением нескольких способов параллелизма, включая тайлы, межкадровую обработку IFP и WPP. Для начала полезнее оставить согласованную автоматическую конфигурацию, чем независимо включить все доступные механизмы.

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

Несжатые промежуточные данные требуют заметного дискового пространства. Один кадр 1920 × 1080 в 8-битном YUV 4:2:0 содержит 3 110 400 байт. Для 250 кадров это 777 600 000 байт, то есть около 777,6 МБ без заголовков. В обычном 10-битном представлении с 16-битным хранением отсчётов объём удваивается до 1 555 200 000 байт. Y4M добавляет к пиксельным данным собственные заголовки.

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

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

Пример рабочего сценария: контрольная VVC-копия готового ролика

Воспроизводимый пример начинается с конкретных исходных условий. Пусть source.mp4 — готовый прогрессивный SDR-ролик 1920 × 1080 с постоянной частотой 25 кадров/с, цветом BT.709, ограниченным диапазоном и 8-битным изображением. В нём должно быть не менее 250 кадров. Для примера используются FFmpeg, vvencapp 1.14.0 и техническое приложение vvdecapp из отдельного проекта VVdeC. Файлы сохраняются в рабочую папку, где нет одноимённых результатов.

Подготовка одинакового входа для сравнения

Сначала получают 250 несжатых кадров первой видеодорожки. Аудио в этом примере не требуется: цель — проверить сжатие и восстановление изображения. Команда подготовки:

ffmpeg -i source.mp4 -map 0:v:0 -frames:v 250 -an -pix_fmt yuv420p -f yuv4mpegpipe sample.y4m

Полученный sample.y4m содержит десять секунд при заданной частоте и становится единым входом для сравнений. Команда не предназначена для HDR-мастера или сохранения 10-битного оригинала: её 8-битный формат выбран под оговорённые условия.

Кодирование с явными параметрами

Начальный вариант создаётся с medium, базовым QP 30 и включённой QPA. Разрядность кодирования и сведения о сигнале указаны явно:

vvencapp -i sample.y4m –preset medium -q 30 –qpa 1 –internal-bitdepth 10 –sdr sdr_709 –range limited -o sample-q30.266

Имя sample-q30.266 обозначает отдельный результат. Для сравнения степени квантования можно повторить команду с -q 34 и другим именем, например sample-q34.266, сохранив остальные параметры. Сравнивают размер, восстановленные кадры и время обработки. Выбранные числа являются начальными точками сравнения, а не готовым стандартом качества для любых сюжетов.

Для варианта с целевым средним битрейтом та же подготовленная последовательность обрабатывается иначе:

vvencapp -i sample.y4m –preset medium -b 2M -m 5M -p 2 –qpa 1 –internal-bitdepth 10 –sdr sdr_709 –range limited -o sample-vbr.266

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

Декодирование и проверка полноты

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

vvdecapp -b sample-q30.266 -o decoded-q30.y4m

Восстановленный Y4M позволяет исследовать результат независимо от поддержки VVC обычным видеоплеером. Число кадров и геометрию можно вывести через ffprobe:

ffprobe -v error -select_streams v:0 -count_frames -show_entries stream=width,height,pix_fmt,nb_read_frames -of default=noprint_wrappers=1 decoded-q30.y4m

Для заданного примера ожидаются 1920 × 1080 и 250 прочитанных кадров; разрядность реконструкции соответствует выбранному кодированию. Затем проверяют движение, детали и тональные переходы относительно sample.y4m. Сопоставление только с исходным MP4 без учёта стадии подготовки смешивает потери предварительного преобразования и собственно VVC-сжатия.

Использование через FFmpeg: готовый контейнер без промежуточного YUV-файла

Поддержка libvvenc включена в основной проект FFmpeg начиная с версии 7.1, но конкретная сборка должна быть подготовлена с –enable-libvvenc. Установка самостоятельного vvencapp не добавляет кодировщик в уже собранный FFmpeg. Проверка выполняется командой ffmpeg -hide_banner -h encoder=libvvenc: она должна показать справку именно по этому кодировщику.

Пример создания MP4 с первой видеодорожкой и, при её наличии, первой аудиодорожкой:

ffmpeg -i source.mp4 -map 0:v:0 -map “0:a:0?” -c:v libvvenc -preset medium -qp 30 -pix_fmt yuv420p10le -c:a aac -b:a 192k output-vvc.mp4

Параметр -c:v выбирает библиотеку, -qp задаёт квантование через интерфейс FFmpeg. Входное представление интеграции — yuv420p10le; его не следует путать с обозначением yuv420_10 в самостоятельном приложении. Звук кодируется средствами FFmpeg в AAC. Эта команда не сохраняет все аудиодорожки и субтитры автоматически: выбор потоков здесь специально ограничен.

Десятибитный буфер интеграции и восьмибитное внутреннее кодирование — разные уровни настройки. Дополнительные параметры передаются через -vvenc-params, а не через –additional из vvencapp. Допустимые параметры обёртки определяет справка установленного FFmpeg.

Автоматическое выполнение обоих проходов в vvencapp нельзя переносить на FFmpeg как свойство любого вызова библиотеки. Многопроходность настраивают для выбранной оболочки; в конечном контейнере отдельно проверяют временные метки и синхронизацию аудио.

Автоматизация, пакетные задания и работа с потоком данных

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

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

Самостоятельное приложение читает стандартный ввод через -i –. Для Y4M в канале дополнительно задают –y4m. Это позволяет получать несжатые кадры от другой программы без промежуточной записи на диск. Но обычный канал не предоставляет повторного произвольного чтения: автоматическое выполнение обоих проходов по такому входу не поддерживается.

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

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

Приватность и лицензирование

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

Локальность не равна автоматической защите материалов. Несжатые YUV/Y4M-файлы содержат изображения, журналы — параметры и пути, а статистика проходов — сведения об обработке. Для конфиденциальной съёмки нужно учитывать права на рабочие папки, резервное копирование и синхронизацию каталогов. Передача журнала в публичное обсуждение требует удаления чувствительных имён и путей. У сторонней оболочки или облачного сервера действуют собственные правила обработки данных.

Исходный код распространяется по Clear BSD, BSD-3-Clause-Clear. Лицензия разрешает использование, изменение и распространение при соблюдении её условий, включая сохранение необходимых уведомлений. Платной разблокировки пресетов, лимита минут, обязательного водяного знака и подписки для самостоятельного кодировщика нет. vvencFFapp — не покупаемая Pro-редакция, а другой интерфейс к той же библиотеке.

Лицензия на программный код не предоставляет патентных прав. Это прямо отделённое условие Clear BSD. Поэтому бесплатное получение VVenC нельзя переводить в утверждение о безусловно бесплатном коммерческом использовании всех технологий VVC. Для коммерческого продукта или сервиса патентные вопросы оцениваются отдельно с учётом характера использования и применимых территорий; юридическое заключение не заменяется выбором открытой библиотеки.

Типичные проблемы и способы диагностики

Программа не запускается или не находится

Сначала отделяют отсутствие команды в PATH от ошибки самого исполняемого файла. Запуск с явным путём показывает, установлен ли нужный компонент. Затем проверяют архитектуру и наличие зависимых библиотек. Для сообщения о недопустимой инструкции на x86 сверяют поддержку SSE4.1 и происхождение сборки. Переустановка видеоплеера или пакета аудиокодеков не устраняет несовпадение процессорной архитектуры.

Параметр не распознаётся

Первая проверка — имя приложения и его –help. Параметры vvencapp, vvencFFapp и обёртки FFmpeg различаются. Вторая — версия: например, –range относится к актуальному выпуску 1.14.0, а не к любому старому бинарному файлу. В автоматизации полезно сохранять вывод –version вместе с командой, чтобы случайная подмена программы в PATH была заметна.

Изображение полосатое, цвета перепутаны или кадры смещены

Для raw YUV проверяют размеры, разрядность, порядок компонент и упаковку. Неверное описание меняет границы чтения: данные следующей строки или компоненты интерпретируются не на своём месте. Корректность источника сначала подтверждают отдельным просмотром с теми же параметрами либо повторно создают Y4M с известными характеристиками. Подбор QP не исправляет ошибку размещения пикселей.

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

Проверяют -f, пропуск начальных кадров и настройки конфигурационного файла. Для источника без заголовка отдельно сверяют частоту, включая её знаменатель. Частоты 30 и 30000/1001 не идентичны. При вводе через канал изучают журнал поставщика данных и код его завершения. Размер выходного файла не заменяет подсчёт декодированных кадров.

Второй проход не использует статистику

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

Чёрный стал серым или изменились света

Сначала сопоставляют диапазон и цветовые характеристики до кодирования и после декодирования. Затем проверяют настройки преобразования во внешнем инструменте и интерпретацию сигнала проигрывателем. Увеличивать битрейт до устранения несоответствия limited/full бессмысленно: больше данных не исправляет неправильное отображение уровней.

Файл создан, но не воспроизводится

Элементарный .266 проверяют VVC-декодером, а контейнер — приложением, поддерживающим и его структуру, и VVC. Отсутствие такой поддержки нужно отличать от ошибки потока. Через FFmpeg полезно отдельно проверить список кодировщиков и декодировщиков: присутствие libvvenc не доказывает наличие декодера в той же сборке.

Результат пустой или предыдущая копия исчезла

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

Как принимать результат, а не только завершённый процесс

Техническая приёмка включает успешное завершение кодирования, полное декодирование и совпадение ожидаемых характеристик. Проверяются число кадров, размеры, разрядность, цвет и, для контейнерного результата, дорожки и длительность. Для MP4 сведения можно вывести командой ffprobe -v error -show_streams -show_format output-vvc.mp4. Чтение заголовков само по себе ещё не является полным декодированием.

При наличии VVC-декодера в FFmpeg команда ffmpeg -v error -i output-vvc.mp4 -map 0:v:0 -f null – проходит видеодорожку без записи большого восстановленного файла. Отсутствие сообщений об ошибках нужно рассматривать вместе с кодом завершения и полнотой обработки. Такой контроль не оценивает художественное качество и не проверяет звук, поскольку команда выбирает только видео.

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

Плюсы и минусы

Кому подойдёт и кому не подойдёт

Кому подойдёт

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

Кому не подойдёт

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

Альтернативы для других задач

uvg266 — другая открытая реализация VVC

Кодировщик Ultra Video Group тоже создаёт H.266/VVC и предоставляет консольное приложение и C API. Он основан на разработках проекта Kvazaar и продолжает развиваться. Его уместно рассматривать для инженерного сравнения реализаций одного стандарта. Это не способ получить более привычный графический интерфейс или обойти необходимость VVC-декодера: конечный стандарт остаётся тем же, а настройки и результаты нужно сравнивать отдельно.

x265 — когда в процессе нужен HEVC

x265 кодирует H.265/HEVC, а не VVC. У него есть консольное приложение, библиотека, пресеты и собственные режимы управления качеством, включая CRF. Это осмысленная альтернатива для уже налаженного HEVC-процесса и согласованного оборудования воспроизведения. Настройки QP и CRF между продуктами напрямую не переводятся; преимущество такого выбора определяется требованиями получателя, а не более знакомым названием параметров.

SVT-AV1 — для процесса распространения в AV1

SVT-AV1 — программный кодировщик и библиотека для AV1, развиваемые в экосистеме AOMedia. Он доступен как самостоятельный инструмент и используется другими программами, включая FFmpeg и HandBrake. Его выбирают, когда целевая система ориентирована на AV1. Это смена формата распространения, а не другая сборка VVenC. Для сравнения важно одновременно учитывать время обработки, размер и изображение, не сопоставляя только номера пресетов.

HandBrake — когда важнее законченный процесс конвертации

HandBrake предоставляет графический интерфейс, очередь, предварительный просмотр, работу с аудио и субтитрами и создание MP4, MKV или WebM. Среди программных кодировщиков есть x265 и SVT-AV1. Он удобнее для подготовки обычных пользовательских копий без самостоятельной сборки цепочки из нескольких приложений. Это альтернатива организации работы, а не официальная графическая редакция VVenC: выбор контейнера, кодека и доступных настроек у неё собственный.

FAQ: детали, которые важны после первого запуска

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

Число входных кадров можно ограничить параметром -f 1. Однако источник всё равно должен быть представлен поддерживаемыми пикселями, а результатом останется VVC-поток. Этот опыт пригоден для исследования кодирования отдельного кадра, но не заменяет экспорт фотографии с привычными метаданными в JPEG или другой фотографический формат.

Почему в статистике для P-кадров встречается нулевое количество и NaN?

Статистика рассчитывается отдельно по типам I, P и B. Когда кадров определённого типа нет, для его средних значений отсутствуют данные. В межкадровой структуре с B-кадрами отсутствие P само по себе не является ошибкой. О повреждении судят по сообщениям кодировщика и декодера, а не по пустой категории статистики.

Обязаны ли Windows и Linux создавать побитово одинаковые файлы?

Для такого требования нужно контролировать версии, конфигурации и особенности сборки, включая арифметику с плавающей точкой. Предусмотрен параметр CMake VVENC_FFP_CONTRACT_OFF=ON для отключения соответствующего объединения операций компилятором. Различие контрольных сумм файлов само по себе не доказывает повреждение: отдельно проверяются декодируемость и восстановленное изображение.

Является ли статистика первого прохода резервной копией результата?

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

Почему порядок кадров в подробном журнале отличается от порядка просмотра?

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

Итог: когда выбор VVenC оправдан

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

При передаче ролика важнее требования получателя: согласованный HEVC или AV1-процесс не нужно менять только ради нового стандарта. Для конвертации с просмотром и звуком графический транскодер потребует меньше настройки. VVenC оправдан там, где нужен контроль именно над VVC и проверяется весь путь до воспроизведения.