Guía de diseño de MFT de dispositivos

La pila de captura de vídeo en Windows admite una extensión en modo de usuario en forma de DMFT. Se trata de un componente de extensión por dispositivo que proporcionan los IHV, y la canalización de captura lo inserta como la primera transformación inmediatamente después de la captura. El DMFT recibe fotogramas post-procesados del dispositivo. Se pueden realizar operaciones adicionales de post-procesamiento en los fotogramas dentro del DMFT. El DMFT puede recibir fotogramas de todos los flujos del dispositivo y puede proporcionar cualquier número de flujos de salida según los requisitos.

En este artículo se describe el diseño de una extensión de todo el dispositivo que se ejecuta en modo de usuario que se puede usar para realizar el procesamiento posterior común a todas las secuencias.

Terminología

Objetivos de diseño

• Extensión del modo de usuario para todo el filtro de dispositivo que tiene la misma duración que el filtro de dispositivo

• Admite cualquier número de entradas procedentes del dispositivo.

• Admite cualquier número de salidas (el requisito actual es de tres secuencias: vista previa, registro y foto)

• Enruta todos los controles de dispositivo a Device MFT (que opcionalmente controla o lo pasa al dispositivo).

• Procesamiento posterior paralelo de la secuencia capturada

• Permitir el procesamiento 3A independientemente de la velocidad de fotogramas

• Permitir que los metadatos de una secuencia se compartan entre otras secuencias

• Acceso a recursos de GPU

• Acceso a las colas de trabajo de MF MMCSS

• Acceso a MF Allocator

• Interfaz simple (similar a MFT)

• Arquitectura interna flexible para la extensibilidad de Proveedores Independientes de Hardware (IHV) y Fabricantes de Equipos Originales (OEM)

Restricciones de diseño

• No hay ningún cambio en la superficie de la Capture API

• Compatibilidad completa con versiones anteriores. Por ejemplo, no hay regresiones mientras se trabaja con escenarios y aplicaciones heredados.

Arquitectura de pila de captura

En este artículo se describe el soporte para una extensión de modo de usuario para todo el filtro en el controlador de captura. Este componente tiene acceso a las API MF, los grupos de subprocesos, la GPU y los recursos de ISP. La extensión de ancho de filtro proporciona la flexibilidad de tener cualquier número de secuencias entre ella y el filtro Ks del dispositivo. Esta flexibilidad permite una comunicación sin problemas fuera de banda entre la extensión en modo de usuario y el controlador que se pueden usar para metadatos dedicados y flujos de procesamiento 3A.

Administrador de transformación de dispositivos (DTM)

La pila de captura presenta un nuevo componente proporcionado por el sistema, el Gestor de Transformación de Dispositivos (DTM). Esto reside dentro de DeviceSource y administra Devproxy MFT y Device MFT. DTM realiza la negociación de MediaType, la propagación de muestras y la gestión de todos los eventos de MFT. También expone la interfaz IMFTransform a DeviceSource y otras interfaces privadas necesarias que DeviceSource necesita para administrar flujos de dispositivo. Este componente abstrae Devproxy y Device MFT de la canalización. La canalización solo ve el DTM como el dispositivo y las secuencias fuera de DTM como flujos de dispositivo.

Devproxy

Devproxy es un MFT asincrónico que gestiona los comandos y los fotogramas de vídeo entre el controlador de cámara AVStream y Media Foundation. Windows proporciona esto y admite n número de salidas del controlador de cámara. Además, este es el propietario de los asignadores para todos los pines expuestos por el dispositivo.

Dispositivo MFT

Device MFT es una extensión en modo de usuario para el controlador de captura. Es un MFT asincrónico m x n . Se instala en el sistema con el controlador de captura y lo proporciona el proveedor del controlador de captura.

El número de flujos de entrada de Device MFT debe ser el mismo que el número de patillas Ks expuestas por el dispositivo. Los mediatipos admitidos por los flujos de entrada de MFT del dispositivo deben ser los mismos que los mediatipos expuestos por los pines KS.

