MFT de hardware
Nota
Este tema se aplica a Windows 7 o posterior.
En este tema se describe cómo escribir una transformación de Media Foundation (MFT) que actúa como proxy a un codificador de hardware, descodificador o procesador de señal digital (DSP).
Importante
Si un códec de hardware usa el controlador de clase multimedia AVStream, no requiere un MFT personalizado. Media Foundation proporciona un proxy AVStream para este propósito. La información de este tema solo se aplica en el caso especial en el que el códec de hardware no usa AVStream. Para obtener más información, consulte compatibilidad con códecs de hardware en AVStream.
Este tema contiene las secciones siguientes:
- introducción
- atributos MFT de hardware de
- secuencia de protocolo de enlace de hardware
- procesamiento de datos de
- descodificador/codificador emparejado
- temas relacionados
Introducción
Cualquier códec de hardware que no se base en AVStream debe proporcionar su propio MFT para actuar como proxy para el controlador. Un códec de hardware puede incorporar varios bloques funcionales distintos:
- Codificador
- Descodificador
- Conversión de formato y escalado de fotogramas
Cada una de estas funciones debe administrarse mediante un MFT independiente. Un MFT de hardware nunca debe actuar como un "transcodificador" de varios propósitos. En su lugar, coloque las funciones de codificación en un codificador MFT y las funciones de descodificación en un MFT de descodificador. Si el hardware ofrece conversiones de formato y escalado de fotogramas, coloque esas funciones en un procesador de vídeo independiente, registrado en la categoría MFT_CATEGORY_VIDEO_PROCESSOR. Si el hardware no admite el escalado de fotogramas o la conversión de formato, Media Foundation proporciona un procesador de vídeo de software.
Las MFT de hardware tienen los siguientes requisitos generales:
- Las MFT de hardware deben usar el nuevo modelo de procesamiento asincrónico, tal como se describe en MFT asincrónicas.
- Las MFT de hardware deben admitir cambios de formato dinámico, como se describe en Cambios de formato dinámico.
Atributos MFT de hardware
Un MFT de hardware debe implementar los siguientes métodos relacionados con los atributos:
- IMFTransform::GetAttributes: devuelve un almacén de atributos para los atributos MFT globales.
- IMFTransform::GetInputStreamAttributes: devuelve un almacén de atributos para un flujo de entrada.
- IMFTransform::GetOutputStreamAttributes: devuelve un almacén de atributos para un flujo de salida.
Cuando se crea el MFT por primera vez, debe establecer los atributos siguientes en su propio almacén de atributos global (es decir, el almacén de atributos devuelto por GetAttributes):
Atributo | Descripción |
---|---|
MF_TRANSFORM_ASYNC | Debe establecerse en TRUE. Indica que MFT realiza el procesamiento asincrónico. |
MFT_ENUM_HARDWARE_URL_Attribute | Contiene el vínculo simbólico para el dispositivo de hardware. El cargador de topología usa la presencia de este atributo para probar si un MFT representa un dispositivo de hardware. |
MFT_SUPPORT_DYNAMIC_FORMAT_CHANGE | Debe establecerse en TRUE. Indica que MFT admite cambios de formato dinámico. |
Secuencia de protocolo de enlace de hardware
Si dos MFT representan el mismo dispositivo físico, pueden intercambiar datos dentro del hardware, por ejemplo, a través de un bus de hardware. No es necesario copiar los datos en la memoria del sistema y volver al dispositivo.
En el diagrama siguiente, los MFT etiquetados como "A" y "B" representan bloques funcionales dentro del mismo hardware. Por ejemplo, en un escenario de transcodificación, "A" podría representar un descodificador de hardware y "B" podría representar un codificador de hardware. El flujo de datos entre "A" y "B" se produce dentro del hardware. El MFT con la etiqueta "C" es un software MFT. El flujo de datos de "B" a "C" usa memoria del sistema.
Para establecer una conexión de hardware, las dos MFT de hardware deben usar un canal de comunicación privado. Esta conexión se establece durante la negociación de formato, antes de establecer los tipos multimedia y antes de la primera llamada a ProcessInput. El proceso de conexión funciona de la siguiente manera:
El cargador de topología comprueba ambas TMF para la presencia del atributo MFT_ENUM_HARDWARE_URL_Attribute. Tenga en cuenta que no examina el valor de este atributo.
Si MFT_ENUM_HARDWARE_URL_Attribute está presente en ambas MFT, el cargador de topología hace lo siguiente:
- El cargador de topología llama a IMFTransform::GetOutputStreamAttributes en el MFT (A) ascendente. Este método devuelve un puntero IMFAttributes. Deje que este puntero se denota pUpstream .
- El cargador de topología llama a IMFTransform::GetInputStreamAttributes en el MFT de bajada (B). Esta llamada también devuelve un puntero IMFAttributes. Deje que este puntero se denota pDownstream.
- El cargador de topología establece el atributo MFT_CONNECTED_STREAM_ATTRIBUTE en pDownstream llamando a IMFAttributes::SetUnknown. El valor del atributo es el puntero pUpstream.
- El cargador de topología establece el atributo MFT_CONNECTED_TO_HW_STREAM en true en pDownstream y pUpstream.
En este punto, el MFT de bajada tiene un puntero al almacén de atributos de MFT ascendente, como se muestra en el diagrama siguiente.
Nota
Para mayor claridad, en este diagrama se muestran los flujos y los almacenes de atributos como objetos distintos, pero eso no es necesario para la implementación.
El MFT descendente usa el IMFAttributes puntero para establecer un canal de comunicación privado con el MFT ascendente. Dado que el canal es privado, la implementación define el mecanismo exacto. Por ejemplo, el MFT podría consultar una interfaz COM privada.
Durante el paso 4, el MFT de bajada debe comprobar si los dos MFT comparten el mismo dispositivo físico. Si no es así, deben recurrir al uso de la memoria del sistema para el transporte de datos. Esto permite que el MFT funcione correctamente con MFT de software y otros dispositivos de hardware.
Si el protocolo de enlace se realiza correctamente y los dos MFT comparten un canal de datos privado, no usan el modelo de procesamiento de datos estándar (descrito en la sección siguiente) en el punto de conexión. En concreto, el MFT descendente no envía eventos METransformNeedInput; para obtener más información, consulte la sección siguiente de este tema.
Procesamiento de datos
Cuando un MFT de hardware usa la memoria del sistema para el transporte de datos, el proceso funciona de la siguiente manera:
- Para solicitar más entrada, MFT envía un evento METransformNeedInput.
- El evento METransformNeedInput hace que la canalización llame a IMFTransform::P rocessInput.
- Cuando MFT tiene datos de salida, MFT envía un evento METransformHaveOutput.
- El evento METransformHaveOutput hace que la canalización llame a IMFTransform::P rocessOutput.
Para obtener más información, consulte MFP asincrónicas.
Sin embargo, si el MFT usa un canal de hardware, no envía estos eventos en el punto de conexión de hardware, ya que toda la transferencia de datos se produce internamente dentro del hardware. Por lo tanto, la canalización no llama a ProcessInput ni ProcessOutput en el punto de conexión.
Por ejemplo, considere el primer diagrama de este tema. Dada esta configuración, el procesamiento de datos se produciría de la siguiente manera:
- "A" envía METransformNeedInput para solicitar datos.
- La canalización llama a ProcessInput en "A".
- "A" y "B" procesan los datos en hardware.
- Una vez completado el procesamiento, "B" envía un evento METransformHaveOutput.
- La canalización llama ProcessOutput en "B".
Descodificador/codificador emparejado
Si un descodificador y un codificador se encuentran en el mismo chip de hardware, puede ser preferible usarlos juntos al transcodificar. Es decir, seleccionar uno debe hacer que se seleccione el otro en la canalización de transcodificación. Para asegurarse de que se eligen los códecs de hardware coincidentes, ambos TMF de códec deben ofrecer un tipo de medio personalizado. Para crear un tipo de medio personalizado:
- Establezca el atributo MF_MT_MAJOR_TYPE en MFMediaType_Audio o MFMediaType_Video, según corresponda.
- Establezca el atributo MF_MT_SUBTYPE en un valor GUID personalizado.
Otros atributos de tipo son opcionales. El descodificador devuelve el tipo personalizado de su IMFTransform::GetOutputAvailableTypey el codificador devuelve el tipo personalizado de su método IMFTransform::GetInputAvailableType. En ambos casos, el tipo personalizado debe ser la primera entrada de la lista (dwTypeIndex = 0).
Para trabajar con códecs de software, el códec también debe devolver al menos un formato estándar, como NV12 para vídeo. Los formatos estándar deben aparecer después del tipo personalizado (dwTypeIndex> 0). Si los dos códecs siempre deben emparejarse y no pueden interoperar con códecs de software, las MFT deben devolver solo el formato personalizado y no devolver ningún formato estándar.
Nota
Si un descodificador no devuelve ningún formato estándar, no se puede usar para la reproducción con el representador de vídeo mejorado . En ese caso, debe registrarse como descodificador de solo transcodificación. Consulte Transcode-Only de descodificadores .
Temas relacionados
-
escribir un MFT personalizado
-
implementación de un MFT de códec