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

VVdeC превращает сжатый видеопоток H.266/VVC в несжатые кадры, которые можно передать проигрывателю, системе обработки видео или сохранить для анализа. Это не видеоредактор и не конвертер с окном предпросмотра: продукт состоит из программной библиотеки и консольного приложения vvdecapp. Его имеет смысл выбирать, когда нужен именно декодер VVC — для проверки закодированного материала, получения кадров YUV или встраивания поддержки формата в собственное приложение.

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

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

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

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

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

Полное название продукта — Fraunhofer Versatile Video Decoder. Основной разработчик — Fraunhofer HHI, Институт телекоммуникаций имени Генриха Герца, при участии других авторов проекта. Реализация написана на C++, а наружу предоставляет интерфейс на языке C. Такое устройство позволяет подключать декодер к приложениям, не связывая их со всеми внутренними классами его движка.

Программа реализует декодирование стандарта H.266, также называемого VVC — Versatile Video Coding. Поддерживаемая область включает все средства профиля Main10. Для обычного рабочего процесса это означает прежде всего видеоматериал с цветовой субдискретизацией 4:2:0 и глубиной 8 или 10 бит. Название Main10 не означает, что любой файл с десятибитным изображением совместим: кодек и профиль потока также должны соответствовать декодеру.

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

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

Что изменилось в ветке 3.x

VVdeC развивается и распространяется с открытыми исходниками. Версия 3.2.0 добавила реализации с NEON, NEON-RDM, SVE и SVE2 для многих вычислительных операций и расширила определение возможностей ARM-процессора. Набор доступных векторных инструкций зависит от конкретного оборудования: наличие сборки ARM не означает поддержку всех этих расширений одновременно.

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

При переходе с веток 1.x и 2.x существенна версия 3.0: она изменила API и нарушила прежнюю бинарную совместимость. Зависимые приложения необходимо пересобирать, а не просто заменять файл библиотеки. В той же версии появился синтез плёночного зерна, а масштабирование выходного изображения было перенесено из библиотеки в пример приложения. Выпуск 3.1 добавил в vvdecapp упакованный вывод YUV.

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

Какие системы действительно входят в охват

VVdeC собирается для Windows Win32, x64 и ARM64; для Linux — x86, x86-64, ARMv7 и ARM64. На macOS предусмотрены Intel x64 и Apple Silicon ARM64. Поддержка архитектуры означает наличие соответствующего пути сборки и проверки проекта, но не наличие единственного универсального установщика, одинаково подходящего всем перечисленным системам.

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

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

Официальный выпуск 3.2.0 распространяется архивами исходного кода ZIP и TAR.GZ. В составе файлов этого релиза нет отдельного графического установщика Windows или macOS. Сборка использует CMake и компилятор с поддержкой C++14; в зависимости от системы это инструменты Visual Studio, GCC или Clang. Пользователю без среды разработки проще начинать с готового пакета для своей системы, проверяя его происхождение и версию.

Пакет Homebrew устанавливается командой brew install vvdec и включает vvdecapp. Пакетный менеджер выступает поставщиком сборки; её версия и архитектура должны соответствовать рабочему компьютеру. Готовый пакет снимает необходимость компилировать код, но не меняет назначение продукта.

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

Интерфейс: вместо окна редактора — команда и журнал

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

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

Справка и основные группы параметров

vvdecapp –help выводит краткую справку, а vvdecapp –fullhelp — дополнительные настройки, включая параметры синтеза зерна, масштабирования RPR и SIMD. Команда vvdecapp –version позволяет установить версию фактически запускаемого приложения. Проверять именно исполняемый файл полезнее, чем ориентироваться на название когда-то скачанного архива: в PATH могут находиться несколько сборок.

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

Как читать сообщения приложения

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

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

Отсутствие файла после успешного запуска — нормальный результат, когда не указан –output. В таком режиме приложение выполняет декодирование без сохранения кадров. Это полезно для проверки совместимости или оценки вычислительной части, однако для получения YUV либо Y4M путь вывода нужно задать явно.

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

