Декодеры amd media foundation что это
Реализация MFT кодека
В этом разделе приводятся некоторые рекомендации по реализации декодера или кодировщика в качестве Media Foundation преобразования (MFT).
Кодировщики
Согласование формата кодировщика
Для инициализации кодировщика используется следующая процедура:
После того как тип выходных данных задан на шаге 3, метод жетинпутаваилаблетипе должен возвращать список входных типов, совместимых с текущим типом выходных данных. Иными словами, все типы, возвращаемые функцией жетинпутаваилаблетипе в этой точке, должны быть допустимыми для сетинпуттипе.
Кодировщики и декодеры должны поддерживать NV12 как распространенный несжатый формат. Это гарантирует, что компоненты конвейера могут взаимодействовать с минимальными колорспаце преобразованиями. Конечно же, также поддерживаются и другие форматы.
Декодеров
Transcode-Only декодеры
Некоторые декодеры оптимизированы для перекодирования (декодирования и повторного кодирования потока) и не подходят для использования во время воспроизведения.
Если таблица MFT декодера предназначена только для перекодировки, установите флаг _ перечисления MFT Enum _ _ _ только при регистрации MFT. (См. мфтрегистер.)
| _ Перечисление _ флагов _ _ перечисления MFT мфтрегистер | _ Перечисление _ флагов _ _ перечисления MFT мфтенумекс | Перечислен ли MFT? |
|---|---|---|
| 1 | 1 | Да |
| 1 | 0 | Нет |
| 0 | 1 | Да |
| 0 | 0 | Да |
Атрибуты чересстрочности
Источник мультимедиа может присоединить следующие атрибуты чересстрочности к примерам мультимедиа, которые он доставляет.
| attribute | Описание |
|---|---|
| Мфсампликстенсион _ репеатфирстфиелд | Эквивалентно флагу «повторить первое поле» (РФФ). |
| Мфсампликстенсион _ боттомфиелдфирст | Обратный флаг «первое поле» (ТФФ). |
Эти флаги предоставляют подсказку расширенному обработчику видео (Евр) при выполнении дечередования. Декодер должен распространять эти флаги в нисходящем порядке, копируя их в выходные образцы, чтобы они достигли Евр.
Второй выпуск, включенный в Windows 7, представляет расширенную поддержку медиаформатов и DXVA HD для ускорения HD-контента при использовании драйверов WDDM 1.1.
СОДЕРЖАНИЕ
Архитектура
Практические архитектуры MF
Теоретически существует только одна архитектура Media Foundation, и это модель Media Session, Pipeline, Media Source, Transform и Media Sink. Однако эта архитектура может быть сложной в настройке, и существуют значительные возможности для легких, относительно простых в настройке компонентов MF, предназначенных для обработки медиаданных для простых точечных решений. Таким образом, практические соображения вызвали необходимость реализации вариаций фундаментальной конструкции конвейера, и были разработаны такие компоненты, как Source Reader и Sink Writer, которые работают вне модели конвейера. Некоторые источники разделяют архитектуру Media Foundation на три основных класса.
Архитектура конвейера отличается использованием отдельного объекта Media Session и конвейера. Медиа-данные передаются из одного или нескольких источников мультимедиа в один или несколько приемников мультимедиа и, необязательно, проходят через ноль или несколько преобразований мультимедиа. Медиа-сеанс управляет потоком мультимедийных данных через конвейер, и этот конвейер может иметь несколько разветвлений и ответвлений. Приложение MF может получить доступ к мультимедийным данным при переходе от источника мультимедиа к приемнику мультимедиа, реализовав настраиваемый компонент преобразования мультимедиа и вставив его в соответствующее место в конвейере.
Архитектура Reader-Writer использует компонент, называемый Source Reader, для предоставления мультимедийных данных и компонент Sink Writer для их использования. Source Reader действительно содержит тип внутреннего конвейера, но он недоступен для приложения. Источник чтения не является источником мультимедиа, а устройство записи приемника не является приемником мультимедиа, и ни одно из них не может быть напрямую включено в конвейер или управляться сеансом мультимедиа. Как правило, мультимедийные данные передаются от устройства чтения источника к устройству записи приемника действиями приложения. Приложение либо принимает пакеты мультимедийных данных (называемых образцами мультимедиа) из Source Reader и передает их непосредственно в Sink Writer, либо оно настраивает функцию обратного вызова в Source Reader, которая выполняет ту же операцию. Фактически, поскольку оно управляет транспортировкой данных, само приложение выполняет ту же роль, что и сеанс мультимедиа в приложении с архитектурой конвейера. Поскольку приложение MF управляет передачей образцов мультимедиа между устройством чтения источника и записывающим устройством, оно всегда будет иметь доступ к необработанным мультимедийным данным. Компоненты Source Reader и Sink Writer действительно имеют ограниченные возможности по автоматической загрузке Media Transforms, чтобы помочь с преобразованием формата мультимедийных данных, однако это делается внутренне, и приложение мало контролирует это.
Source Reader и Sink Writer обеспечивают простоту использования, а конвейерная архитектура предлагает чрезвычайно сложный контроль над потоком мультимедийных данных. Однако многие компоненты, доступные для конвейера (например, Enhanced Video Renderer), просто не могут быть легко использованы в архитектурном приложении Reader-Writer. Поскольку структура образца мультимедиа, созданного программой чтения исходного кода, идентична тому, что выводится источником мультимедиа, можно настроить конвейерную архитектуру, в которой образцы мультимедиа перехватываются, когда они проходят через конвейер, а копия передается в Медиа-раковина. Это известно как гибридная архитектура, и она позволяет иметь приложение, которое использует преимущества сложных возможностей обработки сеанса мультимедиа и конвейера, используя при этом простоту использования Sink Writer. Sink Writer не является частью конвейера и не взаимодействует с медиа-сеансом. Фактически, мультимедийные данные обрабатываются специальным приемником мультимедиа, который называется приемником захвата образцов, который потребляет мультимедийные данные и передает копию устройству записи приемника. Также возможно реализовать гибридную архитектуру с настраиваемым преобразованием мультимедиа, которое копирует образцы мультимедиа и передает их устройству записи приемника, когда они проходят через конвейер. В обоих случаях специальный компонент в конвейере эффективно действует как простое приложение Reader-Writer и питает Sink Writer. Как правило, гибридные архитектуры используют конвейер и модуль записи приемника. Теоретически можно реализовать механизм, в котором средство чтения исходного кода могло бы каким-то образом вводить образцы мультимедиа в конвейер, но, в отличие от приемника захвата образцов, такого стандартного компонента не существует.
Преобразование Media Foundation
Улучшенное средство визуализации видео
Поддерживаемые медиа-форматы
Воспроизведение MIDI также пока не поддерживается с помощью Media Foundation.
Поддержка приложения
Приложения, поддерживающие Media Foundation, включают:
Любое приложение, использующее Protected Media Path в Windows, также использует Media Foundation.
Декодер видео H. 265/HEVC
Декодер видео H. 265 предоставляет следующие интерфейсы.
Типы входных данных
Входной тип должен содержать по крайней мере два следующих атрибута:
| attribute | Описание |
|---|---|
| _ _ основной тип MF _ MT | _Видео мфмедиатипе |
| подтип MF _ MT _ | Мфвидеоформат _ HEVC или мфвидеоформат _ HEVC _ ES |
Первый подтип носителя, Мфвидеоформат _ HEVC, указывает, что образцы мультимедиа содержат H. 265 битовый поток с начальными кодами, а поток — с чередованием SPS/PPS. Предполагается наличие одного кадра на выборку.
Подтип носителя Мфвидеоформат HEVC ES означает, что _ _ примеры мультимедиа содержат элементарное значение H. 265 битовый поток, где каждый пример может содержать частичное изображение, несколько изображений, некоторые рисунки и часть изображения.
Входные типы носителей не могут динамически изменяться между двумя типами. Декодер может обнаруживать изменения в выходном формате на основе простейшего синтаксиса потока (пропорции, измерения, флаги развертки, сведения о колориметрие) и запускать соответствующие изменения типа выходных данных.
Для входного типа мультимедиа декодер ожидает, что источник задает правильный профиль. Например, если содержимое будет 10 бит, тип носителя input должен указать профиль как Main10.
Типы вывода
Декодер поддерживает следующие выходные типы выходных данных:
Дополнительные сведения об этих подтипах см. в разделе GUID подтипа видео.
Атрибуты преобразования
| attribute | Описание |
|---|---|
| КОДЕКАПИ _ авловлатенцимоде | Включает или отключает режим декодирования с низкой задержкой. |
| КОДЕКАПИ _ авдекнумворкерсреадс | Задает число рабочих потоков, используемых декодером. |
| КОДЕКАПИ _ авдеквидеосумбнаилженератионмоде | Включает или отключает режим формирования эскизов. |
| _ _ задана длина налу MF _ | Указывает, что сведения о длине налу будут отправляться в виде большого двоичного объекта в каждом сжатом образце H. 265. |
| _ _ сведения о длине MF налу _ | Указывает длину Налус в образце. Это большой двоичный объект MF, заданный в сжатых примерах входных данных для декодера H. 265. |
| _ _ минимальное _ _ число образцов выходных данных SA MF _ | Указывает максимальное число выборок выходных данных. |
Ограничения формата
Декодер поддерживает следующие форматы:
| Требование | Значение |
|---|---|
| Профили и уровни | Main, Главная по-прежнему рисунок и профили Main10 |
| Форматы чрома | 4:2:0 чрома |
| Минимальное разрешение | 48 × 48 пикселей |
| Максимальное разрешение | 4096 × 2304 пикселей Максимальное гарантированное разрешение для ускорения ДКСВА — 1920 × 1088 пикселей; при более высоком разрешении Декодирование выполняется с помощью ДКСВА, если оно поддерживается базовым оборудованием, в противном случае Декодирование выполняется с помощью программного обеспечения. |
| дксва | Декодер поддерживает DX11 и DX12 ДКСВА, но не ДКСВА версии 2 или ДКСВА версии 1. |
Входные данные должны соответствовать приложению B из ITU-T H. 265 | ISO/IEC 23008-2. Данные должны включать начальные коды. Декодер пропускает байты, пока не найдет допустимый набор параметров последовательности (SPS) и набор параметров изображения (PPS) в байтовом потоке.
Декодер AAC
Декодер AAC поддерживает как необработанные AAC потоки без заголовков, так и AAC в потоке передачи звуковых данных (ADTS).
начиная с Windows 8 декодер AAC также поддерживает декодирование потоков потокового транспорта MPEG-4 с уровнем мультиплексирования (латм) и уровнем синхронизации (уровнями гарантии). Он также может преобразовать поток ЛАТМ/УРОВНЯМИ гарантии в ADTS.
Идентификатор класса
Идентификатором класса (CLSID) кодировщика AAC является CLSID _ кмсаакдекмфт, определенный в файле заголовка вмкодекдсп. h.
Типы носителей
Декодер AAC поддерживает следующие типы носителей.
Типы входных данных
Декодер AAC поддерживает следующие подтипы звука:
| Subtype | Описание | Header |
|---|---|---|
| MFAudioFormat_AAC | Необработанный AAC или ADTS AAC. Для этого подтипа мультимедиа тип носителя предоставляет частоту выборки и число каналов перед применением средств Спектрал (SBR) Replication и параметрической стерео (PS), если они есть. Результатом работы средства SBR является двойная декодированная частота выборки по сравнению с частотой выборки ядра AAC-LC. Результатом работы средства PS является декодирование стерео из потока AAC-LC ядра Mono. Этот подтип эквивалентен MEDIASUBTYPE_MPEG_HEAAC, определенному в вмкодекдсп. h. См. раздел идентификаторы GUID для звуковых подтипов. Этот подтип выводится с помощью источника файлов MPEG-4 и средства синтаксического анализа ADTS. | мфапи. h |
| MEDIASUBTYPE_RAW_AAC1 | Необработанный AAC. Этот подтип используется для AAC, содержащихся в AVI-файле, с тегом формата Audio, равным WAVE_FORMAT_RAW_AAC1 (0x00FF). Для этого подтипа тип носителя предоставляет частоту выборки и число каналов после применения инструментов SBR и PS, если они есть. | вмкодекдсп. h |
Чтобы настроить декодер AAC, задайте следующие атрибуты для входного типа носителя.
Типы вывода
Декодер поддерживает следующие типы выходных данных:
