Поделиться через


Обработка согласования типов данных в кодеках AVStream

При инициализации устройства предоставляемый системой модуль Device Proxy (Devproxy) анализирует дескрипторы фильтра, предоставляемые драйвером. Кроме того, Devproxy предоставляет поддерживаемые драйвером диапазоны данных на входных и выходных контактах соответствующего MFT (Media Foundation Transform).

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

Во время согласования типов данных происходит следующее взаимодействие:

  1. Devproxy извлекает диапазоны данных, предоставляемые мини-накопителем в каждом дескрипторе пин-кода фильтров кодека оборудования.

  2. Devproxy отправляет драйверу запрос на пересечение данных.

  3. Devproxy предоставляет полностью сформированные типы в MF.

  4. Построитель топологий MF (эквивалент построителя графов DirectShow) создает топологию потоковой передачи.

  5. После того как построитель топологий MF завершит работу с типом данных для пин-кода ввода-вывода Devproxy, он задает тип данных в контакте, вызвав функцию обратного вызова AVStrMiniPinSetDataFormat мини-driver. Если маркер KS не существует, Devproxy вызывает KsCreatePin.

Чтобы обеспечить успешное согласование типов данных, мини-диск должен выполнить следующие действия.

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

    const PKSDATARANGE VideoDecoderInputPinDataRanges[8] = {
        (PKSDATARANGE)&H264DataFormat,
        (PKSDATARANGE)&VC_1DataFormat,
        (PKSDATARANGE)&VC_1DataFormatVIH2,
        (PKSDATARANGE)&WMV9DataFormat,
        (PKSDATARANGE)&WMV9DataFormatVIH2,
        (PKSDATARANGE)&DX50DataFormat,
        (PKSDATARANGE)&DX50DataFormatVIH2,
        (PKSDATARANGE)&MPEG2DataFormat
    };
    

    В этом случае указанные диапазоны относятся к типам-оболочкам, таким как KS_DATARANGE_MPEG2_VIDEO, KS_DATARANGE_VIDEO и KS_DATARANGE_VIDEO2. В приведенном выше примере кода каждый диапазон является типизированным в KSDATARANGE.

    Последний элемент структур-оболочек называется структурой блоков формата, например KS_DATARANGE_MPEG2_VIDEO. VideoInfoHeader.

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

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

  2. Драйверы должны разрешать настройку типа носителя на закреплении во время KSSTATE_STOP/KSSTATE_RUN. Здесь не требуется никаких действий, кроме как убедиться, что драйвер не запрещает это.

  3. Драйвер должен предоставить обработчик пересечения в KSPIN_DESCRIPTOR_EX. IntersectHandler для каждого контакта.

  4. Мини-диск должен предоставить обработчик для свойства KSPROPERTY_CONNECTION_PROPOSEDATAFORMAT .

  5. Если задан тип выходного носителя, кодировщик должен сообщать о возможных типах входных данных (с помощью дескриптора пин-кода) на основе указанного типа выходного носителя. Если тип выходного носителя не задан, кодировщики не должны сообщать о входных типах мультимедиа.

  6. Если задан тип входного носителя, декодеры должны сообщать о возможных типах выходных данных на основе указанного типа входного носителя.

  7. Если задан тип входного носителя, видеопроцессоры должны сообщать о своих типах выходных данных на основе указанного типа входного носителя.

  8. Драйвер должен поддерживать интерфейс ICodecAPI . Затем компоненты пользовательского режима могут получать сведения о конфигурации кодека с помощью этого интерфейса пользовательского режима.

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

  10. Свойства ICodecAPI и свойства типа мультимедиа API кодека перекрываются в некоторых областях, например в профиле и уровне. В таких случаях свойства API кодека, связанные с типом мультимедиа, переопределяют свойства ICodecAPI. После установки типа носителя мини-диск не должен разрешать изменение этих перекрывающихся свойств.

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

  12. Ожидаемые входные данные для кодировщика должны быть 4:2:0 и по крайней мере NV12 с чередованием/прогрессивным. Ожидаемые выходные данные — это сжатый элементарный поток в формате MPEG2 PS/TS или H.264 в приложении B.

  13. Ожидаемые входные данные декодера являются элементарным потоком. Ожидаемые выходные данные — это немасштабируемая версия исходного потока в виде несжатого NV12.

  14. Закрепление в драйвере AVStream должно иметь состояния, которые не зависят друг от друга. Это означает, что входной контакт может переходить с KSSTATE_STOP на KSSTATE_RUN , пока выходной контакт остается в состоянии KSSTATE_STOP .

  15. Когда мини-диск получает запросы GET свойства с переменными размерами буфера данных, он должен интерпретировать буфер NULL как запрос на требуемый размер буфера. В этом случае драйвер должен указать требуемую длину в поле Irp-IoStatus.Information> и вернуть STATUS_BUFFER_OVERFLOW. Кроме того, мини-диск должен задать код возврата как предупреждение, а не ошибку. Например, следуйте этим рекомендациям с обработчиками пересечения данных.