Condividi tramite


Gestione della negoziazione dei tipi di dati nei codec AVStream

Quando un dispositivo viene inizializzato, il modulo Device Proxy (Devproxy) fornito dal sistema analizza i descrittori di filtro forniti dal driver. Devproxy espone inoltre gli intervalli di dati supportati dal driver nei pin di input e output del MFT corrispondente (Media Foundation Transform).

Quando inizia lo streaming, la pipeline MF e le applicazioni in modalità utente usano questi intervalli per eseguire la negoziazione dei tipi di dati con il driver.

Le interazioni seguenti si verificano durante una negoziazione dei tipi di dati:

  1. Devproxy recupera gli intervalli di dati forniti dal minidriver in ogni descrittore pin dei filtri codec hardware.

  2. Devproxy genera una richiesta di intersezione dei dati al driver.

  3. Devproxy espone i tipi completamente formati a MF.

  4. Mf Topology Builder (l'equivalente MF di DirectShow graph builder) costruisce la topologia di streaming.

  5. Dopo che il generatore di topologie MF finalizza un tipo di dati per un pin di input/output Devproxy, imposta il tipo di dati sul pin chiamando la funzione di callback AVStrMiniPinSetDataFormat del minidriver. Se il pin KS non esiste, Devproxy chiama KsCreatePin.

Per abilitare la negoziazione dei tipi di dati riusciti, il minidriver deve seguire questa procedura:

  1. Specificare un elenco degli intervalli di dati supportati nel membro DataRanges di KSPIN_DESCRIPTOR per ogni pin esposto incluso nei filtri codec hardware. Ad esempio:

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

    In questo caso, gli intervalli specificati sono di tipi wrapper, ad esempio KS_DATARANGE_MPEG2_VIDEO, KS_DATARANGE_VIDEO e KS_DATARANGE_VIDEO2. Nell'esempio di codice elencato in precedenza, ogni intervallo è typecast in KSDATARANGE.

    L'ultimo membro delle strutture wrapper è noto come struttura del blocco di formato, ad esempio KS_DATARANGE_MPEG2_VIDEO. VideoInfoHeader.

    Un driver che supporta intervalli di dati continui deve specificare i valori massimi nella struttura del blocco di formato. Un driver che supporta intervalli di dati discreti deve specificare una matrice che contiene i valori discreti nelle strutture del blocco di formato.

    Se un driver che dichiara di supportare un determinato formato in un secondo momento non riesce una richiesta di formato impostata su tale formato, le prestazioni potrebbero essere ridotte. Solo i formati di elenco per i quali si garantisce il supporto.

  2. I driver devono consentire l'impostazione di un tipo di supporto su un pin durante KSSTATE_STOP/KSSTATE_RUN. Non è necessaria alcuna azione qui diversa da per assicurarsi che il driver non consenta questo.

  3. Il driver deve fornire un gestore intersect in KSPIN_DESCRIPTOR_EX. IntersectHandler per ogni pin.

  4. Il minidriver deve fornire un gestore per la proprietà KSPROPERTY_CONNECTION_PROPOSEDATAFORMAT .

  5. Se il tipo di supporto di output è impostato, un codificatore deve segnalare i tipi di input possibili (usando un descrittore pin) in base al tipo di supporto di output specificato. Se un tipo di supporto di output non è impostato, i codificatori non devono segnalare alcun tipo di supporto di input.

  6. Se il tipo di supporto di input è impostato, i decodificatori devono segnalare i possibili tipi di output in base al tipo di supporto di input specificato.

  7. Se il tipo di supporto di input è impostato, i processori video devono segnalare i tipi di output in base al tipo di supporto di input specificato.

  8. Il driver deve supportare l'interfaccia ICodecAPI . I componenti in modalità utente possono quindi ottenere informazioni sulla configurazione del codec usando questa interfaccia in modalità utente.

  9. Durante la configurazione di un codificatore, le proprietà ICodecAPI vengono impostate, seguite dal tipo di supporto di output. A questo scopo, il codificatore deve fornire solo tipi di input che possono supportare con la configurazione corrente.

  10. Le proprietà ICodecAPI e le proprietà del tipo di supporto dell'API Codec si sovrappongono in alcune aree, ad esempio profilo e livello. In questi casi, le proprietà dell'API codec correlate al tipo di supporto eseguono l'override delle proprietà ICodecAPI. Dopo aver impostato il tipo di supporto, il minidriver non deve consentire la modifica di queste proprietà sovrapposte.

  11. Durante la configurazione di un decodificatore, il tipo di input viene impostato prima. A questo scopo, il decodificatore deve fornire solo tipi di output che possono supportare con il tipo di input corrente.

  12. L'input previsto per un codificatore deve essere 4:2:0 e almeno NV12 interlaccia/progressivo. L'output previsto è un flusso elementare compresso in formato MPEG2 PS/TS o H.264 Allegato B.

  13. L'input previsto per un decodificatore è un flusso elementare. L'output previsto è la versione non ridimensionata del flusso di origine come NV12 non compresso.

  14. I pin su un driver AVStream devono avere stati indipendenti tra loro. Ciò significa che un pin di input può passare dal KSSTATE_STOP fino al KSSTATE_RUN mentre il pin di output rimane allo stato KSSTATE_STOP .

  15. Quando il minidriver riceve le richieste GET di proprietà con dimensioni del buffer di dati variabili, il minidriver deve interpretare un buffer NULL come query per le dimensioni del buffer richiesto. In questo caso, il driver deve specificare la lunghezza necessaria nel campo Irp-IoStatus.Information> e restituire STATUS_BUFFER_OVERFLOW. Inoltre, il minidriver deve impostare il codice restituito come avviso e non un errore. Ad esempio, seguire questa guida con i gestori di intersezione dei dati.