Condividi tramite

Gestione delle modifiche del flusso

  • Articolo

Questo argomento descrive come una trasformazione di Media Foundation (MFT) deve gestire le modifiche del formato durante lo streaming.

Importante

Questo argomento non si applica ai codificatori. I codificatori non devono propagare le modifiche al formato, come descritto in questo argomento. I codificatori devono accettare solo un tipo di input corrispondente al tipo di output attualmente configurato.

 

Panoramica delle modifiche al formato

In genere, esistono due motivi per cui un formato può cambiare durante lo streaming.

  • Il client potrebbe passare a un flusso con un nuovo formato. Ad esempio, in televisione digitale, ciò può verificarsi a causa di una modifica del canale.
  • In alcuni formati video, ad esempio H.264, il bitstream può segnalare una modifica del formato. Tali modifiche possono includere modifiche alla dominanza dei campi, alla risoluzione video o alle proporzioni dei pixel.

Se il tipo di codifica cambia, il client potrebbe dover rimuovere MFT dalla pipeline e sostituirlo con un altro MFT. Ad esempio, il client potrebbe dover eseguire lo scambio in un nuovo decodificatore. In questo argomento non viene illustrata questa situazione. In questo argomento viene illustrato solo il caso in cui il MFT corrente può gestire il nuovo formato.

Se il formato cambia, MFT potrebbe richiedere un nuovo tipo di input, un nuovo tipo di output o entrambi.

  • Le modifiche apportate al tipo di input vengono avviate dal client. Un MFT non modifica mai il proprio tipo di input.
  • Le modifiche apportate al tipo di output vengono avviate da MFT. MFT segnala che richiede un nuovo tipo di output e il client negozia il nuovo tipo di output con MFT.

Di conseguenza, sono possibili tre casi distinti:

  • Il client imposta un nuovo tipo di input. MFT utilizza il nuovo formato, senza alcuna modifica al tipo di output.
  • Il client imposta un nuovo tipo di input e attiva una modifica nel tipo di output.
  • Il tipo di input non cambia, ma MFT rileva una modifica del formato nel bitstream, che richiede un nuovo tipo di output.

Implementazione delle modifiche di formato

Nella parte restante di questo argomento viene descritto come il client deve elaborare una modifica del formato e come implementare le modifiche al formato in un MFT.

Tipo di output

Qualsiasi MFT può avviare una modifica al tipo di output, come indicato di seguito:

  1. Il client chiama IMFTransform::P rocessOutput. Il MFT risponde come segue:
    1. MFT non produce un esempio di output in ProcessOutput.
    2. MFT imposta il flag MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE nel membro dwStatus della struttura MFT_OUTPUT_DATA_BUFFER .
    3. Il metodo ProcessOutput restituisce il codice di errore MF_E_TRANSFORM_STREAM_CHANGE.
  2. Il client chiama IMFTransform::GetOutputAvailableType. Questo metodo restituisce un set aggiornato di tipi di output.
  3. Il client chiama SetOutputType per impostare un nuovo tipo di output.
  4. Il client riprende a chiamare ProcessInput/ProcessOutput.

Tipo di input

Le modifiche apportate al tipo di input vengono avviate dal client, mai da MFT. Se il tipo di input cambia, potrebbe attivare una modifica al tipo di output.

La sequenza esatta di eventi dipende dal valore dell'attributo MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE .

Valore Descrizione
FALSE Prima che il client imposti un nuovo tipo di input, deve svuotare MFT.
TRUE Il client può impostare un nuovo tipo di input senza svuotare MFT.

 

Un MFT espone questo attributo tramite il metodo IMFTransform::GetAttributes . Il valore predefinito di questo attributo è FALSE; se MFT non imposta l'attributo, considerare il valore come FALSE.

MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE è FALSE

  1. Il client invia il messaggio di MFT_MESSAGE_COMMAND_DRAIN .
  2. Il client svuota il MFT chiamando IMFTransform::P rocessOutput fino a quando ProcessOutput non restituisce MF_E_TRANSFORM_NEED_MORE_INPUT.
  3. Il client chiama IMFTransform::SetInputType per impostare il nuovo tipo di input.
  4. MFT convalida il tipo di input. Se il tipo non è valido, SetInputType restituisce MF_E_INVALIDMEDIATYPE o un altro codice di errore. In caso contrario, SetInputType restituisce S_OK.
  5. Supponendo che il tipo di input sia valido, MFT valuta se il tipo di output cambia anche. In caso contrario, lo streaming continua e non sono necessarie altre azioni.
  6. Se il tipo di output cambia:
    1. MFT invalida il tipo di supporto di output corrente e aggiorna l'elenco dei tipi di supporti di output disponibili.
    2. La chiamata successiva a ProcessOutput restituisce MF_E_TRANSFORM_STREAM_CHANGE, come descritto nella sezione precedente.
    3. Il client chiama IMFTransform::GetOutputAvailableType per ottenere l'elenco aggiornato dei tipi di output.
    4. Il client chiama SetOutputType.

MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE è TRUE

  1. Il client chiama IMFTransform::SetInputType per impostare il nuovo tipo di input.
  2. MFT convalida il tipo di input. Se il tipo non è valido, SetInputType restituisce MF_E_INVALIDMEDIATYPE o un altro codice di errore. In caso contrario, SetInputType restituisce S_OK.
  3. Supponendo che il tipo di input sia valido, MFT valuta se il tipo di output cambia anche. In caso contrario, lo streaming continua e non sono necessarie altre azioni.
  4. Prima che il tipo di output venga modificato, MFT deve elaborare tutti gli esempi di input memorizzati nella cache, come indicato di seguito:
    1. MFT non invalida il tipo di output corrente.
    2. MFT produce l'output possibile dagli esempi di input memorizzati nella cache.
    3. È facoltativo se MFT accetta nuovi esempi di input durante l'elaborazione degli esempi memorizzati nella cache. In tal caso, i nuovi esempi di input useranno il nuovo formato di input, quindi MFT deve tenere traccia del punto quando il formato è stato modificato.
  5. Dopo che MFT elabora tutti i campioni ricevuti prima della modifica del tipo di input, IMFTransform::P rocessOutput restituisce MF_E_TRANSFORM_STREAM_CHANGE.
  6. MFT invalida il tipo di output corrente e aggiorna l'elenco dei tipi di supporti di output disponibili.
  7. Il client negozia il nuovo tipo di output, come descritto in precedenza.

Le MFP asincrone devono restituire il valore TRUE per l'attributo MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE . Quando si usa un MFT asincrono, il client può presupporre che l'attributo MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE sia impostato su TRUE.

Quando MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE è TRUE, la differenza principale è che il client non è necessario svuotare MFT prima di impostare un nuovo tipo di input. Di conseguenza, il tipo di input può cambiare mentre MFT mantiene campioni di input. È importante che il MFT non elimina semplicemente questi campioni. Inoltre, il tipo di output non può cambiare fino a quando MFT elabora tutti i dati memorizzati nella cache.

Il paragrafo precedente si applica in particolare ai decodificatori video, che possono ricevere fotogrammi intercoded fuori dall'ordine temporale e quindi devono memorizzarli nella cache. Se un MFT non memorizza nella cache i campioni di input, lo svuotamento è essenzialmente un no-op. In tal caso, MFT può impostare MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE su FALSE (o lasciare l'attributo non impostato).

Si noti inoltre che ogni MFT deve gestire correttamente le modifiche del formato dopo essere state svuotate. L'attributo MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE indica se MFT supporta modifiche al formato senza svuotamento.

Modifica in modalità interlaccia

Le modifiche apportate alla modalità di interlacciamento video sono un caso speciale, perché non invalidano il tipo di supporto corrente. Viene invece specificata la modalità interlaccia per ogni fotogramma video impostando gli attributi nell'esempio multimediale. Un video MFT deve controllare ogni esempio di input per la presenza di questi flag.

La modalità interlaccia può cambiare quando la dominanza del campo passa dal campo superiore al campo inferiore o quando il video passa tra immagini progressive e interlacciate.

Per altre informazioni, vedere Flag interlacciati su esempi.

Scrittura di un MFT personalizzato