Восстановление кадров VVC

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

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

Параллельность и задержка разбора

Настройка –threads определяет рабочий пул декодера — группу параллельно выполняющих работу потоков. Значение -1 включает автоматический выбор по доступной процессору логической параллельности. Значение 0 отключает рабочий пул и задаёт однопоточный режим обработки. Значение 1 создаёт пул из одного рабочего потока, но не равнозначно строгому ограничению всего процесса одним ядром, поскольку у приложения остаётся основной поток выполнения.

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

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

SIMD: ускорение на процессоре

SIMD-инструкции позволяют выполнять однотипные операции над несколькими значениями одновременно. VVdeC использует такие оптимизации на поддерживаемых архитектурах. Для x86 в приложении предусмотрены варианты SSE4.1, SSE4.2, AVX и AVX2; в текущей ветке ARM — NEON и более новые расширения соответствующих процессоров. Перечень реально доступных путей зависит от платформы и сборки.

Режим –simd -1 выбирает доступный вариант автоматически, а –simd 0 включает скалярный путь. Последний полезен для диагностики различий между оптимизированной и обычной обработкой, но не предназначен для получения «более качественного» изображения. Принудительный выбор неподдерживаемой процессором инструкции не расширяет возможности оборудования.

SIMD не относится к видеокарте: у VVdeC нет переключателя CUDA, превращающего библиотеку в аппаратный GPU-декодер. Приложение может отдельно использовать графическую систему для отображения, но это другой этап обработки.

Синтез зерна и масштабирование RPR

–filmGrain управляет синтезом плёночного зерна по сообщениям Film Grain Characteristics SEI в потоке. По умолчанию он включён. Это воспроизведение описанного в видеоданных эффекта, а не универсальный фильтр для добавления зернистости к любому ролику. Настройка не выполняет нейросетевое восстановление, ретушь или шумоподавление.

–upscale относится к изображениям RPR — Reference Picture Resampling, связанным с изменением разрешения внутри потока. В приложении есть три режима: 0 — без дополнительного масштабирования выхода, 1 — размещение изображения в целевом размере без пересчёта масштаба, 2 — масштабирование до целевого разрешения. Это не произвольный экспорт в выбранные пользователем размеры и не ИИ-увеличение детализации.

Важное отличие библиотеки от утилиты: начиная с 3.0 такая обработка выхода находится на стороне приложения. Разработчик собственного проигрывателя не должен рассчитывать, что один вызов декодирования автоматически воспроизведёт все действия vvdecapp по подготовке постоянного размера кадра.

Проверка хешей и обработка ошибок

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

–CheckYuvMD5 решает другую задачу: сравнивает контрольную сумму полного декодированного YUV с заданным ожидаемым значением. Для неё нужен достоверный эталон. Контрольная сумма сжатого входного файла не подходит; сумма файла Y4M с заголовками также не является автоматически тем же самым значением. Различать объект проверки необходимо ещё до запуска.

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

Входные и выходные форматы без путаницы

Элементарный поток не равен контейнеру

vvdecapp принимает поток VVC в представлении Annex B: сжатые данные разделены на блоки NAL, границы которых обозначаются стартовыми последовательностями. Встречаются имена с расширениями .266, .vvc или .bit, однако решающим остаётся содержимое. Переименование файла .mp4 в .266 не извлекает видеодорожку и не меняет способ упаковки данных.

MP4, MKV и MOV — контейнеры, в которых могут находиться видеодорожки разных кодеков, звук, субтитры и временные метки. Штатное приложение VVdeC не разбирает их как универсальный демультиплексор. Сначала нужен компонент, который выделит совместимый VVC-поток и представит его в требуемом виде. Наличие H.264, HEVC или AV1 внутри контейнера не позволяет обработать его этим декодером.

