Compartilhar via


Manipulando a negociação de tipo de dados em codecs AVStream

Quando um dispositivo é inicializado, o módulo Proxy de Dispositivo (Devproxy) fornecido pelo sistema analisa os descritores de filtro fornecidos pelo driver. Além disso, o Devproxy expõe os intervalos de dados com suporte para driver nos pinos de entrada e saída do MFT correspondente (Media Foundation Transform).

Quando o streaming começa, o pipeline MF e os aplicativos do modo de usuário usam esses intervalos para executar a negociação de tipo de dados com o driver.

As seguintes interações ocorrem durante uma negociação de tipo de dados:

  1. O Devproxy recupera os intervalos de dados fornecidos pelo minidriver em cada descritor de pino dos filtros de codec de hardware.

  2. A devproxy emite uma solicitação de interseção de dados para o driver.

  3. O Devproxy expõe tipos totalmente formados ao MF.

  4. O Construtor de Topologia do MF (equivalente a MF do construtor de grafos DirectShow) constrói a topologia de streaming.

  5. Depois que o construtor de Topologia do MF finaliza um tipo de dados para um pin de entrada/saída de Devproxy, ele define o tipo de dados no pino chamando a função de retorno de chamada AVStrMiniPinSetDataFormat do minidriver. Se o pino KS não existir, Devproxy chamará KsCreatePin.

Para habilitar a negociação bem-sucedida de tipo de dados, o minidriver deve seguir estas etapas:

  1. Forneça uma lista de intervalos de dados com suporte no membro DataRanges de KSPIN_DESCRIPTOR para cada pin exposto incluído nos filtros de codec de hardware. Por exemplo:

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

    Nesse caso, os intervalos especificados são de tipos de wrapper, como KS_DATARANGE_MPEG2_VIDEO, KS_DATARANGE_VIDEO e KS_DATARANGE_VIDEO2. No exemplo de código listado anteriormente, cada intervalo é digitado como KSDATARANGE.

    O último membro das estruturas de wrapper é conhecido como a estrutura de bloco de formato, por exemplo, KS_DATARANGE_MPEG2_VIDEO. VideoInfoHeader.

    Um driver que dá suporte a intervalos de dados contínuos deve especificar os valores máximos na estrutura de blocos de formato. Um driver que dá suporte a intervalos de dados discretos deve especificar uma matriz que contenha os valores discretos nas estruturas de bloco de formato.

    Se um driver que afirma dar suporte a um determinado formato mais tarde falhar em uma solicitação de formato definido para esse formato, o desempenho poderá ser reduzido. Somente formatos de lista para os quais você garante suporte.

  2. Os drivers devem permitir que um tipo de mídia seja definido em um pino enquanto estiver em KSSTATE_STOP/KSSTATE_RUN. Nenhuma ação é necessária aqui além de garantir que o driver não permite isso.

  3. O driver deve fornecer um manipulador intersect no KSPIN_DESCRIPTOR_EX. IntersectHandler para cada pino.

  4. O minidriver deve fornecer um manipulador para a propriedade KSPROPERTY_CONNECTION_PROPOSEDATAFORMAT .

  5. Se o tipo de mídia de saída estiver definido, um codificador deverá relatar possíveis tipos de entrada (usando um descritor de pino) com base no tipo de mídia de saída especificado. Se um tipo de mídia de saída não estiver definido, os codificadores não deverão relatar nenhum tipo de mídia de entrada.

  6. Se o tipo de mídia de entrada estiver definido, os decodificadores deverão relatar possíveis tipos de saída com base no tipo de mídia de entrada especificado.

  7. Se o tipo de mídia de entrada estiver definido, os Processadores de Vídeo deverão relatar seus tipos de saída com base no tipo de mídia de entrada especificado.

  8. O driver deve dar suporte à interface ICodecAPI . Os componentes do modo de usuário podem obter informações de configuração de codec usando essa interface do modo de usuário.

  9. Durante a instalação de um codificador, primeiro as propriedades ICodecAPI são definidas, seguidas pelo tipo de mídia de saída. Depois disso, o codificador só deve fornecer tipos de entrada que ele possa dar suporte à configuração atual.

  10. As propriedades ICodecAPI e as propriedades de tipo de mídia da API codec se sobrepõem em algumas áreas, por exemplo, perfil e nível. Nesses casos, as propriedades da API codec relacionadas ao tipo de mídia substituem as propriedades ICodecAPI. Depois que o tipo de mídia é definido, o minidriver não deve permitir a modificação dessas propriedades sobrepostas.

  11. Durante a instalação de um decodificador, o tipo de entrada é definido primeiro. A seguir, o decodificador deve fornecer apenas tipos de saída que ele possa dar suporte com seu tipo de entrada atual.

  12. A entrada esperada para um codificador deve ser 4:2:0 e pelo menos NV12 entrelace/progressivo. A saída esperada é um fluxo elementar compactado no formato MPEG2 PS/TS ou H.264 Anexo B.

  13. A entrada esperada para um decodificador é um fluxo elementar. A saída esperada é a versão não dimensionada do fluxo de origem como NV12 não compactado.

  14. Os pinos em um driver AVStream devem ter estados independentes uns dos outros. Isso significa que um pino de entrada pode fazer a transição do KSSTATE_STOP para o KSSTATE_RUN enquanto o pino de saída permanece no estado KSSTATE_STOP .

  15. Quando o minidriver recebe solicitações GET de propriedade com tamanhos de buffer de dados variáveis, o minidriver deve interpretar um buffer NULL como uma consulta para o tamanho do buffer necessário. Nesse caso, o driver deve especificar o comprimento necessário no campo Irp-IoStatus.Information> e retornar STATUS_BUFFER_OVERFLOW. Além disso, o minidriver deve definir o código de retorno como um aviso e não um erro. Por exemplo, siga estas diretrizes com manipuladores de interseção de dados.