Guida alla progettazione MFT del dispositivo
Lo stack di acquisizione video in Windows supporta un'estensione in modalità utente sotto forma di DMFT. Si tratta di un componente di estensione per dispositivo fornito da IHV e che la pipeline di acquisizione inserisce come prima trasformazione, post-acquisizione. Il dmft riceve fotogrammi post-elaborati dal dispositivo. Ulteriori operazioni di post-elaborazione sui fotogrammi possono essere eseguite all'interno del DMFT. Il dmft può ricevere fotogrammi da tutti i flussi del dispositivo e può esporre qualsiasi numero di flussi di output in base alle esigenze.
Questo articolo descrive la progettazione di un'estensione a livello di dispositivo in esecuzione in modalità utente che può essere usata per eseguire la post-elaborazione comune a tutti i flussi.
Terminologia
| Termine | Descrizione |
|---|---|
| KS | Driver di streaming del kernel |
| AVStream | Modello di driver di streaming video audio |
| Filtro | Oggetto che rappresenta un'istanza del dispositivo |
| MFT dispositivo | Estensione del driver di acquisizione in modalità utente fornita da IHV |
| Devproxy | MF <-> Marshaler AVStream |
| DTM | Device Transform Manager che gestisce devproxy e Device MFT. Rappresenta il dispositivo nella pipeline MF. |
Obiettivi di progettazione
Estensione in modalità utente a livello di filtro del dispositivo con la stessa durata del filtro del dispositivo
Supporta qualsiasi numero di input provenienti dal dispositivo
Supporta un numero qualsiasi di output (il requisito corrente è costituito da tre flussi: anteprima, record e foto)
Indirizza tutti i controlli del dispositivo a Device MFT (che facoltativamente gestisce o passa al dispositivo)
Post-elaborazione parallela del flusso acquisito
Consenti elaborazione 3A indipendente dalla frequenza dei fotogrammi
Consentire la condivisione dei metadati da un flusso tra altri flussi
Accesso alle risorse GPU
Accesso alle code di lavoro MMCSS MF
Accesso all'allocatore MF
Interfaccia semplice (simile a MFT)
Architettura interna flessibile per l'estendibilità IHV/OEM
Vincoli di progettazione
Nessuna modifica nell'area dell'API di acquisizione
Completare la compatibilità con le versioni precedenti. Ad esempio, nessuna regressione durante l'uso di app e scenari legacy.
Architettura dello stack di acquisizione
Questo articolo descrive il supporto per un'estensione in modalità utente a livello di filtro per il driver di acquisizione. Questo componente ha accesso alle API MF, ai pool di thread, alle risorse GPU e ISP. L'estensione a livello di filtro offre la flessibilità di avere un numero qualsiasi di flussi tra se stesso e il filtro Ks del dispositivo. Questa flessibilità consente una comunicazione fuori banda tra l'estensione in modalità utente e il driver che possono essere usati per i metadati dedicati e i flussi di elaborazione 3A.
Device Transform Manager (DTM)
Lo stack di acquisizione introduce un nuovo componente fornito dal sistema, Device Transform Manager (DTM). Questo si trova all'interno di DeviceSource e gestisce Devproxy MFT e Device MFT. DTM esegue la negoziazione MediaType, la propagazione dei campioni e tutta la gestione degli eventi MFT. Espone inoltre l'interfaccia IMFTransform a DeviceSource e ad altre interfacce private necessarie che DeviceSource deve gestire i flussi dei dispositivi. Questo componente astrae Devproxy e Device MFT dalla pipeline. La pipeline vede semplicemente il DTM come dispositivo e i flussi fuori dal DTM come flussi del dispositivo.
Devproxy
Devproxy è un MFT asincrono che effettua il marshalling dei comandi e dei fotogrammi video tra il driver della fotocamera AVStream e Media Foundation. Viene fornito da Windows e supporta n numero di output dal driver della fotocamera. Inoltre, possiede gli allocatori per tutti i pin esposti dal dispositivo.
MFT dispositivo
Device MFT è un'estensione in modalità utente per il driver di acquisizione. È un m x n MFT asincrono. Viene installato nel sistema con il driver di acquisizione e viene fornito dal fornitore del driver di acquisizione.
Il numero di flussi di input di Device MFT deve essere uguale al numero di pin K esposti dal dispositivo. I mediatipi supportati dai flussi di input di Device MFT devono essere uguali ai mediatype esposti dai pin KS.
Il numero di flussi di output esposti da Device MFT sono i flussi visualizzati da DeviceSource e dallo stack di acquisizione, dall'API di acquisizione e dalle applicazioni e possono essere uno, due o tre flussi. I conteggi dei flussi di input e output di Device MFT non devono essere uguali. Inoltre, i flussi di input e di output non devono avere gli stessi tipi di supporto e in genere hanno tipi di supporto diversi. Il numero di mediatipi non deve corrispondere.
Il primo pin Ks rappresentato in modalità utente dal flusso di output di Devproxy viene associato al primo flusso di input di Device MFT, il secondo pin Ks rappresentato in modalità utente dal flusso di output di Devproxy con il secondo flusso di input di Device MFT e così via.
Al dispositivo MFT viene assegnato un puntatore a Devproxy, dispositivo DX e MF WorkQueue ID. I frame che escono dal dispositivo vengono inseriti direttamente nell'input MFT del dispositivo corrispondente come campioni MF. Con tutto questo, Device MFT può pubblicare i campioni acquisiti e fornire campioni all'anteprima, registrare e aggiungere pin fotografici.
Tutti i comandi e i controlli che passano al dispositivo vengono reindirizzati a Device MFT. Il dispositivo MFT gestisce i controlli o li passa al driver tramite Devproxy. In questo modo, la gestione dei comandi viene semplificata dallo stack di driver di acquisizione.
Panoramica funzionale
Durante l'inizializzazione della pipeline di acquisizione, se è presente un MFT del dispositivo, DeviceSource crea un'istanza di DTM. Passa un'istanza di Devproxy che rappresenta il dispositivo alla routine di inizializzazione del DTM. DTM crea device MFT ed esegue convalide di base, ad esempio verifica che il numero di pin di output di Devproxy corrisponda al numero di pin di input di Device MFT, il supporto per le interfacce obbligatorie e così via.
DeviceSource esegue query DTM per ottenere i mediatipi di output supportati. DTM ottiene questo risultato dai pin di output di Device MFT. DeviceSource espone il descrittore di presentazione e il descrittore di flusso in base a queste informazioni alla pipeline di acquisizione.
SourceReader usa i mediatype esposti di DeviceSource e imposta i mediatipi predefiniti in ogni flusso. A sua volta, DeviceSource imposta i mediatipi predefiniti nei flussi di output del DTM. DTM imposta il tipo di supporto nel flusso di output di Device MFT usando il metodo SetOutputStreamState .
Quando viene chiamato SetOutputStreamState , il dispositivo MFT invia un messaggio a DTM per modificare il tipo di mediatipo del flusso di input in base al tipo di mediatipo di output e alle attese selezionati. In risposta a questo messaggio, DTM esegue una query sul tipo di supporto di input preferito per il flusso di input del dispositivo MFT usando GetPreferredInputStreamState. In questo modo viene impostato il tipo di supporto nel flusso di output corrispondente di Devproxy. In caso di esito positivo, DTM imposta lo stesso tipo di supporto sul flusso di input di Device MFT usando SetInputStreamState. Dopo aver ricevuto questa chiamata, Device MFT completa SetOutputStreamState.
CaptureEngine seleziona singoli flussi abilitando flussi specifici in DeviceSource. Questa operazione viene propagata a Device MFT da DTM tramite una chiamata SetOutputStreamState . Il dispositivo MFT inserisce i flussi di output specifici nello stato richiesto. Come accennato in precedenza, il dispositivo MFT notifica anche DTM sui flussi di input necessari che devono essere abilitati. Ciò comporta la propagazione della selezione del flusso in Devproxy. Al termine di questo processo, tutti i flussi necessari, in Devproxy e Device MFT, sono pronti per lo streaming.
SourceReader avvia DeviceSource quando CaptureEngine chiama ReadSample. A sua volta, DeviceSource avvia il DTM inviando MFT_MESSAGE_NOTIFY_BEGIN_STREAMING e MFT_MESSAGE_NOTIFY_START_OF_STREAM messaggi che indicano l'inizio della pipeline. DTM avvia Devproxy e Device MFT propagando MFT_MESSAGE_NOTIFY_BEGIN_STREAMING e MFT_MESSAGE_NOTIFY_START_OF_STREAM messaggi.
Nota
Allocare le risorse necessarie all'avvio dello streaming anziché all'inizializzazione MFT del dispositivo.
DTM chiama SetOutputStreamState negli output di MFT del dispositivo con il parametro dello stato di streaming. Il dispositivo MFT avvia lo streaming in tali flussi di output. DTM avvia lo streaming nei flussi di output Devproxy con set di mediatype valido. Devproxy alloca gli esempi e li recupera dal dispositivo. Questi esempi vengono inseriti nel dispositivo MFT nel pin di input pertinente. Il dispositivo MFT elabora questi esempi e restituisce l'output a DeviceSource. Da DeviceSource, gli esempi passano attraverso SourceReader a CaptureEngine.
CaptureEngine arresta i singoli flussi disabilitando singoli flussi tramite un'interfaccia interna in DeviceSource. Questa operazione viene convertita in un flusso di output specifico che disabilita in Device MFT tramite SetOutputStreamState. A sua volta, il dispositivo MFT può richiedere di disabilitare flussi di input specifici tramite l'evento METransformInputStreamStateChanged . DTM propaga questo valore ai flussi Devproxy corrispondenti.
Purché il dispositivo MFT stesso in stato di streaming, può richiedere a qualsiasi flusso di input di passare a uno qualsiasi dei DeviceStreamState validi. Ad esempio, potrebbe inviarlo a DeviceStreamState_Stop o DeviceStreamState_Run o DeviceStreamState_Pause e così via, senza influire su altri flussi.
Tuttavia, la transizione del flusso di output è controllata dalla pipeline di acquisizione. Ad esempio, l'anteprima, il record e i flussi di foto sono abilitati o disabilitati dalla pipeline di acquisizione. Anche quando gli output sono disabilitati, un flusso di input potrebbe comunque essere in streaming, purché il dispositivo MFT stesso sia in streaming.
Durata del dispositivo MFT
L'MFT del dispositivo viene caricato dopo la creazione del filtro KS. Viene scaricato prima che il filtro KS venga chiuso.
Dal punto di vista della pipeline, quando viene creato DeviceSource, viene creato il dispositivo MFT e quando DeviceSource viene arrestato, il dispositivo MFT viene arrestato in modo sincrono.
Per supportare l'arresto, il dispositivo MFT deve supportare l'interfaccia IMFShutdown . Dopo aver chiamato Device MFT-Shutdown>, qualsiasi altra chiamata dell'interfaccia nel dispositivo MFT deve restituire un errore MF_E_SHUTDOWN.
Tipo di memoria
I fotogrammi possono essere acquisiti in buffer di memoria di sistema o buffer di memoria DX, in base alla preferenza del driver della fotocamera. Qualsiasi buffer esce dal driver della fotocamera viene inserito direttamente in Device MFT per un'ulteriore elaborazione.
Devproxy alloca i buffer in base alle preferenze del driver. È necessario che Il dispositivo MFT usi le API dell'allocatore MF per allocare gli esempi necessari per i pin di output per le trasformazioni non disponibili.
Modifica del tipo di supporto durante lo streaming
I client di SourceReader sono in grado di visualizzare i tipi di supporto esposti dai flussi di output di Device MFT come mediatype supportati in modo nativo. Quando il tipo di supporto nativo viene modificato, SourceReader invia chiamate di notifica del tipo di supporto nel dispositivo MFT tramite DeviceSource. È responsabilità del dispositivo MFT scaricare tutti i campioni in sospeso dalla coda del flusso e passare al nuovo tipo di supporto in tale flusso in modo tempestivo. Se è necessario modificare il tipo di supporto di input, è necessario modificare il tipo di supporto di input corrente in quello. DTM ottiene il mediatype corrente dal flusso di input di Device MFT e lo imposta sui flussi di output di Devproxy e sull'input di Device MFT dopo ogni modifica del tipo di supporto nativo.
Modifica del tipo di supporto di input in MFT del dispositivo
Poiché si tratta di un m x n MFT, possono verificarsi ripercussioni sui mediatipi e sullo stato del pin di streaming di input quando cambiano i tipi di mediatipi o lo stato del pin di streaming di output. In particolare quando si verificano le modifiche seguenti:
Modifiche al tipo di supporto di output
Quando un'applicazione modifica il tipo di supporto nativo, scorre lo stack di acquisizione in Device MFT come modifica del tipo di supporto del pin di output.
Quando cambia il tipo di mediatipo di output, può attivare una modifica del tipo di supporto di input. Si supponga, ad esempio, che tutti i pin di output siano in streaming a 720p. Ciò comporta lo streaming dalla fotocamera a 720p. Si supponga quindi che il flusso di record cambi il tipo di supporto nativo in 1080p. In tal caso, uno dei flussi di input MFT del dispositivo che recuperava i dati nel flusso di record dovrà modificare il relativo tipo di supporto.
Il pin di output è disabilitato
- Quando un'applicazione disabilita uno degli output di Device MFT quando lo stesso input viene condiviso da più output, per l'ottimizzazione, l'input potrebbe dover modificare il tipo di supporto. Ad esempio, se un flusso di output di 1080p si arresta e tutti gli altri flussi, condividendo un input, vengono trasmessi a 720p, il flusso di input deve modificare il tipo di media in 720p per risparmiare potenza e migliorare le prestazioni.
DTM gestisce le notifiche METransformInputStreamStateChanged da Device MFT per modificare il tipo di media e lo stato nell'input MFT del dispositivo e nell'output Devproxy in queste condizioni.
Mediatipi di output preferiti di Device MFT
È consigliabile che il dispositivo MFT producano tipi di supporti di output usando il formato NV12. YUY2 è la prossima migliore alternativa. I tipi di supporti MJPEG e RGB non sono consigliati.
Scarica MFT dispositivo
Sono necessari due tipi di scaricamento durante la gestione di Device MFT:
Scaricamento globale
Scaricamento A livello MFT del dispositivo. Ciò si verifica in genere quando il DTM sta per inviare un messaggio di stop streaming a Device MFT.
Il dispositivo MFT dovrebbe eliminare tutti i campioni dalle code di input e output e restituire in modo sincrono.
Il dispositivo MFT non deve richiedere un nuovo input o inviare una notifica sul nuovo output disponibile.
Scaricamento locale
- Scaricamento specifico del pin di output. Ciò si verifica in genere quando un flusso viene arrestato.
Tutti gli eventi pubblicati prima dello scaricamento vengono eliminati da Device MFT Manager. Dopo lo scaricamento, il dispositivo MFT reimposta il conteggio interno di rilevamento METransformHaveOutput .
Svuotamento del dispositivo MFT
Il dispositivo MFT non riceverà un messaggio di svuotamento separato perché non è necessario svuotare in un'origine di acquisizione in tempo reale.
Trigger foto
In questo modello, invece di inviare il trigger di foto e i trigger della sequenza di foto si avviano e arrestano direttamente al driver, vengono reindirizzati a Device MFT. Il dispositivo MFT gestisce il trigger o lo inoltra al driver della fotocamera in base alle esigenze.
Avvio a caldo
DeviceSource tenta di avviare un flusso di output specifico eseguendo la transizione del flusso allo stato di sospensione. A sua volta, DTM chiama il metodo IMFDeviceTransform::SetOutputStreamState su Device MFT per eseguire la transizione di un flusso di output specifico allo stato di pausa. In questo modo, il flusso di input corrispondente verrà messo in pausa. Questo risultato viene ottenuto da Device MFT richiedendo METransformInputStreamStateChanged a DTM e gestendo il metodo IMFDeviceTransform::SetInputStreamState .
Sequenza di foto variabile
Con questa architettura, la sequenza di foto viene implementata con il driver del dispositivo fotocamera e Device MFT, riducendo notevolmente la complessità del driver del dispositivo fotocamera. I trigger della sequenza di foto di avvio e arresto vengono inviati al dispositivo MFT e gestiscono più facilmente la sequenza di foto.
Conferma foto
Il dispositivo MFT supporta la conferma delle foto tramite l'interfaccia IMFCapturePhotoConfirmation . La pipeline recupera questa interfaccia tramite il metodo IMFGetService::GetService .
Metadati UFX
Devproxy esegue una query sul driver per le dimensioni del buffer dei metadati e alloca la memoria per i metadati. I metadati provenienti dal driver sono ancora impostati da Devproxy nell'esempio. Il dispositivo MFT utilizza i metadati dell'esempio. I metadati possono essere passati con l'esempio tramite il flusso di output o usati per la post-elaborazione.
Con Device MFT che supporta un numero qualsiasi di input, è possibile usare un pin di input dedicato solo per i metadati o per i metadati fuori banda. Il tipo di supporto per questo pin è personalizzato e il driver decide le dimensioni e il numero di buffer.
Questo flusso di metadati viene esposto oltre il DTM. Il flusso può essere inserito nello stato di streaming quando il dispositivo MFT avvia lo streaming. Ad esempio, quando vengono selezionati flussi di output per lo streaming, Il dispositivo MFT può richiedere ATM di avviare uno o più flussi video e anche il flusso di metadati, usando l'evento METransformInputStreamStateChanged .
Nota: non è necessario che il numero di pin di input corrisponda al numero di pin di output in questo modello. Può essere presente un pin separato dedicato per i metadati o 3A.
Gestione eventi DTM (Device Transform Manager)
Gli eventi di Gestione trasformazione dispositivi sono definiti negli articoli di riferimento seguenti:
Interfaccia IMFDeviceTransform
L'interfaccia IMFDeviceTransform è definita per interagire con Device MFT. Questa interfaccia facilita la gestione degli input m e n output MFT del dispositivo. Insieme ad altre interfacce, Device MFT deve implementare questa interfaccia.
Propagazione generale degli eventi
Quando si verifica un evento in Devproxy (o all'interno del dispositivo), è necessario propagarlo a Device MFT e a DeviceSource.
Requisiti MFT del dispositivo
Requisiti dell'interfaccia
I dispositivi MFT devono supportare le interfacce seguenti:
-
In questo modo tutti i metodi, gli eventi e le proprietà ks passano attraverso Il dispositivo MFT. In questo modo, Device MFT può gestire queste chiamate di funzioni all'interno di Device MFT o semplicemente inoltrarle al driver. Nel caso in cui gestisca i metodi KsEvent, il dispositivo MFT deve eseguire le operazioni seguenti:
Se Device MFT gestisce qualsiasi evento KSEVENT_TYPE_ONESHOT , duplica l'handle quando riceve KSEVENT_TYPE_ENABLE.
Al termine dell'impostazione o della generazione dell'evento, chiama CloseHandle nell'handle duplicato.
Se Device MFT gestisce eventi non KSEVENT_TYPE_ONESHOT, deve duplicare l'handle quando riceve KSEVENT_TYPE_ENABLE e chiamare CloseHandle sull'handle duplicato quando l'evento ks viene disabilitato chiamando la funzione KsEvent con il primo parametro (ID evento ks) e il secondo parametro (lunghezza evento) impostato su zero. I dati e la lunghezza dell'evento sono validi. I dati dell'evento identificano in modo univoco un evento ks specifico.
Se Device MFT gestisce eventi non KSEVENT_TYPE_ONESHOT, deve duplicare l'handle quando riceve KSEVENT_TYPE_ENABLE e deve chiamare CloseHandle negli handle duplicati quando gli eventi ks vengono disabilitati chiamando la funzione KsEvent con tutti i parametri impostati su zero.
Requisiti di notifica
Le MFP del dispositivo devono usare i messaggi seguenti per informare DTM sulla disponibilità di campioni, qualsiasi modifica dello stato del flusso di input e così via.
Requisiti dei thread
Il dispositivo MFT non deve creare i propri thread. Deve invece usare le code di lavoro di Media Foundation, allocate in base all'ID passato al DMFT tramite l'interfaccia IMFRealTimeClientEx . Ciò consente di assicurarsi che tutti i thread in esecuzione nel dispositivo MFT ottengano la priorità corretta in corrispondenza della quale la pipeline di acquisizione è in esecuzione ed evitare le inversione con priorità del thread.
Requisiti di InputStream
Conteggio dei flussi
- Il numero di flussi di input in Device MFT deve corrispondere al numero di flussi supportati dal driver.
MediaTypes
Il numero di mediatype e i tipi di supporto effettivi supportati dall'input di Device MFT devono corrispondere al numero e ai tipi di mediatype supportati dal driver.
Il numero può essere diverso solo se i mediatipi supportati dall'input di Device MFT sono un subset dei mediatype supportati dal driver.
I mediatipi supportati dal driver e dall'input di Device MFT possono essere mediatipi standard o personalizzati.
Come registrare il dispositivo MFT
Il dispositivo fotocamera INF deve avere la voce di interfaccia del dispositivo seguente che specifica il CLSID della CoClasse 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%
Queste voci INF comportano l'immissione delle chiavi del Registro di sistema seguenti:
Nota
Questo è solo un esempio (non la chiave di regkey effettiva)
[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 >>>
Concatenamento MFT del dispositivo
Device MFT è il meccanismo di plug-in modalità utente consigliato per IHVs e OEM per estendere la funzionalità della fotocamera in Windows.
Prima di Windows 10, versione 1703, la pipeline della fotocamera supportava un solo plug-in di estensione DMFT.
A partire da Windows 10, versione 1703, la pipeline della fotocamera di Windows supporta una catena facoltativa di DMFT con un massimo di due DMFT.
A partire da Windows 11 versione 22H2, la pipeline della fotocamera di Windows supporta una catena facoltativa di DMFT con un massimo di quattro DMFT.
Ciò garantisce maggiore flessibilità per gli OEM e gli IHD per fornire un componente aggiuntivo di valore sotto forma di flussi di fotocamera post-elaborazione. Ad esempio, un dispositivo può usare PDMFT insieme a un DMFT IHV e a un DMFT OEM.
La figura seguente illustra l'architettura che include una catena di DMFT.
Acquisire i flussi di campioni dal driver della fotocamera a DevProxy, quindi passare attraverso le catene DMFT. Ogni DMFT nella catena ha la possibilità di elaborare l'esempio. Se dmft non vuole elaborare l'esempio, può fungere da pass-through solo per passare l'esempio alla dmft successiva.
Per i controlli come KsProperty, la chiamata aumenta il flusso, ovvero l'ultimo DMFT nella catena ottiene la chiamata per prima. La chiamata può essere gestita lì o passata alla dmft precedente nella catena.
Gli errori vengono propagati da DMFT a DTM e quindi alle applicazioni. Per le DMFT IHV/OEM, qualsiasi dmft non riesce a creare un'istanza di è un errore irreversibile per DTM.
Requisiti per IMFT:
Il numero di pin di input del DMFT deve corrispondere al numero di pin di output del DMFT precedente. In caso contrario, DTM avrà esito negativo durante l'inizializzazione. Tuttavia, i conteggi dei pin di input e output dello stesso DMFT non devono corrispondere.
DMFT deve supportare le interfacce - IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl e IMFMediaEventGenerator; IMFTransform potrebbe dover essere supportato se è configurato MFT0 o il successivo DMFT nella catena richiede il supporto IMFTransform.
Nei sistemi a 64 bit che non usano Frame Server, è necessario registrare sia DMFT a 32 bit che a 64 bit. Dato che una fotocamera USB potrebbe essere collegata a un sistema arbitrario, per le fotocamere USB "esterne" (o non in arrivo), il fornitore della fotocamera USB deve fornire DMFT a 32 bit e a 64 bit.
Configurare la catena DMFT
Un dispositivo fotocamera può facoltativamente fornire un oggetto COM DMFT in una DLL usando un file INF personalizzato che usa sezioni della posta in arrivo USBVideo.INF.
Nell'oggetto personalizzato. La sezione "Interface AddReg" del file INF specificare i CLSID DMFT aggiungendo la voce del Registro di sistema seguente:
CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%
Come illustrato nelle impostazioni INF di esempio seguenti (sostituire %Dmft0.CLSID% e % Dmft1.CLSID% con le stringhe CLSID effettive in uso per i DMFT), sono consentiti al massimo 2 CLSID in Windows 10, versione 1703 e il primo è più vicino a DevProxy e l'ultimo è l'ultimo DMFT nella catena.
Platform DMFT CLSID è {3D096DDE-8971-4AD5-98F9-C74F56492630}.
Alcune impostazioni cameraDeviceMftCLSIDChain di esempio:
Nessun DMFT IHV/OEM o DMFT della piattaforma
- CameraDeviceMftCLSIDChain = "" (o non è necessario specificare questa voce del Registro di sistema)
IHV/OEM DMFT
- CameraDeviceMftCLSIDChain = %Dmft.CLSID%
DMFT <della piattaforma -> DMFT IHV/OEM
CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%
Ecco uno screenshot della chiave del Registro di sistema dei risultati per una fotocamera USB con PLATFORM DMFT e DMFT (con GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) nella catena.
IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Nota
CameraDeviceMftCLSIDChain può avere un massimo di 2 CLSID.
Se CameraDeviceMftCLSIDChain è configurato, le impostazioni legacy CameraDeviceMftCLSID vengono ignorate da DTM.
Se CameraDeviceMftCLSIDChain non è configurato e la legacy CameraDeviceMftCLSID è configurata, la catena sarà simile a (se la fotocamera USB e supportata da Platform DMFT e Platform DMFT è abilitata) DevProxy -> Platform DMFT <-> OEM/IHV DMFT o (se la fotocamera non è supportata dalla piattaforma DMFT o piattaforma DMFT è disabilitata) DevProxy <<-> OEM/IHV DMFT.
Impostazioni di file INF di esempio:
[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%
Oggetto Com e registrazione MFT di dispositivi MFT
Anziché registrare l'oggetto COM driver a livello globale, l'oggetto COM driver viene registrato nella chiave del dispositivo. Ciò consente la registrazione COM MFT dall'interno del contenitore e impedisce la creazione di chiavi globali del Registro di sistema, mantenendo così l'isolamento del pacchetto driver. Le MFP vengono registrate anche con la chiave del dispositivo per motivi simili.
Modifiche apportate al driver INF
Al momento dell'installazione del driver di dispositivo, l'INF deve ora eseguire tutte le registrazioni COM e MFT sotto la chiave del dispositivo. Le registrazioni MFT e COM devono cambiare come illustrato di seguito:
Registrazioni MFT
| Prima | Dopo |
|---|---|
| INF AddReg: HKCR, MediaFoundation\Transforms\{clsid}\... |
Software del dispositivo per istanza INF AddReg: HKR, MediaFoundation\Transforms\{clsid}\... |
| Posizione del Registro di sistema: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Percorsi del Registro di sistema: software key\MediaFoundation\Transforms\{clsid}\... |
Registrazioni COM
In Windows 26100 e versioni successive, tutte le registrazioni COM per dispositivi MFT devono usare le direttive AddComServer/AddComClass in INF. Di seguito è riportato un esempio di sintassi:
[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%
Le versioni precedenti della registrazione COM MFT del dispositivo usavano AddReg per installare manualmente la classe COM.
| Prima | Dopo |
|---|---|
| INF AddReg: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Software del dispositivo per istanza INF AddReg: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\... |
La sintassi INF per la differenziazione basata sulla versione del sistema operativo è disponibile in Combinazione delle estensioni della piattaforma con le versioni del sistema operativo. A partire da Window 11 25300, l'INF deve essere conforme a queste nuove chiavi del Registro di sistema. Le versioni precedenti del sistema operativo usano le chiavi tradizionali del Registro di sistema per la compatibilità. L'INF deve configurare queste chiavi del Registro di sistema nella posizione precedente nelle build precedenti del sistema operativo e creare le nuove chiavi nella nuova posizione per le build più recenti del sistema operativo. Ad esempio, per una registrazione MFT in una build precedente, INF crea la chiave nella voce del Registro di sistema seguente:
HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\
Per una registrazione MFT in una nuova build, INF crea la chiave nella voce del Registro di sistema seguente:
**software key**\MediaFoundation\Transforms\{clsid}\
Questa voce definisce dove la chiave software rappresenta la chiave software di un dispositivo.
Per altre informazioni, vedere Apertura della chiave software di un dispositivo.
Di seguito è riportato un esempio di sintassi per le diverse versioni 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
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per