Для MP4, первая видеодорожка которого действительно закодирована в VVC, подготовку входа можно выполнить средствами FFmpeg. Нужна сборка с фильтром vvc_mp4toannexb и выходным форматом vvc. Команда извлекает только выбранную видеодорожку, не выполняет повторного кодирования и не сохраняет звук:

ffmpeg -i source.mp4 -map 0:v:0 -c:v copy -bsf:v vvc_mp4toannexb -f vvc input.266

Это предварительная обработка внешним инструментом, а не функция vvdecapp. Для проверки содержимого контейнера подходит ffprobe source.mp4; для проверки наличия фильтра — список ffmpeg -bsfs. При другой кодировке дорожки приведённая операция не превращает её в VVC.

YUV, Y4M и упакованные данные

Обычный выход YUV содержит значения яркости и цветоразностных компонент. В рассматриваемом процессе 8-битное 4:2:0 соответствует yuv420p, а 10-битное — yuv420p10le: десятибитные значения размещаются в шестнадцатибитных элементах. Голый файл .yuv не хранит самодостаточного описания ширины, высоты и частоты кадров. Эти параметры должны сопровождать его отдельно.

YUV4MPEG2, обычно обозначаемый расширением .y4m, добавляет заголовок и маркеры кадров. Он удобнее для передачи между совместимыми инструментами: в нём описаны размер изображения, частота и представление компонент. Однако сами кадры остаются несжатыми. Y4M не является альтернативой компактному MP4 для отправки клиенту или загрузки на сайт.

Формат выбирается параметром –y4m либо распознаётся по расширению .y4m у выходного имени. Для вывода в канал, где имени файла с расширением нет, явное указание особенно полезно. Опция –pyuv или окончание .pyuv включает плотную упаковку YUV. Для 10-битных данных четыре отсчёта помещаются в пять байт вместо восьми байт при хранении в шестнадцатибитных элементах.

Для этих 10-битных данных плотная упаковка сокращает объём на 37,5%, но требует поддержки читающим инструментом. Открытие .pyuv как обычного yuv420p10le даст неправильную интерпретацию отсчётов. Одновременно включить упакованный YUV и Y4M в vvdecapp нельзя.

Нативного сохранения в JPEG, PNG или TIFF у vvdecapp нет. Для получения отдельных фотографий из видеоряда понадобятся преобразование цвета и отдельный инструмент записи изображений. Название raw YUV тоже не следует путать с камерным RAW: это уже восстановленные видеокомпоненты, а не исходные показания сенсора с возможностями проявки.

Цвет, HDR и частота кадров

Глубина 10 бит не доказывает наличие HDR. Для правильной интерпретации важны передаточная функция, цветовые первичные координаты, матрица преобразования и диапазон уровней. API VVdeC предоставляет связанные с изображением параметры VUI и доступ к SEI, в том числе описаниям мастеринг-дисплея и уровней яркости. Их наличие не означает, что консольный вывод автоматически организует цветоуправление на мониторе.

Сохранение обычного YUV не переносит всю информацию исходного контейнера. Заголовок Y4M в vvdecapp описывает геометрию, частоту, тип развёртки и формат компонент, но не заменяет полноценный контейнер со звуком и всеми метаданными HDR. Для профессиональной цепочки сведения о цвете нужно передавать и проверять отдельно на каждом переходе.

Есть конкретная особенность определения частоты: при наличии подходящих данных HRD приложение использует временные параметры потока, а при их отсутствии начинает с значения 50/1 для заголовка Y4M. Поэтому созданный файл нельзя безусловно считать носителем достоверной частоты оригинала. Неправильная скорость воспроизведения после декодирования требует проверки временных данных, а не только количества изображений.

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

Нагрузка определяется разрешением, частотой и структурой потока, глубиной изображения, рабочим пулом и способом передачи кадров. Сам факт запуска программы на компьютере не гарантирует декодирование любого 4K- или 8K-материала в реальном времени.

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