El número de flujos de salida expuestos por Device MFT son los flujos vistos por DeviceSource y la pila de captura, la API de captura y las aplicaciones, y pueden ser uno, dos o tres flujos. Los recuentos de flujos de entrada y salida de Device MFT no necesitan ser los mismos. Además, las secuencias de entrada y salida no necesitan tener los mismos tipos de medios y normalmente tienen distintos tipos de medios. El número de tipos de medios no debe coincidir tampoco.

El primer pin Ks representado en modo de usuario por el flujo de salida de Devproxy se asocia con la primera secuencia de entrada de Device MFT, la segunda Ks Pin representada en modo de usuario por el flujo de salida de Devproxy con la segunda secuencia de entrada de Device MFT, etc.

El dispositivo MFT recibe un puntero a Devproxy, dispositivo DX y ID de MF WorkQueue. Los fotogramas que salen del dispositivo se introducen directamente en la entrada del MFT del dispositivo correspondiente como MF Samples. Con todos estos elementos, Device MFT puede publicar el procesamiento de las muestras capturadas y servir muestras a los pins de vista previa, registro y foto.

Todos los comandos y controles que van al dispositivo son redirigidos a Device MFT. El dispositivo MFT controla los controles o los pasa al controlador a través de Devproxy. Esto optimiza el manejo de comandos mediante el conjunto de controladores de captura.

Información general sobre las funciones

Al inicializar la canalización de captura, si hay un MFT de dispositivo para el dispositivo, DeviceSource crea instancias de DTM. Pasa una instancia de Devproxy que representa el dispositivo a la rutina de inicialización de DTM. DTM cocrea Device MFT y realiza validaciones básicas; por ejemplo, verifica que el número de pines de salida de Devproxy sea igual al número de pines de entrada de Device MFT, comprueba la compatibilidad con interfaces obligatorias, etc.

DeviceSource consulta DTM para obtener los tipos de medios de salida admitidos. DTM obtiene esto de los pines de salida del dispositivo MFT. DeviceSource expone el descriptor de presentación y el descriptor de secuencia en función de esta información a la canalización de captura.

SourceReader usa los tipos de medios expuestos de DeviceSource y establece los tipos de medios predeterminados en cada secuencia. A su vez, DeviceSource establece los tipos de medios predeterminados en los flujos de salida de DTM. DTM establece el tipo de medios en el flujo de salida del dispositivo MFT mediante el método SetOutputStreamState .

Cuando se llama a SetOutputStreamState, Device MFT envía un mensaje a DTM para cambiar el tipo de medio del flujo de entrada en función del tipo de medio de salida seleccionado y espera. En respuesta a este mensaje, DTM consulta el tipo de medio de entrada preferido para el flujo de entrada de Device MFT mediante GetPreferredInputStreamState. Esto establece el tipo de medios en el flujo de salida correspondiente de Devproxy. Si esto tiene éxito, DTM asigna ese mismo tipo de medio al flujo de entrada del MFT del dispositivo utilizando SetInputStreamState. Después de recibir esta llamada, Device MFT completa SetOutputStreamState.

CaptureEngine selecciona secuencias individuales habilitando flujos específicos en DeviceSource. Esto se propaga a Device MFT by DTM a través de una llamada SetOutputStreamState . El dispositivo MFT coloca los flujos de salida específicos en el estado solicitado. Como se mencionó anteriormente, Device MFT también notifica a DTM sobre los flujos de entrada necesarios que deben estar habilitados. Esto da como resultado que DTM propague la selección de secuencia a Devproxy. Al final de este proceso, todas las secuencias necesarias, en Devproxy y Device MFT, están listas para la transmisión.

