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

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

  • Статья

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

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

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

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

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

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

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

  5. После того как конструктор топологии MF завершает определение типа данных для входного/выходного контакта Devproxy, он устанавливает тип данных на контакте, вызывая функцию обратного вызова AVStrMiniPinSetDataFormat минидрайвера. Если пин-код 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 Codec перекрываются в некоторых областях, например, в таких как профиль и уровень. В этих случаях свойства API Codec, связанные с типом мультимедиа, переопределяют свойства 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. Кроме того, минидрайвер должен установить возвращаемый код как предупреждение, а не ошибку. Например, следуйте этим рекомендациям с обработчиками пересечения данных.