Запись несжатого выхода способна стать отдельным узким местом. Для кадра 4:2:0 с чётными шириной и высотой 8-битное представление занимает 1,5 × ширина × высота байт. При хранении 10-битных отсчётов в шестнадцатибитных элементах размер составляет 3 × ширина × высота. Это расчёт данных изображения, а не полного потребления оперативной памяти декодером.

Например, один кадр 1920 × 1080 в обычном 10-битном YUV занимает 6 220 800 байт. При 25 кадрах в секунду получается 155,52 МБ/с, а минута — около 9,33 ГБ без заголовков. Это расчётный пример для заданного представления, не результат измерения VVdeC. Y4M добавляет служебные данные, упакованный YUV использует другую схему хранения.

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

Пример рабочего сценария: из VVC в проверяемый Y4M

Для локального получения несжатого видео понадобятся корректный элементарный поток Main10 и vvdecapp с описанными параметрами. В примере исходник обозначен как input.266: это заранее подготовленный VVC-поток, например результат работы кодировщика. При повторении команд замените имя своим путём к файлу.

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

Для сборки из распакованных исходников с современным CMake можно создать отдельный каталог и явно включить установку приложения. Следующие команды выполняются из корня исходного дерева; число 4 в параметре –parallel ограничивает параллельность компиляции, а не последующего декодирования:

cmake -S . -B build-review -DCMAKE_BUILD_TYPE=Release -DVVDEC_INSTALL_VVDECAPP=ON

cmake –build build-review –config Release –parallel 4

cmake –install build-review –config Release –prefix ./local-vvdec

Локальный префикс отделяет эту установку от системной. В Linux и macOS приложение в таком размещении вызывают через ./local-vvdec/bin/vvdecapp, а в PowerShell — через .local-vvdecbinvvdecapp.exe. Ниже для краткости используется имя vvdecapp: оно предполагает, что каталог программы уже находится в PATH или заменён полным путём к исполняемому файлу.

Проверка потока и сохранение

1. Установите версию запускаемого приложения командой vvdecapp –version. Сверьте доступные параметры через –fullhelp. Это исключает применение новых опций к старой сборке.

2. Выполните короткий запуск без сохранения: vvdecapp -b input.266 -f 100 -v 3. Ограничение позволяет начать с небольшой части материала. Количество полученных кадров зависит от содержимого файла; команда не гарантирует сто изображений из короткого или повреждённого потока.

3. После успешного разбора сохраните полный результат: vvdecapp -b input.266 -o decoded.y4m -t -1 -v 3. Здесь нет ограничения -f, а расширение выхода включает Y4M.

4. Дождитесь завершения процесса и проверьте сообщения об ошибках, число кадров и наличие результата. Для входа с контрольными SEI можно дополнительно включить -dph; без соответствующих данных потока эта проверка не заменяет независимый эталон.

5. Откройте результат отдельным проигрывателем, например командой ffplay decoded.y4m. FFplay входит в инструментарий FFmpeg и не является частью VVdeC; его нужно установить отдельно.

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

Проверка характеристик результата

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

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

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

Для процесса с заранее известными параметрами можно вместо Y4M получить decoded.yuv. Например, несжатый выход 1920 × 1080, 25 кадров/с, 10 бит, 4:2:0 открывается так: ffplay -f rawvideo -pixel_format yuv420p10le -video_size 1920×1080 -framerate 25 decoded.yuv. Эти значения нельзя переносить на неизвестный материал: здесь они являются условиями примера, а не универсальными настройками.

Использование библиотеки в собственном приложении

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

Типовая последовательность начинается с vvdec_params_default и настройки vvdecParams, затем создаётся экземпляр через vvdec_decoder_open. Входные данные описывает vvdecAccessUnit: у него есть буфер, его размер и фактически занятая длина, а также поля временных меток. Подготовленные данные подаются в vvdec_decode. Передавать произвольный кусок MP4 вместо ожидаемого представления NAL нельзя.

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

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