SourceReader inicia DeviceSource cuando CaptureEngine llama a ReadSample. A su vez, DeviceSource inicia el DTM enviando MFT_MESSAGE_NOTIFY_BEGIN_STREAMING y MFT_MESSAGE_NOTIFY_START_OF_STREAM mensajes que indican el inicio de la canalización. DTM inicia Devproxy y Device MFT al propagar los mensajes MFT_MESSAGE_NOTIFY_BEGIN_STREAMING y MFT_MESSAGE_NOTIFY_START_OF_STREAM.

DTM llama a SetOutputStreamState en las salidas del dispositivo MFT con el parámetro de estado de streaming. El dispositivo MFT inicia el streaming en esos flujos de salida. DTM inicia el streaming en los flujos de salida de Devproxy que tienen establecido un tipo de medio válido. Devproxy asigna los ejemplos y los captura del dispositivo. Estas muestras se envían al dispositivo MFT en el pin de entrada correspondiente. Device MFT procesa estos ejemplos y proporciona la salida a DeviceSource. Desde DeviceSource, los ejemplos fluyen a través de SourceReader a CaptureEngine.

CaptureEngine detiene las secuencias individuales deshabilitando las secuencias individuales a través de una interfaz interna en DeviceSource. La desactivación de una secuencia de salida específica en Device MFT se logra a través de SetOutputStreamState. A su vez, Device MFT puede solicitar deshabilitar flujos de entrada específicos a través del evento METransformInputStreamStateChanged . DTM propaga esto a las secuencias correspondientes de Devproxy.

Siempre que el propio Dispositivo MFT esté en estado de streaming, puede solicitar cualquier flujo de entrada para realizar la transición a cualquiera de los deviceStreamState válidos. Por ejemplo, podría enviarlo a DeviceStreamState_Stop o DeviceStreamState_Run o DeviceStreamState_Pause, etc., sin afectar a otras secuencias.

Sin embargo, la transición del flujo de salida se controla mediante la canalización de captura. Por ejemplo, la canalización de captura habilita o deshabilita la vista previa, el registro y las secuencias de fotos. Incluso cuando las salidas están deshabilitadas, un flujo de entrada podría seguir siendo streaming siempre y cuando el propio Dispositivo MFT esté en estado de streaming.

Duración del dispositivo MFT

El dispositivo MFT se carga después de crear el filtro KS. Se descarga antes de que se cierre el filtro KS.

Desde la perspectiva de una canalización, cuando se crea DeviceSource, se crea el dispositivo MFT y, cuando se apaga DeviceSource, el dispositivo MFT se apaga de forma sincrónica.

Para admitir el apagado, el MFT del dispositivo debe admitir la interfaz IMFShutdown . Después de llamar a Device MFT-Shutdown>, cualquier otra llamada de interfaz al Dispositivo MFT debe devolver un error MF_E_SHUTDOWN.

Tipo de memoria

Los fotogramas se pueden capturar en búferes de memoria del sistema o búferes de memoria DX, según la preferencia del controlador de cámara. Cualquier búfer que salga del controlador de cámara se introduce directamente en el MFT del dispositivo para su posterior procesamiento.

Devproxy asigna los búferes en función de la preferencia del controlador. Es necesario que Device MFT utilice las API de asignación MF para asignar las muestras necesarias para sus pines de salida en transformaciones no in situ.

Cambio de tipo multimedia durante el streaming

Los clientes de SourceReader pueden ver los tipos de medios expuestos por los flujos de salida de MFT del dispositivo como tipos de medios admitidos de forma nativa. Cuando se cambia el tipo de medio nativo, SourceReader envía llamadas de notificación de tipo multimedia a Device MFT a través de DeviceSource. Es responsabilidad del dispositivo MFT vaciar todas las muestras pendientes de la cola de esa secuencia y cambiar al nuevo tipo de medio en esa secuencia de manera oportuna. Si es necesario cambiar el tipo de medio de entrada, debe cambiar el tipo de medio de entrada actual a ese. DTM obtiene el tipo de medio actual de la secuencia de entrada del Dispositivo MFT y lo establece en los flujos de salida de Devproxy y la entrada del Dispositivo MFT después de cada cambio de tipo de medio nativo.

