MFP 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 para 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 fin. 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 siguientes secciones:
- Introducción
- Atributos MFT de hardware
- Secuencia de protocolo de enlace de hardware
- Procesamiento de datos
- 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" multiuso. En su lugar, coloque las funciones de codificación en un codificador MFT y descodificar funciones en un descodificador MFT. 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 la conversión de formato o escalado de fotogramas, 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, como se describe en MFP asincrónicas.
- Las MFP 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 siguientes atributos 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 del dispositivo de hardware. El cargador de topología usa la presencia de este atributo para comprobar 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 MFP 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, las MFP etiquetadas 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 etiquetado como "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 que se establezcan los tipos de medios 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 MFP para comprobar 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 MFP, el cargador de topologías 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 denote pUpstream.
- El cargador de topología llama a IMFTransform::GetInputStreamAttributes en el MFT (B) de bajada. Esta llamada también devuelve un puntero IMFAttributes . Deje que este puntero se denote pDownstream.
- El cargador de topología establece el atributo MFT_CONNECTED_STREAM_ATTRIBUTE en pDownstream mediante una llamada 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 utiliza el puntero IMFAttributes 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 descendente debe comprobar si las dos MPT 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 MFP 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, el 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 todas las transferencias de datos se producen 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 el hardware.
- Una vez completado el procesamiento, "B" envía un evento METransformHaveOutput .
- La canalización llama a 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 el otro se seleccione en la canalización de transcodificación. Para asegurarse de que se eligen los códecs de hardware coincidentes, ambos códecs deben ofrecer un tipo de medio personalizado. Para crear un tipo de medio personalizado:
- Establezca el atributo MF_MT_MAJOR_TYPEen 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::GetOutputAvailableType y 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 estar emparejados y no pueden interoperar con códecs de software, las MFP solo deben devolver 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 Descodificadores de solo transcodificación.
Temas relacionados