У каждой плоскости кадра есть указатель, ширина, высота, шаг строки и размер отсчёта. Шаг строки измеряется в байтах и не обязан совпадать с числом видимых пикселей. Код, который копирует память как плотный массив без учёта stride, способен испортить изображение даже при правильном декодировании. После использования кадр освобождается через vvdec_frame_unref; обращаться к его данным после освобождения нельзя.

Библиотека поддерживает внешний распределитель памяти через vvdec_decoder_open_with_allocator. Это даёт приложению контроль над выделением буферов, но не гарантирует автоматически передачу кадров на GPU без копирования. Сопутствующие ошибки уточняются через vvdec_get_last_error и vvdec_get_last_additional_error, а параметры цвета и SEI получают из атрибутов соответствующих кадров.

Автоматизация, мультимедийные системы и браузер

Пакетная работа без встроенного менеджера очереди

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

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

Выход -o – направляет данные в стандартный вывод; для Y4M в этом случае нужен явный параметр –y4m. Такой способ позволяет передавать изображения следующему процессу без обязательного промежуточного файла. Это свойство командной обработки, а не встроенная облачная функция.

FFmpeg и GStreamer

В экосистеме FFmpeg необходимо различать собственный VVC-декодер и обёртку libvvdec. Наличие декодера с именем vvc не доказывает, что используется библиотека Fraunhofer. Для интеграции именно libvvdec проект VVdeC предусматривает отдельное применение соответствующего патча к FFmpeg и сборку с –enable-libvvdec. Нельзя считать поддержку этой обёртки обязательной для любого готового пакета FFmpeg.

Практическая проверка начинается с ffmpeg -decoders: нужно установить имя доступного декодера. Поддержка кодировщика libvvenc отвечает на другой вопрос и не подтверждает наличие libvvdec. Зато контейнеры, фильтры, обработка звука и конечное кодирование в такой связке относятся к FFmpeg, а не становятся собственными функциями VVdeC.

В GStreamer существует элемент vvdec. Его место в цепочке хорошо показывает разделение ответственности: источник читает файл, qtdemux разбирает MP4, h266parse подготавливает VVC, vvdec восстанавливает изображения, а последующие элементы преобразуют цвет и выводят видео. Здесь воспроизведение контейнера обеспечивается всей системой, хотя собственно декодирование выполняет рассматриваемая библиотека.

VVdeC Web Player и мобильное использование

VVdeC Web Player — отдельный демонстрационный веб-проигрыватель на JavaScript, HTML и WebAssembly. Он использует скомпилированный декодер и умеет работать с элементарными потоками, MP4 и сегментированным DASH в пределах своей реализации. Поддержка DASH минимальная и не означает готовую платформу живого вещания; аудио в этом демонстрационном проигрывателе не поддерживается.

Выполнение WebAssembly происходит в браузере, однако страницу и необходимые файлы должен доставить веб-сервер. Для многопоточного режима существенны настройки изоляции страницы, включая COOP и COEP; вне локального окружения требуется HTTPS. Неисправность такой конфигурации не равнозначна несовместимости самого видеопотока с декодером.

Мобильное встраивание и веб-проигрыватель не являются платными редакциями VVdeC. Функции галереи, совместной работы и отправки файлов принадлежат внешнему приложению. У самой библиотеки нет ИИ-монтажа, распознавания объектов или генерации деталей изображения.

Лицензия, стоимость и приватность

Что означает бесплатное распространение

Исходный код VVdeC доступен по лицензии BSD-3-Clause-Clear, также называемой Clear BSD. У проекта нет разделения на Free и Pro с заблокированными разрешениями, водяными знаками или ограничением количества обработанных минут. Не предусмотрены подписка на декодирование, пробный период и активация перед локальным запуском.

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

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

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

Что остаётся локально и где возникают риски

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

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

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

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

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

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

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