Cambio de mediatipo de entrada en el dispositivo MFT

Dado que se trata de un m x n MFT, puede haber repercusiones en los tipos de medios del pin de streaming de entrada y el cambio de estado cuando cambia el estado o los tipos de medios del pin de streaming de salida. En concreto, cuando se producen los cambios siguientes:

• Cambios en el tipo de medio de salida

  • Cuando una aplicación cambia el tipo de medio nativo, este cambio se propaga a través del stack de captura hasta Device MFT, resultando en un cambio del tipo de medio en el pin de salida.

  • Cuando cambia el tipo de medio de salida, puede desencadenar un cambio de tipo de medio de entrada. Por ejemplo, supongamos que todos los pines de salida están transmitiendo a 720p. Esto da como resultado el streaming desde la cámara a 720p. A continuación, supongamos que la secuencia de registros cambia su tipo de medio nativo a 1080p. En ese caso, uno de los flujos de entrada del MFT del dispositivo que estaba recopilando datos para la secuencia de registro tendría que cambiar su tipo de medio.

• El pin de salida está deshabilitado

  • Cuando una aplicación deshabilita una de las salidas de Device MFT cuando más de una salida comparte la misma entrada, para la optimización, es posible que la entrada tenga que cambiar el tipo de medio. Por ejemplo, si se detiene un flujo de salida de 1080p y todos los demás flujos, compartiendo una entrada, se transmiten a 720p, la secuencia de entrada debe cambiar su tipo de medio a 720p para ahorrar energía y mejorar el rendimiento.

DTM controla las notificaciones METransformInputStreamStateChanged del dispositivo MFT para cambiar el tipo de medios y el estado en la entrada MFT del dispositivo y la salida de Devproxy en estas condiciones.

Tipos de medios de salida preferidos de Device MFT

Se recomienda que el dispositivo MFT genere tipos de medios de salida mediante el formato NV12. YUY2 es la siguiente mejor alternativa. No se recomiendan los tipos de medios MJPEG y RGB.

Vaciar MFT del dispositivo

Se necesitan dos tipos de vaciado al administrar Device MFT:

• Limpieza global

  • Vaciado en todo el dispositivo MFT. Esto suele ocurrir cuando el DTM está a punto de enviar un mensaje para detener el streaming al MFT del dispositivo.

  • Se espera que el dispositivo MFT quite todas las muestras de sus colas de entrada y salida y devuelva de forma sincrónica.

  • El dispositivo MFT no debe solicitar una nueva entrada ni enviar una notificación sobre la nueva salida disponible.

• Limpieza local

  • Vaciado específico del pin de salida. Esto suele ocurrir cuando se detiene un flujo de datos.

El Gestor de MFT del Dispositivo elimina todos los eventos que se publicaron antes del reinicio. Después del vaciado, el dispositivo MFT restablece su recuento interno de seguimiento METransformHaveOutput .

Purga del dispositivo MFT

El dispositivo MFT no recibirá un mensaje de purga independiente, ya que no es necesario purgar en un origen de captura en vivo.

Desencadenador de fotos

En este modelo, en lugar de enviar directamente al controlador el desencadenador de fotos y los de inicio y detención de la secuencia de fotos, se redirigen hacia el MFT del dispositivo. El dispositivo MFT controla el desencadenador o lo reenvía al controlador de cámara según sea necesario.

Inicio en caliente

DeviceSource intenta activar un flujo de salida específico mediante la transición del flujo al estado de pausa. A su vez, DTM llama al método IMFDeviceTransform::SetOutputStreamState en device MFT para realizar la transición de un flujo de salida específico para pausar el estado. Esto da como resultado que la secuencia de entrada correspondiente se ponga en pausa. Para ello, el dispositivo MFT solicita METransformInputStreamStateChanged a DTM y controla el método IMFDeviceTransform::SetInputStreamState .

