Guía de diseño de MFT de dispositivos
La pila de capturas 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 suministraN IHV y la canalización de captura se inserta como la primera transformación posterior a la captura. DMFT recibe fotogramas procesados después del dispositivo. Se pueden realizar más operaciones posteriores al procesamiento en los fotogramas dentro de DMFT. DMFT puede recibir fotogramas de todas las secuencias del dispositivo y puede exponer cualquier número de flujos de salida según el requisito.
En este tema se describe el diseño de una extensión para 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
| Término | Descripción |
|---|---|
| KS | Controlador de streaming de kernel |
| Avstream | Modelo de controlador de streaming de vídeo de audio |
| Filtrar | Objeto que representa una instancia de dispositivo |
| MFT del dispositivo | Extensión del controlador de captura en modo de usuario proporcionada por IHD |
| Devproxy | MF <-> Serializador avStream |
| DTM | Administrador de transformaciones de dispositivos que administra devproxy y Device MFT. Representa el dispositivo en la canalización MF. |
Diseño de objetivos
Extensión de modo de usuario de 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 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 MMCSS de MF
Acceso a mf Allocator
Interfaz simple (similar a MFT)
Arquitectura interna flexible para la 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 la pila de captura
En este tema se describe la compatibilidad con una extensión en modo de usuario de filtro para 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 sí mismo 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 puede usar para los metadatos dedicados y los flujos 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). Esto reside dentro de DeviceSource y administra Devproxy MFT y Device MFT. DTM realiza la negociación MediaType, la propagación de muestras y todo el control de eventos 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 los flujos de DTM como flujos de dispositivo.
Devproxy
Devproxy es un MFT asincrónico que serializa los comandos y fotogramas de vídeo entre el controlador de cámara AvStream y Media Foundation. Esto lo proporciona Windows y admite n números de salidas del controlador de cámara. Además, esto posee los asignadores para todos los pines expuestos por el dispositivo.
MFT del dispositivo
Device MFT es una extensión en modo de usuario para el controlador de captura. Es un m x n asincrónico MFT. 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 tipos de medios admitidos por los flujos de entrada de MFT del dispositivo deben ser los mismos que los tipos de medios expuestos por las patillas 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 una, dos o tres secuencias. 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, tendrán diferentes 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 el primer flujo de entrada de Device MFT, el segundo Pin Ks representado 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 dispositivo MFT correspondiente como muestras mf. Con todos ellos, Device MFT puede procesar las muestras capturadas y servir muestras en la vista previa, el registro y las patillas de fotos.
Todos los comandos y controles que van al dispositivo se vuelven a enrutar a Device MFT. El dispositivo MFT controla los controles o los pasa al controlador a través de Devproxy. Esto simplifica el control de comandos mediante la pila de controladores de captura.
Información general funcional
Al inicializar la canalización de captura, si hay un MFT de dispositivo 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 Device MFT y realiza validaciones básicas, por ejemplo, comprueba el número de patillas de salida de Devproxy es igual que el número de patillas de entrada de Device MFT, compatibilidad con interfaces obligatorias, etc.
DeviceSource consulta DTM para obtener los tipos de medios de salida admitidos. DTM obtiene estos de las patillas de salida del dispositivo MFT. DeviceSource expone el Descriptor de presentación y Stream Descriptor 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 MFT de dispositivo mediante el método SetOutputStreamState .
Cuando se llama a SetOutputStreamState , Device MFT envía un mensaje a DTM para cambiar el tipo de medio 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 el flujo de entrada del dispositivo MFT mediante GetPreferredInputStreamState. Esto establece el mediatype en el flujo de salida correspondiente de Devproxy. Si esto se realiza correctamente, DTM establece ese mismo tipo de medio en el flujo de entrada de MFT del dispositivo mediante SetInputStreamState. Después de recibir esta llamada, Device MFT completa SetOutputStreamState.
CaptureEngine selecciona secuencias individuales habilitando secuencias específicas en DeviceSource. DTM propagará esto a Device MFT 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 provoca 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 transmitirse.
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 propagando MFT_MESSAGE_NOTIFY_BEGIN_STREAMING y MFT_MESSAGE_NOTIFY_START_OF_STREAM mensajes.
Nota Asigne los recursos necesarios al iniciar el streaming en lugar de inicializar Device MFT.
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. Estos ejemplos se introducen en el Dispositivo MFT en el pin de entrada correspondiente. El dispositivo 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. Esto se traducirá en un flujo de salida específico que se deshabilita en Device MFT a través de SetOutputStreamState. A su vez, Device MFT puede solicitar la deshabilitación de flujos de entrada específicos a través del evento METransformInputStreamStateChanged . DTM propaga esto a las secuencias Devproxy correspondientes.
Siempre que el propio Device 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 descargará antes de que se cierre el filtro KS.
Desde una perspectiva de canalización, cuando se crea DeviceSource, se crea el MFT del dispositivo y, cuando deviceSource está apagado, 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 de 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. El búfer que salga del controlador de cámara se introduce directamente en el MFT del dispositivo para su posterior procesamiento.
Devproxy asignará los búferes en función de la preferencia del controlador. Es necesario que Device MFT use las API de asignador MF para asignar las muestras necesarias para sus patillas de salida para transformaciones que no están en lugar.
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 medios en esa secuencia de forma 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 de Device MFT y lo establece en los flujos de salida de Devproxy y la entrada del Dispositivo MFT después de cada cambio de tipo multimedia 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 y el cambio de estado de las patillas de streaming de entrada cuando cambia el estado o los tipos de medios del pin de streaming de salida. En concreto, cuando se producen los siguientes cambios:
Cambios de mediatipo de salida
Cuando una aplicación cambia el tipo de medio nativo, pasa en cascada a través de la pila de captura en Device MFT como cambio de mediatipo de 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 todas las patillas de salida se transmiten 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 MFT del dispositivo que estaba capturando datos en 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 MFT del dispositivo 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 un flujo de salida de 1080p se detiene y todos los demás flujos, compartiendo una entrada, se transmiten a 720p, el flujo de entrada debe cambiar su tipo de medio a 720p para ahorrar energía y mejorar el rendimiento.
DTM controla las notificaciones METransformInputStreamStateChanged de Device MFT para cambiar el tipo de medio y el estado en la entrada MFT del dispositivo y la salida Devproxy en estas condiciones.
Tipos de medios de salida preferidos del dispositivo MFT
Se recomienda encarecidamente que el dispositivo MFT produzca con el formato NV12. YUY2 es la siguiente mejor alternativa. No se recomiendan los tipos de medios MJPEG y RGB.
Vaciado del dispositivo MFT
Se necesitan dos tipos de vaciado al administrar Device MFT:
Vaciado global
Vaciado de ancho MFT del dispositivo. Esto suele ocurrir cuando el DTM está a punto de enviar un mensaje de transmisión de detención al dispositivo MFT.
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 nuevas entradas ni enviar notificaciones sobre la nueva salida disponible.
Vaciado local
- Vaciado específico del pin de salida. Esto suele ocurrir cuando se detiene una secuencia.
El Administrador de MFT quita todos los eventos que se publicaron antes del vaciado. 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 el desencadenador de fotos y el inicio de la secuencia de fotos y detener los desencadenadores directamente al controlador, se volverán a enrutar a Device MFT. El dispositivo MFT controlará 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 del dispositivo MFT para realizar la transición de un flujo de salida específico al estado de pausa. Esto da como resultado el flujo de entrada correspondiente que se va a poner 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 device MFT, 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 Device 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 sigue estableciendo metadatos procedentes del controlador en el ejemplo. El dispositivo MFT consume los metadatos del ejemplo. Los metadatos se pueden pasar con el ejemplo a través de su flujo de salida o simplemente se pueden usar 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 estado de streaming cuando device MFT inicia el streaming. Por ejemplo, cuando se seleccionan secuencias de salida para streaming, Device MFT puede solicitar DTM que inicie una o varias secuencias de vídeo, y también la secuencia de metadatos, mediante el evento METransformInputStreamStateChanged .
Nota: No es necesario que el número de patillas de entrada coincida con el número de patillas de salida de este modelo. Puede haber un pin independiente dedicado solo para metadatos o 3A.
Control de eventos de Device Transform Manager (DTM)
Los eventos de Device Transform Manager se definen en los temas de referencia siguientes:
Interfaz IMFDeviceTransform
La interfaz IMFDeviceTransform se define para interactuar con el MFT del dispositivo. Esta interfaz facilita la administración de entradas m y n salida del dispositivo MFT. Junto con otras interfaces, Device MFT debe implementar esta interfaz.
Propagación de eventos generales
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 siguientes interfaces:
-
Esto permite que todas las ksproperties, eventos y métodos pasen por el dispositivo MFT. 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 hacer lo siguiente:
Si Device MFT controla cualquier evento de 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 llama a CloseHandle en el identificador duplicado cuando el evento ks está deshabilitado mediante una llamada a la función KsEvent con el primer parámetro (identificador de evento ks) y el segundo parámetro (longitud del evento) establecido en cero. Los datos y la longitud del evento serán 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 cuando recibe KSEVENT_TYPE_ENABLE y debe llamar a CloseHandle en los identificadores duplicados cuando los eventos ks están deshabilitados mediante una llamada a la función KsEvent con todos los parámetros establecidos en cero.
Requisitos de notificación
Las MFT de dispositivo deben usar los siguientes mensajes para informar a DTM sobre la disponibilidad de las muestras, cualquier cambio de estado de flujo de entrada, etc.
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 pasado a DMFT a través de la interfaz IMFRealTimeClientEx . Esto es para asegurarse de que todos los subprocesos que se ejecutan en device MFT obtienen la prioridad correcta en la que se ejecuta la canalización de captura y evitan las inversiones de prioridad de subproceso.
Requisitos de InputStream
Número de flujos
- El número de flujos de entrada en Device MFT debe ser el mismo que el número de secuencias compatibles con el controlador.
MediaTypes
El número de tipos de medios y los tipos de medios reales admitidos por la entrada del dispositivo MFT deben coincidir con el número y los tipos de mediatipos 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 mediatypes 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.
Para 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%
Las entradas INF anteriores dan lugar a que se escriban las siguientes claves del Registro:
Nota
Este es un ejemplo solo (no la clave regular 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 MFT de dispositivos
Device MFT es el mecanismo de complemento de modo de usuario recomendado para IHV y OEM para ampliar la funcionalidad de 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 y los IHD proporcionen un valor añadido en forma de secuencias de cámara de procesamiento posterior. 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.
Capture el flujo de muestras del controlador de cámara a DevProxy y, a continuación, pase por las cadenas DMFT. Cada DMFT de la cadena tiene la oportunidad de procesar la muestra. Si el DMFT no desea procesar el ejemplo, puede actuar como paso a través simplemente pasar la muestra a la siguiente DMFT.
En el caso de los controles como KsProperty, la llamada aparecerá en secuencia; la última DMFT de la cadena obtendrá primero la llamada, la llamada se puede controlar allí o pasarse a DMFT anterior en la cadena.
Los errores se propagarán de DMFT a DTM y, a continuación, a las aplicaciones. En el caso de dmfts de IHV/OEM, cualquiera de los DMFT no puede crear instancias será un error irrecuperable para DTM.
Requisitos de DMFT:
El recuento de patillas de entrada de DMFT debe coincidir con el recuento de patillas de salida de DMFT anterior; de lo contrario, DTM produciría un error durante la inicialización. Sin embargo, los recuentos de patillas de entrada y salida de la misma DMFT no necesitan coincidir.
DMFT necesita apoyar interfaces - IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl y IMFMediaEventGenerator; Es posible que sea necesario admitir IMFTransform si hay MFT0 configurado o la siguiente DMFT en la cadena requiere soporte técnico 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 podría conectarse a un sistema arbitrario, para cámaras USB "externas" (o no en la bandeja de entrada), el proveedor de la cámara USB debe suministrar DMFTs 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 archivo DLL mediante un archivo INF personalizado que usa secciones de la bandeja de entrada USBVideo.INF.
En el personalizado . La sección "Interface AddReg" del archivo INF especifica 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 inf de ejemplo siguiente (reemplace %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 la primera es más cercana a DevProxy y la última es la última DMFT en la cadena.
El CLSID de DMFT de plataforma es {3D096DDE-8971-4AD5-98F9-C74F56492630}.
Algunos ejemplos de configuración cameraDeviceMftCLSIDChain :
No hay DMFT de IHV/OEM ni DMFT de plataforma
- CameraDeviceMftCLSIDChain = "" (o no es necesario especificar esta entrada del 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 una DMFT (con GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) en la cadena.
IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Nota
CameraDeviceMftCLSIDChain puede tener un máximo de 2 DE CLSID.
Si CameraDeviceMftCLSIDChain está configurado, DTM omitirá la configuración de CameraDeviceMftCLSID heredada.
Si CameraDeviceMftCLSIDChain no está configurado y el CameraDeviceMftCLSID heredado está configurado, la cadena tendría el aspecto (si su cámara USB y 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) DevProxy <-> OEM/IHV DMFT.
Ejemplo de configuración del 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%
Com (objeto) y MFT Registration of Device MFT (Objeto Com) y MFT Registration of Device MFT
En lugar de registrar el objeto COM del controlador globalmente, el objeto COM del controlador ahora se registrará en la clave del dispositivo. Esto permite el registro COM de MFT desde dentro del contenedor y evita la creación de claves del Registro global, lo que conserva el aislamiento del paquete de controladores. Las MFT ahora se registrarán en la clave del dispositivo por motivos similares.
Cambios en el controlador INF
Tras la instalación del controlador de 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 a continuación:
Registros de MFT:
| Antes | Después |
|---|---|
| AddReg de INF: HKCR,MediaFoundation\Transforms\{clsid}\... |
Per-Instance complemento INF de software de dispositivo: HKR,MediaFoundation\Transforms\{clsid}\... |
| Ubicación del Registro: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Ubicaciones del Registro: clave de software\MediaFoundation\Transforms\{clsid}\... |
Registros COM:
| Antes | Después |
|---|---|
| INF AddReg: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Per-Instance complemento INF de software de dispositivo: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\... |
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, INF debe cumplir estas nuevas claves del Registro. Las versiones anteriores del sistema operativo seguirán usando las claves del Registro tradicionales para la compatibilidad. 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 creará la clave en:
HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\
Para un registro de MFT en una nueva compilación, INF creará la clave en:
**software key**\MediaFoundation\Transforms\{clsid}\
Donde clave de software representa la clave de software de un dispositivo. Consulte Apertura de la clave de software de un dispositivo.
A continuación se puede ver 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
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de