Manipulando alterações de fluxo

Este tópico descreve como uma transformação do Media Foundation (MFT) deve lidar com alterações de formato durante o streaming.

Visão geral das alterações de formato

Geralmente, há duas razões pelas quais um formato pode mudar durante o streaming.

• O cliente pode mudar para um fluxo com um novo formato. Por exemplo, na televisão digital, isso pode ocorrer devido a uma mudança de canal.
• Em alguns formatos de vídeo, como H.264, o fluxo de bits pode sinalizar uma mudança de formato. Tais alterações podem incluir alterações na dominância de campo, resolução de vídeo ou proporção de pixel.

Se o tipo de codificação mudar, o cliente pode precisar remover o MFT do pipeline e substituí-lo por outro MFT. (Por exemplo, o cliente pode precisar trocar por um novo decodificador.) Este tópico não abrange essa situação. Este tópico aborda apenas o caso em que a MFT atual pode lidar com o novo formato.

Se o formato mudar, o MFT pode exigir um novo tipo de entrada, um novo tipo de saída ou ambos.

• As alterações no tipo de entrada são iniciadas pelo cliente. Um MFT nunca altera seu próprio tipo de entrada.
• As alterações no tipo de saída são iniciadas pelo MFT. O MFT sinaliza que requer um novo tipo de saída, e o cliente negocia o novo tipo de saída com o MFT.

Assim, são possíveis três casos distintos:

• O cliente define um novo tipo de entrada. O MFT consome o novo formato, sem alteração no seu tipo de saída.
• O cliente define um novo tipo de entrada, e isso dispara uma alteração no tipo de saída.
• O tipo de entrada não muda, mas o MFT deteta uma alteração de formato no fluxo de bits, que requer um novo tipo de saída.

Implementando alterações de formato

O restante deste tópico descreve como o cliente deve processar uma alteração de formato e como implementar alterações de formato em uma MFT.

Tipo de saída

Qualquer MFT pode iniciar uma alteração no seu tipo de saída, da seguinte forma:

1. O cliente chama IMFTransform::ProcessOutput. O MFT responde da seguinte forma:
   1. O MFT não produz uma amostra de saída no ProcessOutput.
   2. O MFT estabelece o sinalizador MFT_OUTPUT_DATA_BUFFER_FORMAT_CHANGE no membro dwStatus da estrutura MFT_OUTPUT_DATA_BUFFER.
   3. O método ProcessOutput retorna o código de erro MF_E_TRANSFORM_STREAM_CHANGE.
2. O cliente chama IMFTransform::GetOutputAvailableType. Esse método retorna um conjunto atualizado de tipos de saída.
3. O cliente chama SetOutputType para definir um novo tipo de saída.
4. O cliente retoma a chamada ProcessInput/ProcessOutput.

Tipo de entrada

As alterações no tipo de entrada são iniciadas pelo cliente, nunca pelo MFT. Se o tipo de entrada mudar, ele pode disparar uma alteração para o tipo de saída.

A sequência exata de eventos depende do valor do atributo MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE.

Um MFT expõe esse atributo por meio de seu método IMFTransform::GetAttributes. O valor padrão desse atributo é FALSE; se a MFT não definir o atributo, trate o valor como FALSE.

MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE é FALSO

1. O cliente envia a mensagem MFT_MESSAGE_COMMAND_DRAIN.
2. O cliente drena o MFT chamando IMFTransform::ProcessOutput até que ProcessOutput retorne MF_E_TRANSFORM_NEED_MORE_INPUT.
3. O cliente chama IMFTransform::SetInputType para definir o novo tipo de entrada.
4. O MFT valida o tipo de entrada. Se o tipo for inválido, SetInputType retornará MF_E_INVALIDMEDIATYPE ou outro código de erro. Caso contrário, SetInputType retornará S_OK.
5. Supondo que o tipo de entrada seja válido, o MFT avalia se o tipo de saída também muda. Caso contrário, o streaming continua e nenhuma ação adicional é necessária.
6. Se o tipo de saída mudar:
   1. O MFT invalida seu tipo de mídia de saída atual e atualiza a lista de tipos de mídia de saída disponíveis.
   2. A próxima chamada para ProcessOutput retorna MF_E_TRANSFORM_STREAM_CHANGE, conforme descrito na seção anterior.
   3. O cliente chama IMFTransform::GetOutputAvailableType para obter a lista atualizada de tipos de saída.
   4. O cliente chama SetOutputType.

MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE é VERDADE

1. O cliente chama IMFTransform::SetInputType para definir o novo tipo de entrada.
2. O MFT valida o tipo de entrada. Se o tipo for inválido, SetInputType retornará MF_E_INVALIDMEDIATYPE ou outro código de erro. Caso contrário, SetInputType retornará S_OK.
3. Supondo que o tipo de entrada seja válido, o MFT avalia se o tipo de saída também muda. Caso contrário, o streaming continua e nenhuma ação adicional é necessária.
4. Antes que o tipo de saída seja alterado, o MFT deve processar quaisquer amostras de entrada em cache, da seguinte maneira:
   1. O MFT não invalida seu tipo de saída atual.
   2. O MFT produz o máximo de saída possível a partir das amostras de entrada em cache.
   3. É opcional se o MFT aceita novas amostras de entrada enquanto processa as amostras armazenadas em cache. Em caso afirmativo, as novas amostras de entrada usarão o novo formato de entrada, portanto, a MFT deve acompanhar o ponto quando o formato foi alterado.
5. Depois que o MFT tiver processado todas as amostras que recebeu antes do tipo de entrada ser alterado, o IMFTransform::ProcessOutput retorna MF_E_TRANSFORM_STREAM_CHANGE.
6. O MFT invalida seu tipo de saída atual e atualiza a lista de tipos de mídia de saída disponíveis.
7. O cliente negocia o novo tipo de saída, conforme descrito anteriormente.

MFTs assíncronas devem retornar o valor TRUE para o atributo MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE. Ao usar uma MFT assíncrona, o cliente pode assumir que o atributo MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE está definido como TRUE.

Quando MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE é TRUE, a principal diferença é que o cliente não é obrigado a drenar o MFT antes de configurar um novo tipo de entrada. Como resultado, o tipo de entrada pode mudar enquanto o MFT está retendo amostras de entrada. É importante que o MFT não se limite a ignorar estas amostras. Além disso, o tipo de saída não pode ser alterado até que o MFT processe todos os seus dados armazenados em cache.

O parágrafo anterior aplica-se especialmente aos decodificadores de vídeo, que podem receber quadros intercodificados fora da ordem temporal e, portanto, precisam armazená-los em cache. Se um MFT não armazenar amostras de entrada em cache, a drenagem é essencialmente um no-op. Nesse caso, o MFT pode definir MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE como FALSE (ou deixar o atributo não definido).

Além disso, observe que cada MFT deve lidar com as alterações de formato corretamente depois de ser drenado. O atributo MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE indica se o MFT suporta alterações de formato sem drenar.

Alteração de modo de entrelaçamento

As alterações no modo de entrelaçamento de vídeo são um caso especial, porque não invalidam o tipo de mídia atual. Em vez disso, o modo de entrelaçamento é especificado para cada quadro de vídeo através da definição de atributos na amostra de mídia. Um MFT de vídeo deve verificar cada amostra de entrada para a presença desses sinalizadores.

O modo entrelaçado pode mudar quando a dominância do campo muda do campo superior para o campo inferior, ou quando o vídeo alterna entre imagens progressivas e entrelaçadas.

Para obter mais informações, consulte Sinalizadores de entrelaçamento em Amostras.

Tópicos relacionados

Escrever um MFT Personalizado