Secuencia de fotos variable

Con esta arquitectura, la secuencia de fotos se implementa con el controlador del dispositivo de cámara y el dispositivo MFT, lo que reduce considerablemente la complejidad del controlador de dispositivo de cámara. Los desencadenadores de secuencia de fotos de inicio y detención se envían al Dispositivo MFT y controlan la secuencia de fotos más fácilmente.

Confirmación de la foto

El dispositivo MFT admite la confirmación de fotos a través de la interfaz IMFCapturePhotoConfirmation . La canalización recupera esta interfaz a través del método IMFGetService::GetService .

Metadatos

Devproxy consulta el controlador para el tamaño del búfer de metadatos y asigna la memoria para los metadatos. Devproxy establece los metadatos procedentes del controlador te en el ejemplo. El dispositivo MFT consume los metadatos del ejemplo. Los metadatos se pueden pasar con la muestra por medio de su flujo de salida o usarse para su procesamiento posterior.

Con Device MFT compatible con cualquier número de entradas, se podría usar un pin de entrada dedicado solo para metadatos o metadatos fuera de banda. El tipo de medio para este pin es personalizado y el controlador decide el tamaño y el número de búferes.

Este flujo de metadatos se expone más allá de DTM. La secuencia se puede colocar en modo de transmisión cuando Device MFT inicia la transmisión. Por ejemplo, cuando se seleccionan secuencias de salida para streaming, Device MFT puede solicitar a DTM que inicie una o varias secuencias de vídeo, así como la secuencia de metadatos, mediante el evento METransformInputStreamStateChanged .

Nota: No es necesario que el número de patillas de entrada coincidan con el número de patillas de salida de este modelo. Puede haber un pin independiente dedicado para metadatos o 3A.

Control de eventos de Device Transform Manager (DTM)

Los eventos de Device Transform Manager se definen en los siguientes artículos de referencia:

• METransformFlushInputStream

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformNeedInput

Interfaz IMFDeviceTransform

La interfaz IMFDeviceTransform se define para interactuar con MFT del dispositivo. Esta interfaz facilita la administración de las entradas m y n salida del dispositivo MFT. Junto con otras interfaces, Device MFT debe implementar esta interfaz.

Propagación general de eventos

Cuando se produce un evento en Devproxy (o dentro del dispositivo), es necesario propagarlo a device MFT y a DeviceSource.

Requisitos de MFT del dispositivo

Requisitos de la interfaz

Las MFT de dispositivo deben admitir las interfaces siguientes:

• IMFDeviceTransform

• IKsControl

  • Esto permite que todas las propiedades KS, eventos y métodos pasen por la MFT del dispositivo. Esto proporciona a Device MFT la capacidad de controlar estas llamadas de funciones dentro de Device MFT o simplemente reenviarlos al controlador. En el caso de que controle los métodos KsEvent, el dispositivo MFT tiene que realizar los pasos siguientes:

    • Si Device MFT controla cualquier evento KSEVENT_TYPE_ONESHOT, duplica el identificador cuando recibe KSEVENT_TYPE_ENABLE.

    • Cuando haya terminado de establecer o generar el evento, llama a CloseHandle en el identificador duplicado.

    • Si Device MFT controla eventos que no son de KSEVENT_TYPE_ONESHOT, debe duplicar el identificador cuando recibe KSEVENT_TYPE_ENABLE y llamar a CloseHandle en el identificador duplicado cuando el evento ks está deshabilitado llamando a la función KsEvent con el primer parámetro (ks event ID) y el segundo parámetro (longitud del evento) establecido en cero. Los datos y la longitud del evento son válidos. Los datos del evento identifican de forma única un evento ks específico.

    • Si Device MFT controla eventos que no son de KSEVENT_TYPE_ONESHOT, debe duplicar el identificador al recibir KSEVENT_TYPE_ENABLE y llamar a CloseHandle en los identificadores duplicados cuando los eventos KS están deshabilitados mediante la llamada a la función KsEvent con todos los parámetros establecidos en cero.