Ошибки загрузки библиотеки после обновления требуют проверки комплекта зависимостей и бинарной совместимости. Особенно важен переход с VVdeC 1.x или 2.x на 3.x. Случайное копирование DLL из другой программы не является корректным способом обновления: приложение и зависимая библиотека должны относиться к совместимой сборке.

Входной файл открывается, но изображения не появляются

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

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

Файл получен, но изображение искажено

Полосы, неправильные цвета и смещение строк в просмотрщике YUV требуют проверки ширины, высоты, субдискретизации и представления отсчётов. Особенно легко перепутать 8-битный YUV, 10-битный YUV в шестнадцатибитных элементах и плотную упаковку .pyuv. Начать локализацию удобно с Y4M, чтобы убрать ручное угадывание части параметров.

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

Часть кадров отсутствует или нарушена длительность

Убедитесь, что не осталось ограничения -f от короткого прогона. В собственной интеграции проверьте получение задержанных кадров через vvdec_flush. В выходе Y4M сравните указанную частоту с известной частотой исходника: запасное значение 50/1 при отсутствии временных данных способно изменить скорость показа, хотя изображения были восстановлены.

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

Декодирование слишком медленное или нестабильное

Проверьте конфигурацию Release, выбранный SIMD-путь и конкурирующие процессы. Затем сравните запуск без –output с записью на диск. Большое расхождение между ними указывает на влияние вывода и хранения, а не только на скорость восстановления кадров. На ноутбуке длительный прогон следует оценивать отдельно от короткого запуска, не переносить разовую цифру на весь материал.

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

Контрольные суммы не совпадают

Установите, что именно сравнивается: сжатый вход, декодированные компоненты, выход после синтеза зерна или файл с заголовками. Зафиксируйте число кадров, параметры зерна и масштабирования, а также эталонный способ получения данных. Несовпадение MD5 двух разных представлений одного видеоряда не доказывает ошибку декодирования.

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

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

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

Разработчикам проигрывателей и систем обработки видео — когда требуется встраиваемый VVC-декодер с C API, выдачей кадров в память и управлением ресурсами. Преимущество раскрывается в составе собственного конвейера, а не при попытке использовать библиотеку как готовое пользовательское приложение.

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

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

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

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

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

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

Три уместные альтернативы

FFmpeg с собственным декодером VVC

FFmpeg рациональнее для полного преобразования: выделить дорожку из контейнера, декодировать, обработать и сохранить другой медиафайл. Его собственный VVC-декодер — отдельная реализация, не libvvdec. Выбор подходит пользователю, которому нужен весь мультимедийный процесс, а не управление одним декодирующим компонентом.

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

VTM и эталонный DecoderApp

VVC Test Model — эталонное программное обеспечение VVC, включающее кодировщик и декодирующее приложение DecoderApp. Оно уместно при изучении стандарта, исследовательских экспериментах и сопоставлении результатов с выбранной эталонной реализацией. VVdeC, напротив, развивает оптимизированную декодирующую реализацию на основе этой программной линии.

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

OpenVVC

OpenVVC — отдельная открытая реализация VVC-декодера на C, создаваемая независимо и распространяемая под LGPL 2.1. Она интересна разработчику, которому нужен другой кодовый фундамент и собственный интерфейс интеграции. Проект предоставляет консольный пример dectest и документирует механизмы параллельной обработки.

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

Вопросы, которые возникают при включении в рабочий процесс

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

Не следует переносить симметрию командной оболочки на приложение. vvdecapp поддерживает специальное выходное имя «-», однако входной –bitstream открывает указанный путь как файл. Значение -b – не является штатным переключателем чтения стандартного ввода в рассматриваемой версии. Для сетевого источника или собственной подачи пакетов нужен подходящий внешний компонент либо использование API.

Можно ли считать каждую единицу NAL отдельным кадром?

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

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

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

Доказывает ли совпадение контрольной суммы, что ролик не редактировали?

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

Итог: выбирать по месту в цепочке обработки

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

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