Аппаратное видео в ПК: декодеры, энкодеры, форматы пикселей и путь кадра
Аппаратные и программные стадии решают разные задачи. Наличие ускоренного декодера не отменяет обработку поверхностей и стоимость вывода. Открыть иллюстрацию в полном размере.
Видеокарта почти не загружает вычислительные блоки, но воспроизводит тяжёлый ролик. При записи игры специальный энкодер работает, однако частота кадров всё равно уменьшается. Другой файл с тем же названием кодека внезапно декодируется на CPU. Это не противоречия: видеотракт состоит из нескольких независимых по назначению стадий. Сжатый поток нужно разобрать, восстановить поверхности кадров, выполнить обработку, затем показать изображение или снова закодировать. Аппаратный блок ускоряет свою часть, но не делает бесплатными память, копирование, синхронизацию и остальные операции.
Содержание статьи
- Четыре действия, которые часто называют одним ускорением
- Контейнер, кодек и формат пикселей — три разных описания
- Сжатый поток нужно подготовить к декодированию
- Восстановленный кадр не обязан быть RGB
- NV12 и P010: смысл отсчёта и размер хранения
- Сколько памяти требует активное изображение
- Поверхностей несколько: ссылки, выходы и промежуточные результаты
- Порядок кодирования и порядок показа могут различаться
- Энкодер выбирает компромисс, а не просто уменьшает файл
- Как проверять реальную аппаратную поддержку
- Копирование и преобразования способны съесть выигрыш
- Пропускная способность и задержка медиаконвейера
- Практический способ оценить весь путь
- Первичные источники
- Читайте также
Четыре действия, которые часто называют одним ускорением
Декодер преобразует сжатое представление в восстановленные изображения. Энкодер принимает изображения и формирует новый сжатый поток по выбранным правилам. Обработка включает масштабирование, изменение цветового представления, композицию и фильтры. Вывод связывает готовую поверхность с расписанием показа и интерфейсом дисплея. Эти действия могут выполняться разными блоками и программными компонентами, даже когда все относятся к одному GPU.
Аппаратные медиаблоки не равны массиву обычных шейдерных исполнителей. NVIDIA отдельно описывает NVDEC и NVENC, Intel предоставляет аппаратные возможности через свои медиасредства и API, другие производители используют собственные реализации. Названия конкретной фирмы нельзя считать универсальными именами любого декодера. Число вычислительных «ядер» GPU не является прямым числом видеодекодеров и не задаёт число потоков определённого кодека.
Независимость блоков по исполнению не означает полной независимости системы. Они делят память, внутренние соединения, доступную мощность и некоторые программные ресурсы. Фильтр может выполняться шейдерами, а специальный этап кодирования — требовать дополнительной обработки. Поэтому перенос кодирования в аппаратный блок способен освободить CPU, но не гарантирует нулевого влияния на игру, монтаж или другое параллельное приложение.
Контейнер, кодек и формат пикселей — три разных описания
Контейнер организует дорожки, временные отметки, метаданные и размещение потоков. Название файла MP4 или MKV само по себе не говорит, каким алгоритмом сжато видео. Кодек задаёт правила представления и восстановления изображения; профиль и уровень уточняют допустимые инструменты и ограничения. Формат пикселей описывает уже восстановленные или подготовленные изображения: компоненты, субдискретизацию, разрядность и размещение в памяти.
Один контейнер способен содержать видео разных кодеков, а один кодек — несколько профилей, разрядностей и вариантов цветовых компонентов. Поэтому фраза «GPU поддерживает HEVC» без уточнений неполна. Необходимо проверить, идёт ли речь о декодировании или кодировании, нужной глубине, 4:2:0 либо другом представлении, разрешении и применяемом API. Наименование семейства алгоритма не гарантирует все его варианты.
Битрейт bitstream относится к сжатому потоку. Он не равен потоку восстановленных кадров по памяти. Учебные 20 Мбит/с дают 2,5 МБ/с до добавления других дорожек и служебного оформления. За час это 9 ГБ в десятичных единицах. Замена мегабит на мегабайты без деления на восемь завышает расчёт в восемь раз; замена МБ на МиБ без уточнения создаёт другую ошибку масштаба.
Сжатый поток нужно подготовить к декодированию
Чтение файла или приём сети сначала доставляет контейнер и его данные. Демультиплексор выделяет нужную дорожку, а парсер разбирает элементы сжатого представления и передаёт параметры декодеру. Часть этой работы может оставаться на CPU, даже если основное восстановление изображения выполняется аппаратно. Уменьшившаяся загрузка процессора не обязана стать нулевой: обслуживание ввода, аудио, временных отметок и интерфейса программы продолжает работать.
Декодер должен знать подходящие параметры потока и иметь достаточно поверхностей. При изменении разрешения или других существенных характеристик может потребоваться перенастройка. Поддержка формата на уровне устройства не гарантирует, что конкретное приложение корректно использует соответствующий путь. Поэтому отсутствие ускорения иногда связано с программной цепочкой или несовместимым вариантом потока, а не с тем, что видеокарта «слишком слабая» по арифметической производительности.
Восстановленный кадр не обязан быть RGB
Во многих медиатрактах используются яркостная компонента Y′ и цветоразностные Cb/Cr, которые в описаниях форматов часто обозначают U/V. Y′ не следует отождествлять с физической яркостью в кд/м²: это кодовая компонента определённого представления изображения. Для восстановления цвета важны матрица преобразования, диапазон кодов, функция передачи и первичные цвета. Одинаковые байты без правильных параметров могут дать разные видимые цвета.
В 4:4:4 цветовые компоненты имеют полную пространственную сетку. В 4:2:2 их горизонтальная частота выборки уменьшена относительно яркостной, а в распространённом 4:2:0 уменьшена и вертикальная. Для чётных размеров в 4:2:0 на каждый яркостный отсчёт в среднем приходится половина цветовых отсчётов: общее число отсчётов равно 1,5 на пиксель. Это счёт компонентов, а не число байтов, пока не определены глубина и способ хранения.
Субдискретизация способна быть достаточно удобной для естественного видео, но меняет тонкие цветовые границы и текст. Она не равна уменьшению разрешения всей яркостной сетки. При записи экрана с мелкими цветными надписями этот компромисс заметнее, чем в некоторых природных сценах. Возвращение к RGB не восстанавливает автоматически отсутствующие цветовые отсчёты: программа интерполирует их по выбранному правилу.
Диапазон кодов и цветовые параметры должны совпасть
Восьмибитная яркостная компонента может интерпретироваться в полном или ограниченном диапазоне; в распространённом ограниченном представлении номинальные уровни чёрного и белого находятся на 16 и 235. Если тракт ошибочно растянет полный диапазон как ограниченный, часть уровней будет отсечена; обратная ошибка изменит чёрный и контраст. Это проблема интерпретации значений, а не обязательно нехватка производительности декодера. Цветовые компоненты имеют собственные правила и не должны автоматически обрабатываться как три одинаковых RGB-канала.
Десятибитный поток также не является синонимом HDR. Больше кодовых уровней полезно в разных задачах, а HDR-представление требует соответствующих параметров цвета и функции передачи. При преобразовании HDR в SDR применяется согласование диапазонов и цветовых возможностей, а не просто отбрасывание двух битов. Декодер способен правильно восстановить исходные кодовые значения, после чего неподходящая обработка даст неверное изображение. Поэтому для оценки цвета нужно проследить не только аппаратное декодирование, но и преобразование вплоть до вывода.
NV12 и P010: смысл отсчёта и размер хранения
NV12 хранит восьмибитную плоскость Y и следующую за ней плоскость чередующихся U/V для 4:2:0. Для идеальной плотной активной области это 1,5 байта на пиксель: один байт яркостной компоненты и в среднем половина байта цветовых компонентов. Размещение называется двухплоскостным или полупланарным, в зависимости от терминологии описания. Важно фактическое устройство памяти, а не только короткое имя.
P010 также использует 4:2:0, но десятибитные значения хранятся в шестнадцатибитных словах. В описанном Microsoft представлении значащие десять бит занимают старшие позиции, младшие шесть равны нулю. Поэтому активная область P010 требует 3 байта на пиксель, а не 1,875 байта, которые получились бы при идеальной плотной упаковке пятнадцати значащих битов на пиксель. Глубина десять бит не означает десятибитный размер каждого элемента памяти.
Другие форматы способны упаковывать компоненты иначе. Нельзя переносить правило P010 на любое десятибитное видео или любой API без проверки. Также имя формата поверхности не задаёт само по себе цветовую матрицу и HDR-параметры. Два P010-буфера могут иметь одинаковую структуру памяти и разное смысловое описание цвета. Совместимость формата хранения является необходимой частью тракта, но не исчерпывает правильность изображения.
Сколько памяти требует активное изображение
Для 3840 × 2160 получаем 8 294 400 пикселей. Плотная активная область NV12 занимает 12 441 600 байт, около 11,87 МиБ. P010 — 24 883 200 байт, около 23,73 МиБ. Четырёхбайтный RGBX-формат потребует 33 177 600 байт, около 31,64 МиБ. Это арифметика заданных форматов, а не фактически выделенный драйвером объём любой поверхности.
Реальный stride, или шаг строки, может превышать число активных байтов. Добавляются выравнивание высоты, тайловая организация и служебные области. Программа должна использовать параметры поверхности, а не вычислять адрес каждой строки только как ширину картинки. Рамка кадрирования может обозначать видимую часть большего буфера. Ошибка этих границ иногда проявляется как смещение изображения, неверный цвет или повреждённая нижняя часть, хотя декодирование потока выполнено правильно.
При 60 кадрах/с один проход по плотной активной области P010 соответствует 1 492 992 000 байт/с, примерно 1,493 ГБ/с. Это почти в 597 раз больше условных 2,5 МБ/с сжатого потока из предыдущего примера. Сравнение не является коэффициентом сжатия конкретного ролика: значения заданы независимо для объяснения масштабов. Оно показывает, почему нетрудный для накопителя bitstream может создавать значительную работу внутри медиатракта.
Поверхностей несколько: ссылки, выходы и промежуточные результаты
Декодеру могут требоваться ранее восстановленные изображения для предсказания следующих. Готовый к показу кадр способен оставаться опорным и поэтому не может быть сразу перезаписан. Дополнительно существуют выходные и промежуточные поверхности обработки. Количество буферов связано с кодеком, потоком, алгоритмом и асинхронной организацией. Один видимый кадр не означает один выделенный буфер, а недостаточный пул способен остановить подачу новой работы.
В учебном примере двенадцать плотных P010-поверхностей 4K занимают 12 × 24 883 200 = 298 598 400 байт, около 284,77 МиБ. Выравнивание и прочие ресурсы сюда не включены. Это не обязательное число буферов какого-либо декодера. Расчёт нужен для масштаба: несколько параллельных потоков, фильтры и энкодер используют суммарную память, хотя каждый отдельный файл имеет небольшой сжатый размер.
Владение поверхностью и асинхронная работа
Аппаратный вызов может поставить работу в очередь и вернуть управление раньше готовности кадра. Программа должна дождаться предусмотренного события или точки синхронизации, прежде чем читать результат или переиспользовать память. Аналогично переданная энкодеру поверхность может ещё использоваться внутри него. Если заменить её содержимое слишком рано, возникают ошибки, которые не объясняются кодеком или скоростью памяти. Правильное владение ресурсом является частью медиатракта, даже когда копирование между этапами исключено.
Достаточный пул позволяет поддерживать перекрытие соседних кадров, но слишком большой запас способен скрывать задержку за очередью. Поэтому увеличение числа буферов не является безусловной оптимизацией. Для экспорта файла важнее непрерывно занимать аппаратные стадии, для живого взаимодействия — не накапливать лишний материал впереди пользователя. Одна и та же конфигурация может показывать высокий средний поток и неудобную задержку. Оценивать эти результаты нужно раздельно, сохраняя смысл каждого числа и выбранную политику переполнения.
Порядок кодирования и порядок показа могут различаться
Межкадровое предсказание использует связи между изображениями. В одном упрощённом примере показываются I0, B1, B2, P3, а для восстановления B1 и B2 нужно уже иметь I0 и P3. Тогда порядок предоставления сжатых изображений декодеру может выглядеть как I0, P3, B1, B2. Это допустимая учебная структура, а не универсальное описание всех B-кадров и всех настроек кодека.
Временные отметки помогают разделять момент декодирования и момент представления. Программа должна выдать кадр по нужному расписанию, даже если восстановлен он раньше или позже соседнего по порядку потока. Кадр, закодированный только внутри себя, также нельзя автоматически объявлять любой возможной точкой чистого случайного доступа: сброс ссылок и свойства точки входа зависят от структуры и правил кодека.
Для живого источника ожидание будущих изображений добавляет задержку. Если условный алгоритм требует ещё два интервала при 60 кадрах/с, это около 33,3 мс до учёта исполнения и передачи. Для записи файла такая организация может быть приемлемой ради эффективности, а для взаимодействия с удалённым рабочим столом требования иные. «Больше FPS кодирования» и «меньше времени от события до видимого результата» остаются разными целями.
Перемотка является другой нагрузкой
При обычном воспроизведении опорные изображения уже подготовлены в нужном порядке. При переходе к произвольному моменту может потребоваться найти подходящую точку входа и восстановить промежуточные изображения, прежде чем показать выбранный кадр. Поэтому быстрое линейное декодирование не гарантирует столь же мгновенного точного поиска по таймлайну. Частота пригодных точек входа, индексы контейнера, состояние буферов и политика приложения участвуют в результате вместе с медиаблоком.
В монтажной программе несколько источников могут одновременно требовать поиска, восстановления и обработки. Пауза на переходе между фрагментами не обязана означать постоянное ограничение обычного просмотра. Для сравнения полезно разделить последовательный экспорт, перемотку и интерактивный таймлайн: они предъявляют разные требования. Короткий тест одного файла также не описывает многокамерный проект. Нельзя просто умножить измеренный поток одного декодера на число дорожек, не учитывая общую память, пулы поверхностей и работу над итоговой композицией.
Энкодер выбирает компромисс, а не просто уменьшает файл
Кодирование включает выбор способов предсказания, представления остатка, квантования и распределения битов. Аппаратная реализация ускоряет поддерживаемые операции, но параметры управления меняют качество, темп и задержку. Название одного кодека не делает два энкодера или два пресета равными. При одинаковом битрейте может различаться сохранение мелких деталей, поведение в движении и вид сложных переходов.
Предварительный анализ будущих кадров, lookahead, помогает распределять ресурсы, но требует ожидания или накопления входа. Учебные 24 кадра при 60 кадрах/с соответствуют 0,4 с материала. Это не гарантированная добавка любой настройки: конкретный конвейер может перекрывать часть действий. Однако содержательный смысл буферизации сохраняется. Профиль с качественным анализом для готового файла нельзя без оговорок сравнивать с низкозадержечным режимом трансляции.
Управление средним или ограниченным битрейтом также не означает одинакового размера каждого кадра. Сложность изображения меняется, а алгоритм распределяет бюджет во времени. Нужны ограничения буфера и пиков, если канал не допускает произвольных всплесков. Простое отношение размера файла к длительности даёт средний поток, но не раскрывает, насколько трудными были короткие участки для сети, буфера или декодера.
Как проверять реальную аппаратную поддержку
Список возможностей API описывает доступные функции интерфейса, но конкретное устройство реализует их подмножество. В руководстве NVDEC предусмотрен запрос возможностей с указанием кодека, цветовой субдискретизации и глубины; результат также описывает допустимые размеры и выходные форматы. У энкодера NVENC существуют свои запросы возможностей. Это разные проверки: поддержка декодирования AV1 не доказывает поддержку его аппаратного кодирования на том же GPU.
Нужно учитывать поколение, вариант кристалла, драйвер, ОС и приложение. Даже внутри одного семейства названий возможны разные медиаблоки. Конкретная программа может не иметь нужного интерфейса или выбирать программный путь для сочетания параметров. Поэтому без анализа bitstream и возможностей пути нельзя обещать аппаратную обработку любого десятибитного файла или любого AV1-видео. Формат, профиль, глубина и субдискретизация проверяются вместе.
Включённый переключатель ускорения ещё не доказывает, что все стадии прошли аппаратно. Полезны журнал приложения, сведения о выбранном декодере, фактическом формате поверхностей и активных движках. Общая загрузка GPU иногда слабо отражает работу отдельного медиаблока. Нагрузка CPU тоже неоднозначна: он может обслуживать неподдержанный фильтр, аудио или контейнер, пока само декодирование уже ускорено. Вывод делают по нескольким согласованным признакам.
Поля чересстрочного видео и готовые кадры
Некоторые источники содержат чересстрочное изображение, где поля относятся к разным строкам и моментам времени. Обозначение частоты полей нельзя автоматически читать как такое же число полноценных прогрессивных кадров. Преобразование в прогрессивный вывод может включать анализ движения и дополнительную буферизацию. Ускоренный декодер и ускоренный деинтерлейсинг — разные возможности, даже если приложение объединяет их одним пользовательским переключателем. Ошибка порядка полей или временных отметок способна нарушать движение при достаточной вычислительной скорости.
При оценке старого видеоматериала поэтому фиксируют не только разрешение и кодек, но и структуру развёртки, порядок полей и требуемый выход. Условная задача превратить 25 чересстрочных кадров с 50 временными полями в 50 прогрессивных изображений не равна простому повторению каждого кадра дважды. Алгоритм должен согласовать пространственные и временные данные. Его качество и цена могут определять впечатление сильнее, чем скорость собственно восстановления сжатого bitstream.
Копирование и преобразования способны съесть выигрыш
Если кадр остаётся в подходящей GPU-памяти и следующий этап умеет использовать ту же поверхность, некоторые промежуточные передачи можно исключить. Именно такие средства обмена поддерживают медиасреды вроде oneVPL и специализированные API. Но совместимость должна охватывать устройство, формат, владение ресурсом и синхронизацию. Фраза zero-copy относится к исключённым копиям, а не к тому, что декодер перестал записывать результат и энкодер перестал его читать.
Один CPU-фильтр способен потребовать выгрузить восстановленное изображение в системную RAM, обработать его и загрузить обратно. Для P010 4K60 активные байты одного направления составляют около 1,493 ГБ/с; обратный путь создаёт сопоставимый поток в другом направлении. Это не полный трафик интерфейса и не утверждение об одном общем лимите для дуплексного соединения. Дополнительно работают копирование, синхронизация и, возможно, преобразование формата.
Даже копия внутри видеопамяти требует чтения источника и записи назначения. В идеализированном подсчёте одна полная копия плотного P010 4K60 создаёт около 2,986 ГБ/с обращений к активным данным, если учитывать оба действия. Кэширование и организация памяти меняют физические транзакции. Поэтому этот расчёт служит нижней моделью работы с буферами, а не готовой оценкой нагрузки контроллера памяти или точной потребности канала.
Пропускная способность и задержка медиаконвейера
Пусть учебные стадии занимают 4 мс на декодирование, 3 мс на обработку и 5 мс на кодирование, работают независимо и способны перекрывать соседние кадры. Один кадр проходит последовательную цепочку за 12 мс без других ожиданий, а установившийся темп ограничен самой медленной стадией. Делить секунду на сумму как единственный предел потока было бы ошибкой. Но наличие очередей добавляет время конкретному кадру даже при достаточной общей производительности.
Другой учебный режим получает 60 кадров/с, а узкое место способно обслужить только 50. В неограниченной очереди запас растёт на десять кадров каждую секунду. Через две секунды накопятся двадцать кадров ожидания, что при обслуживании 50 кадров/с соответствует примерно 0,4 с дополнительного времени для конца очереди. Реальная система имеет конечные буферы и будет тормозить источник, пропускать кадры или менять режим; бесконечный рост является моделью, а не обещанием поведения программы.
Поэтому запись или трансляция может сначала выглядеть нормальной, а затем накапливать задержку. Проверять следует несколько секунд или минут подходящей устойчивой работы, а не только стартовый всплеск скорости. Высокая частота обработки короткого готового файла и способность обслуживать живой источник с заданной задержкой — разные измерения. Для последней особенно важны буферизация, временные отметки и политика при перегрузке.
Число пикселей помогает оценить масштаб, но не всё исполнение
Активный поток 3840 × 2160 при 60 кадрах/с содержит в восемь раз больше пикселей за секунду, чем 1920 × 1080 при 30 кадрах/с. Это полезный ориентир для прохода по поверхностям одинакового формата. Но время декодирования не обязано увеличиваться ровно в восемь раз: влияют структура сжатия, поддерживаемые инструменты, аппаратный параллелизм и другие ограничения. Коэффициент пикселей следует использовать как проверку масштаба данных, сохраняя границу между арифметикой и прогнозом конкретного устройства.
Также одинаковое разрешение не означает одинаковой сложности изображения. Разные кадры требуют разного анализа при кодировании, а ограничения протокола и аппаратуры могут задаваться не только частотой пикселей. Поэтому обещание «несколько потоков 4K» без частоты, кодека и параметров неполно. Сначала уточняют профиль задачи, затем проверяют реальные возможности пути и устойчивое выполнение. Название крупного разрешения удобно для краткого описания, но не заменяет техническую спецификацию нагрузки.
Практический способ оценить весь путь
Сначала описывают вход: контейнер, кодек, профиль, разрядность, субдискретизацию, разрешение, частоту и цветовые параметры. Затем фиксируют требуемый выход: показ, файл или сеть, допустимую задержку и критерий качества. Следом выясняют, какие стадии действительно выполняются аппаратно, где находятся поверхности и не появляется ли переход через RAM. Это даёт проверяемую модель вместо попытки оценивать видеотракт одной общей загрузкой GPU.
При сравнении кодирования сохраняют не только кодек, но и пресет, управление битрейтом, структуру ссылок, lookahead и формат. Отдельно сравнивают качество и время: одинаковый размер файла не доказывает одинаковое изображение. Для воспроизведения важны пропуски кадров и соблюдение расписания, для экспорта — время законченной задачи, для трансляции — устойчивость и задержка. Каждый вывод остаётся привязан к своему сценарию и не становится универсальным рейтингом оборудования.
При поиске ограничения меняют один участок: временно убирают фильтр, сохраняют исходный формат поверхности или сравнивают вывод без дополнительного преобразования. Проверяют, изменились ли время завершения, пропуски и загрузка нужного движка. Если ускорение появилось после удаления фильтра, это поддерживает связь с обработкой или переходом памяти, но ещё не устанавливает единственную причину. Подтверждение получают из согласованного журнала и повторяемого сценария, сохраняя исходные файлы и качество сравнения.
Первичные источники
Все численные поверхности, скорости и очереди статьи являются учебными. Возможности конкретного GPU следует проверять по его реализации и действующему программному пути.
- NVIDIA — NVDEC Video Decoder API Programming Guide 13.1.
- NVIDIA — NVENC Video Encoder API Programming Guide 13.0.
- Microsoft — Recommended 8-Bit YUV Formats for Video Rendering.
- Microsoft — 10-bit and 16-bit YUV Video Formats: P010 и организация поверхности.
- Intel — oneAPI Video Processing Library: архитектура медиатракта и обмен буферами.
- FFmpeg — Filters Documentation: аппаратные поверхности, выгрузка и загрузка.
Комментарии