• IMFRealTimeClientEx

• IMFMediaEventGenerator

• IMFShutdown

• IMFSampleAllocatorControl

Requisitos de notificación

Las MFT de dispositivo deben usar los siguientes mensajes para informar a DTM sobre la disponibilidad de muestras, cualquier cambio de estado de flujo de entrada, etc.

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

Requisitos de subprocesos

El dispositivo MFT no debe crear sus propios subprocesos. En su lugar, debe usar colas de trabajo de Media Foundation, que se asignan en función del identificador que se pasa a DMFT a través de la interfaz IMFRealTimeClientEx . Esto es para asegurarse de que todos los subprocesos que se ejecutan en la Device MFT obtienen la prioridad correcta a la que la canalización de captura está ejecutándose y para evitar las inversiones de prioridad de subproceso.

Requisitos de InputStream

Recuento de transmisiones

• El número de flujos de entrada en el MFT del dispositivo debe ser el mismo que el número de flujos soportados por el controlador.

MediaTypes

• El número de tipos de medios y los tipos de medios reales admitidos por la entrada de MFT del dispositivo deben coincidir con el número y los tipos de tipos de medios admitidos por el controlador.

• El número podría ser diferente solo si los tipos de medios admitidos por la entrada de Device MFT son un subconjunto de los tipos de medios admitidos por el controlador.

• Los tipos de medios admitidos por el controlador y la entrada de Device MFT podrían ser tipos de medios estándar o personalizados.

Cómo registrar el dispositivo MFT

El dispositivo de cámara INF debe tener la siguiente entrada de interfaz de dispositivo que especifica el CLSID de la CoClass del dispositivo MFT.

[CaptureAvstrm.Device.NTarm.Interfaces]
AddInterface = %KSCATEGORY_VIDEO_CAMERA%, %Capture.FilterDescBack%, Capture.FilterBack

[Capture.FilterBack]
AddReg = Capture.FilterBack.AddReg, PinNames.AddReg

[Capture.FilterBack.AddReg]
HKR,,FriendlyName,,%Capture.FilterDescBack%
HKR,,CameraDeviceMftClsid,,%CameraDeviceMFT.Clsid%

Estas entradas INF dan lugar a que se escriban las siguientes claves del Registro:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceClasses\{E5323777-F976-4f5b-9B55-B94699C46E44}\##?#USB#VID_045E&PID_075D&MI_00#8&23C3DB65&0&0000#{E5323777-F976-4f5b-9B55-B94699C46E44}\#GLOBAL\Device Parameters]
"CLSID"="{17CCA71B-ECD7-11D0-B908-00A0C9223196}"
"FriendlyName"="USB Video Device"
"CameraDeviceMftClsid"="{3456A71B-ECD7-11D0-B908-00A0C9223196}"<<< Device MFT CoClass ID >>>

Encadenamiento de MFT de dispositivos

Device MFT es el mecanismo de complemento de modo de usuario recomendado para IHD y OEM para ampliar la funcionalidad de la cámara en Windows.

Antes de Windows 10, versión 1703, la canalización de cámara solo admitía un complemento de extensión DMFT.

A partir de Windows 10, versión 1703, la canalización de cámara de Windows admite una cadena opcional de DMFT con un máximo de dos DMFT.

A partir de Windows 11, versión 22H2, la canalización de cámara de Windows admite una cadena opcional de DMFT con un máximo de cuatro DMFT.

Esto proporciona una mayor flexibilidad para que los OEM e IHV proporcionen un valor añadido en forma de procesamiento posterior de secuencias de cámara. Por ejemplo, un dispositivo podría usar PDMFT junto con un IHV DMFT y un DMFT OEM.

