Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
Videoinspelningsstacken i Windows stöder ett tillägg i användarläge i form av DMFT. Det här är en tilläggskomponent per enhet som IHV:er tillhandahåller och avbildningspipelinen infogas som den första transformeringskomponenten efter avbildningen. DMFT tar emot efterbearbetade ramar från enheten. Ytterligare efterbearbetningsoperationer av ramarna kan göras i DMFT. DMFT kan ta emot ramar från alla strömmar på enheten och det kan exponera valfritt antal utdataströmmar enligt kravet.
Den här artikeln beskriver utformningen av ett enhetsomfattande tillägg som körs i användarläge och som kan användas för att utföra efterbearbetning som är gemensam för alla strömmar.
Terminologi
| Begrepp | Beskrivning |
|---|---|
| KS | Kernel Streaming-drivrutin |
| AVStream | Drivrutinsmodell för ljudvideoströmning |
| Filtrera | Objekt som representerar en enhetsinstans |
| Enhetens MFT | Tillägg för avbildningsdrivrutiner i användarläge som tillhandahålls av IHV:er |
| Devproxy | MF <–> AVStream Marshaler |
| DTM | Enhetstransformhanteraren som hanterar devproxy och enhets-MFT. Representerar enheten i MF-pipeline. |
Designmål
Tillägg för enhetsfilter i användarläge som har samma livslängd som enhetsfiltret
Stöder valfritt antal indata som kommer från enheten
Stöder ett valfritt antal utgångar (det aktuella kravet är tre strömmar: förhandsvisning, inspelning och foto)
Dirigerar alla enhetskontroller till Device MFT (som eventuellt hanterar eller skickar den till enheten)
Parallell efterbearbetning av insamlad dataström
Tillåt 3A-bearbetning oberoende av bildfrekvens
Tillåt att metadata från en ström delas mellan andra strömmar
Åtkomst till GPU-resurser
Åtkomst till MF MMCSS-arbetsköer
Åtkomst till MF-allokerare
Enkelt gränssnitt (liknar MFT)
Flexibel intern arkitektur för utökningsbarhet för IHV/OEM
Designbegränsningar
Ingen ändring i API-avbildningsytan
Slutför bakåtkompatibiliteten. Till exempel inga regressioner när du arbetar med äldre appar och scenarier.
Stackarkitektur
Den här artikeln beskriver stöd för ett filteromfattande användarlägestillägg till avbildningsdrivrutinen. Den här komponenten har åtkomst till MF-API:er, trådpooler, GPU- och ISP-resurser. Filtertillägg med bred funktionalitet ger flexibiliteten att ha valfritt antal kanaler mellan sig själv och Ks-filtret för enheter. Den här flexibiliteten möjliggör sömlös out-of-band-kommunikation mellan användarlägestillägget och drivrutinen som kan användas för dedikerade metadata och 3A-bearbetningsströmmar.
Enhetstransformeringshanteraren (DTM)
Insamlingsstacken introducerar en ny systembaserad komponent, Device Transform Manager (DTM). Detta finns i DeviceSource och hanterar Devproxy MFT och Device MFT. DTM utför MediaType-förhandlingen, exempelspridningen och all MFT-händelsehantering. Det exponerar också IMFTransform-gränssnittet för DeviceSource och andra nödvändiga privata gränssnitt som DeviceSource behöver för att hantera enhetsströmmar. Den här komponenten abstraherar Devproxy och Device MFT från pipelinen. Pipelinen ser bara DTM som enheten och strömmarna från DTM som enhetsströmmar.
Devproxy
Devproxy är en asynkron MFT som hanterar kommandon och bildrutor mellan AVStream-kameradrivern och Media Foundation. Detta tillhandahålls av Windows och stöder n antal utdata från kameradrivrutinen. Dessutom äger detta allokeringarna för alla stift som exponeras av enheten.
Enhetens MFT
Device MFT är ett användarlägestillägg till capture-drivrutinen. Det är en m x n asynkron MFT. Den installeras på systemet med avbildningsdrivrutinen och tillhandahålls av leverantören av avbildningsdrivrutinen.
Antalet indataströmmar för enhetens MFT måste vara samma som antalet Ks-stift som exponeras av enheten. De mediatyper som stöds av enhetens MFT-indataströmmar måste vara samma som de mediatyper som exponeras av KS-stiften.
Antalet utdataströmmar som exponeras av Device MFT är de strömmar som visas av DeviceSource, insamlingsstacken, insamlings-API:et och applikationer och kan vara en, två eller tre utdataströmmar. Antalet indata- och utdataströmmar för enhet MFT behöver inte vara detsamma. Indata- och utdataströmmar behöver inte heller ha samma mediatyper och har vanligtvis olika mediatyper. Antalet mediatyper behöver inte heller matcha.
Den första KS-pinen som representeras i användarläge av Devproxys utdataström associeras med den första indataströmmen för Device MFT, den andra KS-pinen som representeras i användarläge av Devproxys utdataström med den andra indataströmmen för Device MFT och så vidare.
Enhetens MFT ges en pekare till Devproxy, DX-enhet och MF WorkQueue-ID. Ramar som kommer ut från enheten förs direkt in i motsvarande enhets MFT-indata som MF-sampel. Med alla dessa kan Device MFT publicera de insamlade exemplen och skicka exempel till pins för förhandsgranskning, arkivhandling och foto.
Alla kommandon och kontroller som går till enheten omdirigeras till Enhet MFT. Enhetens MFT hanterar kontrollerna eller skickar dem vidare till drivrutinen via Devproxy. Detta effektiviserar kommandohanteringen av insamlingsdrivrutinsstacken.
Funktionsöversikt
Vid initialiseringen av inspelningspipen, om det finns en Device MFT för enheten, instansierar DeviceSource DTM. Den skickar en instans av Devproxy som representerar enheten till DTM:s initieringsrutin. DTM sammanställer Device MFT och utför grundläggande valideringar, till exempel, verifierar att antalet utdatastift för Devproxy är samma som antalet indatastift för Device MFT, och stöd för obligatoriska gränssnitt och så vidare.
DeviceSource frågar DTM för att hämta de utdatamediatyper som stöds. DTM hämtar detta från enhets-MFT:s utgångsstift. DeviceSource exponerar presentationsbeskrivningen och Stream Descriptor baserat på den här informationen för insamlingspipelinen.
SourceReader använder de exponerade mediatyperna i DeviceSource och anger standardmedietyperna på varje ström. I sin tur anger DeviceSource standardmedietyperna på utdataströmmarna för DTM. DTM anger mediatype på utdataströmmen för device MFT med metoden SetOutputStreamState .
När SetOutputStreamState anropas skickar Device MFT ett meddelande till DTM för att ändra medietypen för indataströmmen baserat på den valda utdatamedietypen och väntetiderna. Som svar på det här meddelandet frågar DTM önskad indatamedietyp för indataströmmen för enhetens MFT med GetPreferredInputStreamState. Detta anger mediatype på motsvarande utdataström för Devproxy. Om det lyckas anger DTM samma mediatyp på enhetens MFT-indataström med SetInputStreamState. När det här samtalet har tagits emot slutför Device MFT SetOutputStreamState.
CaptureEngine väljer enskilda strömmar genom att aktivera specifika strömmar på DeviceSource. Detta sprids till Device MFT by DTM via ett SetOutputStreamState-anrop . Enhetens MFT placerar de specifika utdataströmmarna i det begärda tillståndet. Som nämnts ovan meddelar Device MFT även DTM om nödvändiga indataströmmar som måste aktiveras. Detta resulterar i att DTM sprider strömvalet till Devproxy. I slutet av den här processen är alla nödvändiga strömmar i Devproxy och Device MFT redo att strömmas.
SourceReader startar DeviceSource när CaptureEngine anropar ReadSample. I sin tur startar DeviceSource DTM genom att skicka MFT_MESSAGE_NOTIFY_BEGIN_STREAMING och MFT_MESSAGE_NOTIFY_START_OF_STREAM meddelanden som anger början av pipelinen. DTM startar Devproxy och Device MFT genom att sprida MFT_MESSAGE_NOTIFY_BEGIN_STREAMING och MFT_MESSAGE_NOTIFY_START_OF_STREAM meddelanden.
Anmärkning
Allokera nödvändiga resurser vid start av direktuppspelning i stället för enhets-MFT-initiering.
DTM anropar SetOutputStreamState på enhetens MFT-utdata med parametern för strömningstillstånd. Enhetens MFT börjar streama i dessa utdataströmmar. DTM startar strömningen på Devproxy-utdataströmmarna som har en giltig mediatypkonfiguration. Devproxy allokerar exemplen och hämtar dem från enheten. Dessa prover matas in i enhetens MFT genom relevant anslutningsstift. Device MFT bearbetar dessa exempel och ger utdata till DeviceSource. Från DeviceSource flödar exemplen via SourceReader till CaptureEngine.
CaptureEngine stoppar enskilda strömmar genom att inaktivera enskilda strömmar via ett internt gränssnitt på DeviceSource. Detta översätts till specifik utdataström som inaktiveras på enhetens MFT via SetOutputStreamState. I sin tur kan Device MFT begära att inaktivera specifika indataströmmar via METransformInputStreamStateChanged-händelsen . DTM sprider detta till motsvarande Devproxy-strömmar.
Så länge enhetens MFT är i strömningstillstånd kan den begära att alla indataströmmar övergår till någon av de giltiga DeviceStreamState. Den kan till exempel skicka den till DeviceStreamState_Stop eller DeviceStreamState_Run eller DeviceStreamState_Pause osv. utan att påverka andra strömmar.
Övergången till utdataströmmen styrs dock av inspelningspipan. Till exempel aktiveras eller inaktiveras förhandsgransknings-, inspelnings- och fotoströmmarna av inspelningspipelinen. Även när utdata är inaktiverade kan en indataström fortfarande strömmas så länge själva enhetens MFT är i strömningstillstånd.
Livslängd för enhetens MFT
Enhetens MFT läses in efter att KS-filtret har skapats. Den avlastas innan KS-filtret stängs.
Ur ett pipelineperspektiv, när DeviceSource skapas, skapas MFT-enheten och när DeviceSource stängs av, stängs MFT-enheten av synkront.
För att stödja avstängning måste device MFT stödja IMFShutdown-gränssnittet . När MFT-avstängning> av enheten anropas måste alla andra gränssnittsanrop till enhetens MFT returnera ett MF_E_SHUTDOWN fel.
Minnestyp
Ramar kan samlas in i systemminnesbuffertar, eller DX-minnesbuffertar, enligt kameradrivrutinens önskemål. Vilken buffert som än kommer ut ur kameradrivrutinen matas direkt in i enhetens MFT för vidare bearbetning.
Devproxy allokerar buffertarna baserat på drivrutinens inställningar. Vi kräver att Device MFT använder MF-allokerings-API:er för att allokera de prover som behövs för dess utgångsstift för icke-lokala transformationer.
Mediatype-ändring vid direktuppspelning
Klienter i SourceReader kan se medietyperna som exponeras av enhetens MFT-utdataströmmar som mediatyper som stöds internt. När den inbyggda mediatypen ändras skickar SourceReader mediatype-meddelandeanrop till Device MFT via DeviceSource. Det är enhetens MFT:s ansvar att rensa alla väntande exempel från dataströmmens kö och växla till den nya mediatypen på strömmen i tid. Om det är nödvändigt att ändra indatamediets typ bör den aktuella indatamedietypen ändras till den. DTM hämtar den aktuella mediatypen från indataströmmen för enhetens MFT och anger den på Devproxys utdataströmmar och enhetens MFT-indata efter varje intern mediatypändring.
Ändring av indatamediatyp i enhetens MFT
Eftersom detta är en m x n MFT kan det uppstå återverkningar på indataströmningsstiftets mediatyper och tillståndsändringar när utdataströmningsstiftets mediatyper eller tillstånd ändras. Specifikt när följande ändringar inträffar:
Mediatype-ändringar för utdata
När ett program ändrar den inbyggda mediatypen överförs det genom insamlingsstacken till Enhets-MFT när mediatypen för utdatastift ändras.
När medietypen för utdata ändras kan den utlösa en ändring av indatamediet. Anta till exempel att alla utgångsstift streamar vid 720p. Detta resulterar i strömning från kameran på 720p. Anta sedan att inspelningsströmmen ändrar sin ursprungliga mediatyp till 1080p. I så fall skulle en av enhetens Device MFT-indataströmmar som hämtade data till inspelningsströmmen behöva ändra sin mediatyp.
Utdatastiftet är inaktiverat
- När ett program inaktiverar en av Device MFT:s utgångar, när samma ingång delas av fler än en utgång, kan ingången behöva ändra medietypen för optimering. Om till exempel en 1080p-utdataström stoppas och alla andra strömmar, som delar en indata, strömmar på 720p, bör indataströmmen ändra sin mediatyp till 720p för att spara ström och förbättra prestandan.
DTM hanterar METransformInputStreamStateChanged-meddelanden från Device MFT för att ändra mediatype och tillstånd för MFT-indata och Devproxy-utdata under dessa förhållanden.
Önskade utdatamedietyper för enhetens MFT
Vi rekommenderar att enhetens MFT skapar utdatamedietyper med NV12-format. YUY2 är det näst bästa alternativet. MJPEG- och RGB-medietyper rekommenderas inte.
Rensa enhetens MFT
Två typer av tömning krävs vid hantering av enhetens MFT:
Global rensning
Enhetens MFT-omfattande rensning. Detta inträffar vanligtvis när DTM är på väg att skicka ett stoppströmningsmeddelande till Device MFT.
Enhetens MFT förväntas släppa alla dataexemplar från sina indata- och utdataköer och återgå synkront.
Enhetens MFT bör inte be om nya indata eller skicka meddelanden om nya tillgängliga utdata.
Lokal tömning
- Pin-specifik rensning av utdata. Detta inträffar vanligtvis när en ström stoppas.
Alla händelser som har publicerats före tömning tas bort av Device MFT Manager. Efter tömningen återställer Enhetens MFT sitt interna METransformHaveOutput-spårningsantal .
Dränering av enhetens MFT
Enhetens MFT får inget separat avloppsmeddelande eftersom det inte finns något behov av avlopp i en live-avbildningskälla.
Fotoutlösare
I den här modellen omdirigeras fotoutlösaren och fotosekvensens start- och stopputlösare till Enhet MFT i stället för att skickas direkt till drivrutinen. Enhetens MFT hanterar utlösaren eller vidarebefordrar den till kameradrivrutinen efter behov.
Varm start
DeviceSource försöker värmestarta en specifik utdataström genom övergång till paustillstånd. DTM anropar i sin tur metoden IMFDeviceTransform::SetOutputStreamState på Device MFT för att överföra en specifik utdataström till paustillståndet. Detta resulterar i motsvarande indataström som ska pausas. Detta uppnås av Device MFT genom att begära METransformInputStreamStateChanged till DTM och hantera metoden IMFDeviceTransform::SetInputStreamState .
Variabel fotosekvens
Med den här arkitekturen implementeras fotosekvensen med kameraenhetens drivrutin och Enhetens MFT, vilket avsevärt minskar komplexiteten hos kameraenhetens drivrutin. Start- och stoppfotosekvensutlösarna skickas till Enhet MFT för att hantera fotosekvensen på ett enklare sätt.
Fotobekräftelse
Device MFT stöder fotobekräftelse via IMFCapturePhotoConfirmation-gränssnittet . Pipelinen hämtar det här gränssnittet via metoden IMFGetService::GetService.
Metainformation
Devproxy frågar drivrutinen efter metadatabuffertstorlek och allokerar minnet för metadata. Metadata som kommer från föraren anges av Devproxy på provet. Enhetens MFT förbrukar exemplets metadata. Metadata kan antingen skickas vidare med exemplet via utdataströmmen eller användas för dess efterbearbetning.
Med Device MFT som stöder valfritt antal indata kan en dedikerad pin-kod för indata användas bara för metadata eller out-of-band-metadata. Mediatypen för denna pin är anpassad och föraren bestämmer storleken och antalet buffertar.
Den här metadataströmmen exponeras bortom DTM. Strömmen kan sättas i strömningstillstånd när enhetens MFT börjar strömma. När utdataströmmar till exempel väljs för direktuppspelning kan enhetens MFT begära att DTM startar en eller flera videoströmmar samt metadataströmmarna med hjälp av händelsen METransformInputStreamStateChanged.
Obs! Det finns inget krav på att antalet indatastift ska matcha antalet utdatastift i den här modellen. Det kan finnas en separat pin-kod som är dedikerad för metadata eller 3A.
Händelsehantering i Enhetstransformeringshanteraren (DTM)
Händelser för Enhetstransformeringshanteraren definieras i följande referensartiklar:
IMFDeviceTransform-gränssnitt
ImfDeviceTransform-gränssnittet definieras för att interagera med Device MFT. Det här gränssnittet underlättar hanteringen av m-indata och n utdataenhets-MFT. Tillsammans med andra gränssnitt måste Device MFT implementera det här gränssnittet.
Allmän händelsespridning
När en händelse inträffar i Devproxy (eller inuti enheten) måste vi sprida den till enhetens MFT och till DeviceSource.
MFT-krav för enhet
Gränssnittskrav
Enhetens MMFT måste ha stöd för följande gränssnitt:
-
Detta tillåter att alla ks-egenskaper, händelser och metoder går igenom enhetens MFT. Detta ger Device MFT möjlighet att hantera dessa funktionsanrop inne i enhetens MFT eller vidarebefordra dem till drivrutinen. Om den hanterar KsEvent-metoderna måste enhetens MFT utföra följande steg:
Om Device MFT hanterar en KSEVENT_TYPE_ONESHOT-händelse, duplicerar den handtaget när den tar emot KSEVENT_TYPE_ENABLE.
När det har slutat ställa in eller trigga händelsen, anropas funktionen CloseHandle på den duplicerade handtaget.
Om enhetens MFT hanterar icke-KSEVENT_TYPE_ONESHOT händelser bör den duplicera handtaget när det tar emot KSEVENT_TYPE_ENABLE och anropa CloseHandle på det duplicerade handtaget när ks-händelsen inaktiveras genom att anropa funktionen KsEvent med den första parametern (ks-händelse-ID) och den andra parametern (händelselängd) inställd på noll. Händelsedata och längd är giltiga. Händelsedata identifierar unikt en specifik ks-händelse.
Om enhetens MFT hanterar icke-KSEVENT_TYPE_ONESHOT händelser bör den duplicera handtaget när det tar emot KSEVENT_TYPE_ENABLE och anropa CloseHandle på de duplicerade handtagen när ks-händelserna inaktiveras genom att anropa funktionen KsEvent med alla parametrar inställda på noll.
Meddelandekrav
Enhetens MMFT måste använda följande meddelanden för att informera DTM om tillgängligheten för exempel, eventuella ändringar av indataströmmens tillstånd och så vidare.
Trådkrav
Enhetens MFT får inte skapa egna trådar. I stället måste den använda Media Foundation Work Queues, som allokeras baserat på det ID som skickas till DMFT via IMFRealTimeClientEx-gränssnittet . Detta är för att se till att alla trådar som körs i enhetens MFT får rätt prioritet där avbildningspipelinen körs och undviker inversioner av trådprioritet.
Krav för InputStream
Antal dataströmmar
- Antalet indataströmmar i Enhetens MFT måste vara detsamma som antalet strömmar som stöds av drivrutinen.
Medietyper
Antalet mediatyper och de faktiska medietyper som stöds av enhetens MFT-indata måste matcha antalet och typerna av mediatyper som stöds av drivrutinen.
Talet kan bara skilja sig om de mediatyper som stöds av indata från Device MFT är en delmängd av de mediatyper som stöds av drivrutinen.
Mediatyper som stöds av drivrutinen och inmatningen för Device MFT kan vara standard eller anpassade mediatyper.
Så här registrerar du enhetens MFT
Kameraenhetens INF-fil måste ha följande post i enhetsgränssnittet som anger CLSID för CoClass för enhetens 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%
Dessa INF-poster resulterar i att följande registernycklar anges:
Anmärkning
Detta är bara ett exempel (inte den faktiska regkey)
[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 >>>
Enhets-MFT-kedja
Device MFT är den rekommenderade mekanismen för användarplugins som IHVs och OEM-tillverkare kan använda för att förbättra kamerans funktioner i Windows.
Före Windows 10 version 1703 stödde kamerapipelinen endast ett insticksprogram för DMFT-tillägg.
Från och med Windows 10, version 1703, stöder Windows-kamerapipelinen en valfri kedja av DMFT:er med högst två DMFT:er.
Från och med Windows 11, version 22H2, stöder Windows-kamerapipelinen en valfri kedja av DMFT:er med högst fyra DMFT:er.
Detta ger större flexibilitet för OEM-tillverkare och IHV:er att tillhandahålla mervärde i form av kameraströmmar efter bearbetning. En enhet kan till exempel använda PDMFT tillsammans med en IHV DMFT och en OEM DMFT.
Följande bild illustrerar arkitekturen med en kedja av DMFTs.
Avbilda exempelflödet från kameradrivrutinen till DevProxy och gå sedan igenom DMFT-kedjorna. Varje DMFT i kedjan har en chans att bearbeta exemplet. Om DMFT inte vill bearbeta provet kan det fungera som en pass-through och bara vidarebefordra provet till nästa DMFT.
För kontroller som KsProperty går anropet uppströms – den sista DMFT i kedjan får anropet först. Samtalet kan hanteras där eller skickas till tidigare DMFT i kedjan.
Fel sprids från DMFT till DTM och sedan till program. För IHV/OEM DMFTs är det ett allvarligt fel för DTM om någon av DMFT:erna misslyckas med att instansiera.
Krav på DMFT:ar:
Antalet indatastift för DMFT måste matcha antalet utdatastift för tidigare DMFT. Annars skulle DTM misslyckas under initieringen. Antalet pin-koder för in- och utdata för samma DMFT behöver dock inte matcha.
DMFT måste stödja gränssnitt – IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl och IMFMediaEventGenerator; IMFTransform kan behöva stödjas om MFT0 har konfigurerats eller om nästa DMFT i kedjan kräver IMFTransform-stöd.
På 64-bitarssystem som inte använder Frame Server måste både 32- och 64-bitars DMFT registreras. Med tanke på att en USB-kamera kan anslutas till valfritt system, för "externa" (eller tredjeparts) USB-kameror, bör USB-kameraleverantören tillhandahålla både 32-bitars och 64-bitars DMFT.
Konfigurera DMFT-kedjan
En kameraenhet kan också ange ett DMFT COM-objekt i en DLL med hjälp av en anpassad INF-fil som använder delar av inkorgen USBVideo.INF.
I den anpassade .INF-filens avsnitt "Interface AddReg" anger du DMFT CLSID:erna genom att lägga till följande registerposten:
CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft. CLSID%,%Dmft2.CLSID%
Som du ser i inf-exempelinställningarna nedan (ersätt %Dmft0.CLSID-% och % Dmft1.CLSID-% med de faktiska CLSID-strängarna som du använder för dina DMFT: er), finns det högst 2 CLSID:er tillåtna i Windows 10, version 1703, och den första är närmast DevProxy och den sista är den sista DMFT:en i kedjan.
Plattforms-DMFT CLSID är {3D096DDE-8971-4AD5-98F9-C74F56492630}.
Exempel på CameraDeviceMftCLSIDChain-inställningar :
Ingen IHV/OEM DMFT eller plattforms-DMFT
- CameraDeviceMftCLSIDChain = "" (eller inget behov av att ange den här registerposten)
IHV/OEM DMFT
- CameraDeviceMftCLSIDChain = %Dmft.CLSID%
Plattforms-DMFT <–> IHV/OEM DMFT
CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft. CLSID-%
Här är en skärmbild av resultatregisternyckeln för en USB-kamera med Plattform DMFT och en DMFT (med GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) i kedjan.
IHV/OEM DMFT0 <–> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Anmärkning
CameraDeviceMftCLSIDChain kan ha högst 2 CLSIDs.
Om CameraDeviceMftCLSIDChain har konfigurerats, hoppas de äldre inställningarna för CameraDeviceMftCLSID över av DTM.
Om CameraDeviceMftCLSIDChain inte har konfigurerats och den äldre CameraDeviceMftCLSID har konfigurerats, skulle kedjan se ut som (om dess USB-kamera och stöds av Plattform DMFT och Plattform DMFT är aktiverad) DevProxy <–> Plattform DMFT <–> OEM/IHV DMFT eller (om kameran inte stöds av Plattform DMFT eller Plattform DMFT är inaktiverad) DevProxy <–> OEM/IHV DMFT.
Exempel på INF-filinställningar:
[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-objekt och MFT-registrering av enhets-MFT:er
I stället för att registrera COM-drivrutinsobjektet globalt registreras drivrutins-COM-objektet under enhetsnyckeln. Detta tillåter MFT COM-registrering inifrån containern och förhindrar att globala registernycklar skapas, vilket bevarar isolering av drivrutinspaket. MFT registreras också under enhetsnyckeln av liknande anledningar.
Ändringar i drivrutins-INF
Vid installationen av enhetsdrivrutinen måste INF nu göra alla COM-objekt och MFT-registreringar under enhetsnyckeln. MFT- och COM-registreringar måste ändras enligt följande:
MFT-registreringar
| Före | Efter |
|---|---|
| INF AddReg: HKCR, MediaFoundation\Transforms\{clsid}\... |
Per-Instance enhetsprogramvara INF AddReg: HKR, MediaFoundation\Transforms\{clsid}\... |
| Registerplats: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Registerplatser: software key\MediaFoundation\Transforms\{clsid}\... |
COM-registreringar
I Windows 26100 och senare måste alla COM-registreringar för enhets-MFI använda AddComServer/AddComClass-direktiv i INF. Ett syntaxexempel visas här:
[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%
Tidigare versioner av Device MFT COM Registration använde AddReg för att installera COM-klassen manuellt.
| Före | Efter |
|---|---|
| INF AddReg: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Per-Instance enhetsprogramvara INF AddReg: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\... |
INF-syntaxen för differentiering baserat på os-version finns i Kombinera plattformstillägg med operativsystemversioner. Från och med fönster 11 25300 måste INF överensstämma med dessa nya registernycklar. Äldre operativsystemversioner använder de traditionella registernycklarna för kompatibilitet. INF måste konfigurera dessa registernycklar på den gamla platsen i äldre OS-versioner och skapa de nya nycklarna på den nya platsen för nyare OS-versioner. För en MFT-registrering på en äldre version skapar INF till exempel nyckeln under följande registerpost:
HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\
För en MFT-registrering i en ny version skapar INF nyckeln under följande registerpost:
**software key**\MediaFoundation\Transforms\{clsid}\
Den här posten definierar var programvarunyckeln representerar en enhets programvarunyckel.
Mer information finns i Öppna en enhets programvarunyckel.
Ett syntaxexempel på att rikta in sig på olika OS-versioner visas här:
[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