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. Este es un componente de extensión por dispositivo que suministran los IHV, y la tubería de captura lo inserta como la primera transformación, después de la captura. DMFT recibe fotogramas procesados posteriormente del dispositivo. Se pueden realizar más operaciones para el procesamiento posterior de los fotogramas dentro del DMFT. DMFT puede recibir fotogramas de todas las secuencias del dispositivo y puede exponer cualquier número de secuencias de salida según el requisito.
En este artículo se describe el diseño de una extensión de todo el dispositivo que se ejecuta en modo de usuario y que se puede usar para realizar el procesamiento posterior común a todas las secuencias.
Terminología
| Término | Descripción |
|---|---|
| KS | Controlador de streaming de kernel |
| AVStream | Modelo de controlador de streaming de audio y vídeo |
| Filtro | Objeto que representa una instancia de dispositivo |
| MFT de dispositivos | Extensión del controlador de captura en modo de usuario proporcionada por los IHV |
| Devproxy | MF <-> serializador AVStream |
| DTM | Administrador de transformaciones de dispositivos que administra devproxy y MFT de dispositivos. Representa el dispositivo en la canalización MF. |
Objetivos de diseño
Extensión del modo de usuario para todo el filtro del dispositivo que tiene la misma duración que el filtro del dispositivo
Admitir cualquier número de entradas procedentes del dispositivo
Admitir cualquier número de salidas (el requisito actual es de tres secuencias: vista previa, registro y foto)
Enviar todos los controles de dispositivo al dispositivo MFT (que opcionalmente los gestiona o los pasa al dispositivo)
Procesamiento posterior paralelo de la secuencia capturada
Permitir el procesamiento 3A independientemente de la velocidad del fotograma
Permitir que los metadatos una secuencia se compartan entre otros secuencias
Tener acceso a recursos de la GPU
Tener acceso a las colas de trabajo MF MMCSS
Tener acceso a MF Allocator
Interfaz simple (similar a MFT)
Arquitectura interna flexible para extensibilidad de IHV/OEM
Restricciones de diseño
No hay ningún cambio en la superficie de 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 la compatibilidad con una extensión de modo de usuario de todo el filtro para el controlador de captura. Este componente tiene acceso a las API de MF, grupos de subprocesos, GPU y recursos de ISP. La amplia extensión del filtro proporciona la flexibilidad de tener cualquier número de secuencias entre sí y el filtro KS del dispositivo. Esta flexibilidad permite una comunicación fuera de banda fluida entre la extensión en modo de usuario y el controlador que se puede usar para metadatos dedicados y secuencias de procesamiento 3A.
Administrador de transformación de dispositivos (DTM)
La pila de captura presenta un nuevo componente proporcionado por el sistema, el Administrador de transformación de dispositivos (DTM). Este administrador reside dentro de DeviceSource y administra a Devproxy y la MFT de dispositivos. DTM realiza la negociación MediaType, la propagación de muestras y todo el manejo de eventos de la MFT. También expone la interfaz IMFTransform a DeviceSource y otras interfaces privadas necesarias que DeviceSource necesita para administrar las secuencias de dispositivo. Este componente abstrae Devproxy y dispositivo MFT de la canalización. La canalización solo ve el DTM como el dispositivo y las secuencias fuera de DTM como secuencias de dispositivo.
Devproxy
Devproxy es una MFT asincrónica que serializa los comandos y fotogramas de vídeo entre el controlador de cámara AVStream y Media Foundation. Windows proporciona esto y admite n números de salidas del controlador de cámara. Además, este es el propietario de los asignadores para todos los pines expuestos por el dispositivo.
MFT de dispositivos
La MFT de dispositivos es una extensión en modo de usuario para el controlador de captura. Es un MFT asincŕonico 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 secuencias de entrada de la MFT de dispositivos debe ser el mismo que el número de pines KS expuestos por el dispositivo. Los tipos de medios que admiten las secuencias de entrada de la MFT de dispositivos deben ser los mismos que los tipos de medios expuestos por los pines KS.
La cantidad de secuencias de salida expuestas por la MFT de dispositivos son las secuencias vistas por DeviceSource y la pila de captura, la API de captura y las aplicaciones, y pueden ser una, dos o tres secuencias. Los recuentos de secuencias de entrada y salida de la MFT de dispositivos 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 tampoco debe coincidir.
El primer pin KS representado en modo de usuario por la secuencia de salida de Devproxy se asocia con la primera secuencia de entrada de la MFT de dispositivos, el segundo pin KS representado en modo de usuario por la secuencia de salida Devproxy con la segunda secuencia de entrada de la MFT de dispositivos, etc.
Al dispositivo MFT se le asigna un puntero a Devproxy, al dispositivo DX y al ID de mf WorkQueue. Los fotogramas que salen del dispositivo se introducen directamente en la entrada del dispositivo MFT correspondiente como muestras MF. Con todos estos elementos, el dispositivo 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 se redireccionan al dispositivoMFT. El dispositivo MFT gestiona los controles o los pasa al controlador a través de Devproxy. Esto simplifica el control de comandos mediante la pila del controlador de captura.
Introducción a las funciones
Al inicializar la canalización de captura, si hay una MFT de dispositivos para el dispositivo, DeviceSource crea una instancia de DTM. Pasa una instancia de Devproxy que representa el dispositivo a la rutina de inicialización de DTM. DTM crea conjuntamente la MFT de dispositivos y realiza validaciones básicas, por ejemplo, verifica que la cantidad de pines de salida de Devproxy sea igual a la cantidad de pines de entrada de la MFT de dispositivos, compatibilidad con interfaces obligatorias, etc.
DeviceSource consulta a DTM para obtener los tipos de medios de salida admitidos. DTM obtiene esta información de los pines de salida de la MFT de dispositivos. DeviceSource expone el descriptor de presentación y el descriptor de transmisión 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 las secuencias de salida de DTM. DTM establece el tipo de medios en la secuencia de salida de la MFT de dispositivos mediante el método SetOutputStreamState.
Cuando se llama a SetOutputStreamState, la MFT de dispositivos envía un mensaje a DTM para cambiar el tipo de medios de la secuencia 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 la secuencia de entrada de la MFT de dispositivos mediante GetPreferredInputStreamState. Esto establece el tipo de medios en la secuencia de salida correspondiente de Devproxy. Si esto se realiza correctamente, DTM establece ese mismo tipo de medio en la secuencia de entrada de la MFT de dispositivos mediante SetInputStreamState. Después de recibir esta llamada, la MFT de dispositivos completa SetOutputStreamState.
CaptureEngine selecciona secuencias individuales habilitando secuencias específicas en DeviceSource. Esto se propaga a la MFT de dispositivos por DTM a través de una llamada SetOutputStreamState. La MFT de dispositivos coloca las secuencias de salida específicas en el estado solicitado. Como se mencionó anteriormente, la MFT de dispositivos también notifica a DTM sobre las secuencias de entrada necesarias que deben estar habilitadas. Esto da como resultado que DTM propague la selección de la secuencia a Devproxy. Al final de este proceso, todas las secuencias necesarias, en Devproxy y MFT de dispositivos, están listas para transmitirse.
SourceReader inicia DeviceSource cuando CaptureEngine llama a ReadSample. A su vez, DeviceSource inicia DTM enviando mensajes MFT_MESSAGE_NOTIFY_BEGIN_STREAMING y MFT_MESSAGE_NOTIFY_START_OF_STREAM que indican el inicio de la canalización. DTM inicia Devproxy y MFT de dispositivos propagando los mensajes MFT_MESSAGE_NOTIFY_BEGIN_STREAMING y MFT_MESSAGE_NOTIFY_START_OF_STREAM.
Nota:
Asigne los recursos necesarios en el streaming inicial en lugar de inicializar la MFT de dispositivos.
DTM llama a SetOutputStreamState en las salidas de la MFT de dispositivos con el parámetro de estado de streaming. La MFT de dispositivos inicia el streaming en esas secuencias de salida. DTM inicia el streaming en las secuencias de salida de Devproxy que tienen establecido un tipo de medios válido. Devproxy asigna las muestras y las recupera del dispositivo. Estas muestras se introducen en la MFT de dispositivos en el pin de entrada correspondiente. La MFT de dispositivos procesa estas muestras y proporciona la salida a DeviceSource. Desde DeviceSource, las muestras fluyen a través de SourceReader hasta CaptureEngine.
CaptureEngine detiene las secuencias individuales deshabilitándolas a través de una interfaz interna en DeviceSource. Esto se traduce en una secuencia de salida específica que se deshabilita en la MFT de dispositivos a través de SetOutputStreamState. A su vez, la MFT de dispositivos puede solicitar deshabilitar secuencias de entrada específicas a través del evento SetOutputStreamState. DTM propaga esto a las secuencias de Devproxy correspondientes.
Siempre que la propia MFT de dispostivos esté en estado de streaming, puede solicitar cualquier secuencia de entrada para realizar la transición a cualquiera de los DeviceStreamState válidos. Por ejemplo, podría enviarla a DeviceStreamState_Stop, DeviceStreamState_Run o DeviceStreamState_Pause, etc., sin afectar a otras secuencias.
Sin embargo, la transición de la secuencia 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, una secuencia de entrada podría seguir siendo streaming siempre y cuando la propia MFT de dispositivos esté en estado de streaming.
Duración de una MFT de dispositivos
La MFT de dispositivos se carga después de crear el filtro KS. Y se descarga antes de que se cierre el filtro KS.
Desde la perspectiva de una canalización, cuando se crea DeviceSource, se crea la MFT de dispositivos y, cuando se apaga DeviceSource, la MFT de dispositivos se apaga de forma sincrónica.
Para permitir el apagado, la MFT de dispositivos debe admitir la interfaz IMFShutdown. Después de llamar a Device MFT->Shutdown cualquier otra llamada de interfaz a la MFT de dispositivos debe devolver un error MF_E_SHUTDOWN.
Tipo de memoria
Los fotogramas se pueden capturar en búferes de memoria del sistema o en búferes de memoria DX, según la preferencia del controlador de la cámara. Cualquier búfer que salga del controlador de la cámara se introduce directamente en la MFT de dispositivos para su posterior procesamiento.
Devproxy asigna los búferes en función de la preferencia del controlador. Se requiere que la MFT de dispositivos utilice las API del asignador MF para asignar las muestras necesarias para sus pines de salida para transformaciones no in situ.
Cambio de tipo de medio durante el streaming
Los clientes de SourceReader pueden ver los tipos de medios expuestos por las secuencias de salida de la MFT de dispositivos como tipos de medios compatibles de forma nativa. Cuando se cambia el tipo de medio nativo, SourceReader envía llamadas de notificación de tipo multimedia a la MFT de dispositivos a través de DeviceSource. Es responsabilidad de la MFT de dispositivos vaciar todas las muestras pendientes de la cola de esa secuencia y cambiar al nuevo tipo de medios en la secuencia de manera oportuna. Si fuera necesario cambiar el tipo de medio de entrada, entonces se debe cambiar el tipo de medio de entrada actual por ese. DTM obtiene el tipo de medio actual de la secuencia de entrada de la MFT de dispositivos y lo establece en las secuencias de salida de Devproxy y en la entrada de la MFT de dispositivos después de cada cambio de tipo de medio nativo.
Cambio del tipo de medio de entrada en una MFT de dispositivos
Dado que se trata de una MFT m x n, 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, se transmite a través de la pila de captura a una MFT de dispositivos como un cambio de tipo de medio del 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 se transmiten a 720 p. Esto da como resultado el streaming desde la cámara a 720 p. A continuación, supongamos que la secuencia de registros cambia su tipo de medio nativo a 1080 p. En ese caso, una de las secuencias de entrada de la MFT de dispositivos que estaba capturando datos en la secuencia de registros tendría que cambiar su tipo de medio.
El pin de salida está deshabilitado
- Cuando una aplicación deshabilita una de las salidas de la MFT de dispositivos cuando más de una salida comparte la misma entrada, para la optimización, es posible que la entrada deba cambiar el tipo de medio. Por ejemplo, si una secuencia de salida de 1080 p se detiene y todas las demás secuencias que comparten una entrada se transmiten a 720 p, la secuencia de entrada debe cambiar su tipo de medio a 720 p para ahorrar energía y mejorar el rendimiento.
DTM controla las notificaciones METransformInputStreamStateChanged desde la MFT de dispositivos para cambiar el tipo de medios y el estado en la entrada de la MFT de dispositivos y la salida de Devproxy en estas condiciones.
Tipos de medios de salida preferidos de una MFT de dispositivos
Se recomienda que la MFT de dispositivos genere tipos de medios de salida con formato NV12. El formato YUY2 es la siguiente mejor alternativa. No se recomiendan los tipos de medios MJPEG y RGB.
Vaciado de una MFT de dispositivos
Al administrar una MFT de dispositivos se necesitan dos tipos de vaciado:
Vaciado global
Vaciado en toda la MFT de dispositivos. Esto suele ocurrir cuando DTM está a punto de enviar un mensaje de detención de streaming a la MFT de dispositivos.
Se espera que la MFT de dispositios descarte todas las muestras de sus colas de entrada y salida y regrese de forma sincrónica.
La MFT de dispositivos no debería solicitar una nueva entrada ni enviar una notificación sobre una nueva salida disponible.
Vaciado local
- Vaciado específico del pin de salida. Esto suele ocurrir cuando se detiene una secuencia.
El administrador de la MFT de dispositivos descarta todos los eventos publicados antes del vaciado. Después del vaciado, la MFT de dispositivos restablece su recuento interno METransformHaveOutput.
Purga de una MFT de dispositivos
La MFT de dispositivos 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 los desencadenadores de fotos y los desencadenadores de inicio y detención de la secuencia de fotos directamente al controlador, se redirigen a la MFT de dispositivos. La MFT de dispositivos controla el desencadenador o lo reenvía al controlador de cámara según sea necesario.
Inicio intermedio
DeviceSource intenta un inicio intermedio de una secuencia de salida específica mediante la transición de la secuencia al estado de pausa. A su vez, DTM llama al método IMFDeviceTransform::SetOutputStreamState en la MFT de dispositivos para realizar la transición de una secuencia de salida específica para pausar el estado. Esto da como resultado la secuencia de entrada correspondiente que se va a poner en pausa. Para ello, la MFT de dispositivos 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 la MFT de dispositivos, lo que reduce considerablemente la complejidad del controlador del dispositivo de cámara. Los desencadenadores de secuencia de fotos de inicio y detención se envían a la MFT de dispositivos y controlan la secuencia de fotos más fácilmente.
Confirmación de la foto
La MFT de dispositivos 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 al controlador sobre el tamaño del búfer de metadatos y asigna la memoria para los metadatos. Devproxy aún establece los metadatos procedentes del controlador en la muestra. La MFT de dispositivos consume los metadatos de la muestra. Los metadatos pueden transmitirse con la muestra a través de su secuencia de salida o utilizarse para su procesamiento posterior.
Dado que una MFT de dispositivos admite cualquier cantidad 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 estado de streaming cuando la MFT de dispositivos inicia el streaming. Por ejemplo, cuando se seleccionan secuencias de salida para streaming, la MFT de datos 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 la cantidad de pines de entrada coincidan con la cantidad de pines de salida de este modelo. Puede haber un pin independiente dedicado para metadatos o 3A.
Control de eventos del Administrador de transformación de dispositivos (DTM)
Los eventos del Administrador de transformación de dispositivos se definen en los siguientes artículos de referencia:
Interfaz IMFDeviceTransform
La interfaz IMFDeviceTransform se define para interactuar con la MFT de dispositivos. Esta interfaz facilita la gestión de m entradasa y n salidas de la MFT de dispositivos. Junto con otras interfaces, la MFT de dispositivos debe implementar esta interfaz.
Propagación de eventos generales
Cuando se produce un evento en Devproxy (o dentro del dispositivo), es necesario propagarlo a la MFT de dispositivos y a DeviceSource.
Requisitos de una MFT de dispositivos
Requisitos de la interfaz
Las MFT de dispositivos deben admitir las interfaces siguientes:
-
Esta interfaz permite que todas las ksproperties, eventos y métodos pasen por la MFT de dispositivos. Esto proporciona a la MFT de dispositivos la capacidad de controlar estas llamadas de funciones dentro de la MFT de dispositivos o simplemente reenviarlas al controlador. En el caso de que controle los métodos KsEvent, la MFT de dispositivos realizará los pasos siguientes:
Si la MFT de dispositivos controla cualquier evento KSEVENT_TYPE_ONESHOT, entonces 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 la MFT de dispositivos 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 (ID de evento KS) y el segundo parámetro (longitud del evento) establecidos 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 la MFT de dispositivos controla eventos que no son de KSEVENT_TYPE_ONESHOT, debe duplicar el identificador cuando recibe KSEVENT_TYPE_ENABLE y debe llamar a CloseHandle en los identificadores duplicados cuando los eventos KS estén deshabilitados llamando a la función KsEvent con todos los parámetros establecidos en cero.
Requisitos de notificación
Las MFT de dispositivos deben usar los siguientes mensajes para informar a DTM sobre la disponibilidad de muestras, cualquier cambio en el estado de la secuencia de entrada, etc.
Requisitos de subprocesos
La MFT de dispositivo 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. Con esta acción se garantiza que todos los subprocesos que se ejecutan en la MFT de dispositivos obtengan la prioridad correcta en la que se ejecuta la canalización de captura y evitar inversiones de prioridad de subprocesos.
Requisitos de InputStream
Recuento de secuencias
- El número de secuencias de entrada en la MFT de dispositivos debe ser el mismo que el número de secuencias admitidas por el controlador.
MediaTypes
La cantidad de tipos de medios y los tipos de medios reales admitidos por la entrada de la MFT de dispositivos deben coincidir con la cantidad y los tipos de tipos de medios admitidos por el controlador.
La cantidad podría ser diferente solo si los tipos de medios admitidos por la entrada de la MFT de dispositivos son un subconjunto de los tipos de medios admitidos por el controlador.
Los tipos de medios admitidos por el controlador y la entrada de la MFT de dispositivos podrían ser tipos de medios estándar o personalizados.
Registro de la MFT de dispositivos
El dispositivo de cámara INF debe tener la siguiente entrada de interfaz de dispositivo que especifica el CLSID de la CoClass de la MFT de dispositivos.
[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 de registro:
Nota:
Este es solo un ejemplo (no la clave de registro real)
[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 una MFT de dispositivos
MFT de dispositivos es el mecanismo de complemento de modo de usuario recomendado para IHV y OEM para ampliar la funcionalidad de la cámara en Windows.
Antes de Windows 10, versión 1703, la canalización de la cámara solo admitía un complemento de extensión DMFT.
A partir de Windows 10, versión 1703, la canalización de la 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 la 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 IHD aporten un valor añadido en forma de secuencias de cámara posteriores al procesamiento. Por ejemplo, un dispositivo podría usar PDMFT junto con un IHV DMFT y un DMFT OEM.
La siguiente figura ilustra la arquitectura que involucra una cadena de DMFT.
Las muestras de captura fluyen desde el controlador de la cámara a DevProxy y luego pasan por las cadenas DMFT. Cada DMFT de la cadena tiene la oportunidad de procesar la muestra. Si DMFT no procesa la muestra, puede actuar como un intermediarios y simplemente pasar la muestra al siguiente DMFT.
En el caso de los controles como KsProperty, la llamada se realiza en sentido ascendente: el último DMFT de la cadena recibe la llamada primero. La llamada se puede controlar allí o pasar 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 alguno de los DMFT no puede crear una instancia, se trata de un error irrecuperable para DTM.
Requisitos de DMFT:
El número de pines de entrada de DMFT debe coincidir con el número de pines de salida del DMFT anterior. De lo contrario, DTM produciría un error durante la inicialización. Sin embargo, no es necesario que los recuentos de pines de entrada y salida del mismo DMFT coincidan.
DMFT debe admitir interfaces: IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl y IMFMediaEventGenerator; es posible que sea necesario admitir IMFTransform si hay un MFT0 configurado o si el siguiente DMFT en la cadena requiere compatibilidad con IMFTransform
En sistemas de 64 bits que no usan Frame Server, se deben registrar dmFT de 32 y 64 bits. Dado que una cámara USB se puede conectar a un sistema arbitrario, para las cámaras USB "externas" (o que no vienen en la bandeja de entrada), el proveedor de cámaras USB debe proporcionar DMFT de 32 y 64 bits.
Configuración de la cadena DMFT
Un dispositivo de cámara puede proporcionar opcionalmente un objeto COM DMFT en un 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 de registro:
CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%
Como se muestra en la configuración INF de ejemplo siguiente (reemplace %Dmft0.CLSID% y % Dmft1.CLSID% con las cadenas CLSID reales que está usando para sus DMFT), hay un máximo de 2 CLSID permitidos en Windows 10, versión 1703 y el primero es más cercano a DevProxy y el último es el último DMFT en la cadena.
El CLSID del DMFT de plataforma es {3D096DDE-8971-4AD5-98F9-C74F56492630}.
Algunos ejemplos de configuración de CameraDeviceMftCLSIDChain:
Sin IHV/OEM DMFT o DMFT de plataforma
- CameraDeviceMftCLSIDChain = "" (o no es necesario especificar esta entrada de registro)
IHV/OEM DMFT
- CameraDeviceMftCLSIDChain = %Dmft.CLSID%
DMFT de plataforma <-> 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 DMFT de plataforma y un DMFT (con GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) en la cadena.
IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Nota:
El CameraDeviceMftCLSIDChain puede tener un máximo de 2 CLSID.
Si CameraDeviceMftCLSIDChain está configurado, DTM omite la configuración de CameraDeviceMftCLSID settings heredada.
Si CameraDeviceMftCLSIDChain no está configurado y el CameraDeviceMftCLSID heredado está configurado, la cadena tendría el aspecto DevProxy <–> DMFT de plataforma <–> OEM/IHV DMFT (si su cámara es USB y compatible con el DMFT de plataforma y el DMFT de plataforma está habilitado) o bien, DevProxy <-> OEM/IHV DMFT (si la cámara no es complatible con el DMFT de plataforma o el DMFT de plataforma está deshabilitado).
Ejemplo de configuración de un archivo INF:
[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%
Registro de objetos COM y de MFT de una MFT de dispositivos
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 de registro globales, preservando así el aislamiento del paquete de controladores. Los MFT también se registran en la clave del dispositivo por motivos similares.
Cambios en el controlador INF
Tras la instalación del controlador del dispositivo, el INF ahora debe realizar 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
| Antes | Después |
|---|---|
| AddReg de INF: HKCR, MediaFoundation\Transforms\{clsid}\... |
Software de dispositivo por instancia AddReg de INF: HKR, MediaFoundation\Transforms\{clsid}\... |
| Ubicación del registro: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Ubicaciones del registro: software key\MediaFoundation\Transforms\{clsid}\... |
Registros COM
En Windows 26100 y versiones posteriores, todos los registro COM para los MFT de dispositivos 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 la MFT de dispositivos usaban AddReg para instalar manualmente la clase COM.
| Antes | Después |
|---|---|
| AddReg de INF: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Software de dispositivo por instancia AddReg de INF: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\... |
La sintaxis INF para diferenciar según la versión del sistema operativo se puede encontrar en Combinación de extensiones de plataforma con versiones del sistema operativo. A partir de Windows 11 25300, INF debe ajustarse a estas nuevas claves de registro. Las versiones anteriores del sistema operativo utilizan las claves de registro tradicionales para mayor compatibilidad. INF debe configurar estas claves de registro en la ubicación anterior en compilaciones de sistemas operativos más antiguos y crear las nuevas claves en su nueva ubicación para compilaciones más recientes de sistemas operativos. Por ejemplo, para un registro MFT en una compilación más antigua, INF crea la clave bajo la siguiente entrada de registro:
HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\
Para un registro MFT en una nueva compilación, INF crea la clave en la siguiente entrada de registro:
**software key**\MediaFoundation\Transforms\{clsid}\
Esta entrada define dónde software key representa la clave de software de un dispositivo.
Para obtener más información, consulte Cómo abrir la clave de software de un dispositivo.
Aquí se muestra un ejemplo de sintaxis de destino de diferentes versiones del sistema operativo:
[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