En la ilustración siguiente se muestra la arquitectura que implica una cadena de DMFT.

El flujo de muestras se captura desde el controlador de cámara hacia DevProxy y, a continuación, pasa por las cadenas de DMFT. Cada DMFT de la cadena tiene la oportunidad de procesar la muestra. Si la DMFT no desea procesar la muestra, puede actuar como un conducto; simplemente pasa la muestra a la siguiente DMFT.

En el caso de controles como KsProperty, la llamada se envía hacia arriba en la cadena: la última DMFT de la cadena es la primera en recibir la llamada. La llamada se puede atender allí o derivarse al DMFT anterior en la cadena.

Los errores se propagan de DMFT a DTM y, a continuación, a las aplicaciones. En el caso de los DMFT de IHV/OEM, si cualquiera de los DMFT no logra instanciarse, es un error fatal para DTM.

Requisitos de los DMFT:

• El número de patillas de entrada del DMFT debe coincidir con el número de patillas de salida de las DMFT anteriores. De lo contrario, DTM produciría un error durante la inicialización. Sin embargo, el número de pines de entrada y salida del mismo DMFT no necesita coincidir.

• DMFT necesita admitir interfaces - IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl y IMFMediaEventGenerator; IMFTransform podría necesitar ser compatible si hay MFT0 configurado o la siguiente DMFT en la cadena requiere compatibilidad con IMFTransform.

• En sistemas de 64 bits que no usan Frame Server, se deben registrar tanto los DMFTs de 32 bits como los de 64 bits. Dado que una cámara USB podría conectarse a un sistema arbitrario, para cámaras USB "externas", el proveedor de cámaras USB debe suministrar tanto DMFTs de 32 bits como de 64 bits.

Configuración de la cadena DMFT

Un dispositivo de cámara puede proporcionar opcionalmente un objeto COM DMFT en un archivo DLL mediante un archivo INF personalizado que usa secciones de la bandeja de entrada USBVideo.INF.

En la sección "Interface AddReg" del archivo .INF personalizado, especifique los CLSID de DMFT agregando la siguiente entrada del Registro:

CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft. CLSID%,%Dmft2.CLSID%

Como se muestra en la configuración de INF de ejemplo siguiente (reemplace el %Dmft0.CLSID% y % Dmft1.CLSID% por las cadenas CLSID reales que usa para las DMFT), hay un máximo de 2 CLSID permitidos en Windows 10, versión 1703, y el primero es el más cercano a DevProxy y el último es el último DMFT en la cadena.

El CLSID de DMFT de plataforma es {3D096DDE-8971-4AD5-98F9-C74F56492630}.

Algunos ejemplos de configuración cameraDeviceMftCLSIDChain :

• No DMFT de IHV/OEM ni DMFT de plataforma

  • CameraDeviceMftCLSIDChain = "" (o no es necesario especificar esta entrada del Registro)

• IHV/OEM DMFT

  • CameraDeviceMftCLSIDChain = %Dmft.CLSID%

• Plataforma DMFT <-> IHV/OEM DMFT

  • CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%

  • Esta es una captura de pantalla de la clave del Registro de resultados para una cámara USB con Platform DMFT y una DMFT (con GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) en la cadena.

• IHV/OEM DMFT0 <-> IHV/OEM DMFT1

  • CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,

Si CameraDeviceMftCLSIDChain está configurado, DTM omite las opciones de configuración heredadas de CameraDeviceMftCLSID.

Si CameraDeviceMftCLSIDChain no está configurado y el CameraDeviceMftCLSID heredado está configurado, la cadena se vería así: (si es una cámara USB y es compatible con Platform DMFT y Platform DMFT está habilitado) DevProxy <–> Platform DMFT <–> OEM/IHV DMFT o (si la cámara no es compatible con Platform DMFT o Platform DMFT está deshabilitado) DevProxy <–> OEM/IHV DMFT.

Configuración de archivo INF de ejemplo:

[USBVideo.Interface.AddReg]
HKR,,CLSID,,%ProxyVCap.CLSID%
HKR,,FriendlyName,,%USBVideo.DeviceDesc%
HKR,,RTCFlags,0x00010001,0x00000010
HKR,,EnablePlatformDmft,0x00010001,0x00000001
HKR,,DisablePlatformDmftFeatures,0x00010001,0x00000001
HKR,,CameraDeviceMftCLSIDChain, 0x00010000,%Dmft0.CLSID%,%Dmft1.CLSID%

Objeto COM y registro de MFT de dispositivo

En lugar de registrar globalmente el objeto COM del controlador, el objeto COM del controlador se registra en la clave del dispositivo. Esto permite el registro COM de MFT desde el contenedor y evita que se creen claves del Registro global, lo que conserva el aislamiento del paquete de controladores. Las MFT también se registran en la clave del dispositivo por los mismos motivos.

Cambios en el controlador INF

Tras la instalación del controlador de dispositivo, el INF debe realizar ahora todos los registros de objetos COM y MFT en la clave del dispositivo. Los registros MFT y COM deben cambiar como se muestra aquí:

Registros de MFT

Registros COM

En Windows 26100 y versiones posteriores, todo registro COM para las MFT del dispositivo debe usar directivas AddComServer/AddComClass en INF. Aquí se muestra un ejemplo de sintaxis:

[AvsCamera.COM]
AddComServer = AvsCameraMFT,,AvsCamera.COMInstall

[AvsCamera.COMInstall]
ServerType = 1; in-proc
ServerBinary = %13%\AvsCameraDMFT.dll
AddComClass = %DMFT.CLSID%,, AvsCamera.COMClassInstall


[AvsCamera.COMClassInstall]
ThreadingModel = Both
Description = %AvsCamera.ComServerDescription%

Las versiones anteriores del registro COM de Device MFT usaban AddReg para instalar manualmente la clase COM.

La sintaxis INF para diferenciar en función de la versión del sistema operativo se puede encontrar en Combinación de extensiones de plataforma con versiones del sistema operativo. A partir de la ventana 11 25300, el INF debe cumplir estas nuevas claves del Registro. Las versiones anteriores del sistema operativo usan las claves del Registro tradicionales para la compatibilidad. El INF debe configurar estas claves del Registro en la ubicación antigua en compilaciones anteriores del sistema operativo y crear las nuevas claves en su nueva ubicación para las compilaciones más recientes del sistema operativo. Por ejemplo, para un registro de MFT en una compilación anterior, INF crea la clave en la siguiente entrada del Registro:

HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\ 

Para un registro de MFT en una nueva compilación, INF crea la clave en la siguiente entrada del Registro:

**software key**\MediaFoundation\Transforms\{clsid}\ 

Esta entrada define dónde la clave de software representa la clave de software de un dispositivo.

Para obtener más información, consulte Apertura de la clave de software de un dispositivo.

Aquí se muestra un ejemplo de cómo apuntar a diferentes versiones de sistemas operativos.

[Manufacturer] 
%Msft% = Msft, NTamd64,NTamd64.10.0...25300 

; -------------- ; 
; Models Section ; 
; -------------- ; 

; Targets old builds
[Msft.NTamd64] 
%DeviceDesc% = ExampleDDInstall_Old, ExampleHardwareId

[ExampleDDInstall_Old]
 AddReg = MFT_Registration_Old

[MFT_Registration_Old]
; INF work for older build here

; Windows 10 build with build number equal to or greater than 25300 
[msft.ntamd64.10.0...25300]  
%DeviceDesc% = ExampleDDInstall_New, ExampleHardwareId

[ExampleDDInstall_new]
AddReg = MFT_Registration_new

[MFT_Registration_new]
; INF work for newer build here