Entwurfshandbuch für Geräte-MFT
Der Videoaufnahmestapel in Windows unterstützt eine Erweiterung des Benutzermodus in Form von DMFT. Dies ist eine Geräteerweiterungskomponente, die IHVs bereitstellen und die Aufnahmepipeline als erste Transformation nach der Aufnahme eingefügt wird. Der DMFT empfängt nach dem Verarbeiten von Frames vom Gerät. Weitere Nachbearbeitungsvorgänge auf den Frames können innerhalb der DMFT durchgeführt werden. Der DMFT kann Frames von allen Datenströmen des Geräts empfangen und kann eine beliebige Anzahl von Ausgabedatenströmen gemäß der Anforderung verfügbar machen.
In diesem Artikel wird der Entwurf einer geräteweiten Erweiterung beschrieben, die im Benutzermodus ausgeführt wird, um die Nachbearbeitung für alle Datenströme durchzuführen.
Begriff
| Begriff | Beschreibung |
|---|---|
| KS | Kernelstreamingtreiber |
| AVStream | Audiovideostreaming-Treibermodell |
| Filter | Objekt, das eine Geräteinstanz darstellt |
| Geräte-MFT | Vom Benutzermodus bereitgestellte Treibererweiterung für den Benutzermodus |
| Devproxy | MF <-> AVStream Marshaler |
| DTM | Device Transform Manager, der devproxy und Device MFT verwaltet. Stellt das Gerät in der MF-Pipeline dar. |
Entwurfsziele
Gerätefilterweite Benutzermoduserweiterung mit der gleichen Lebensdauer wie der Gerätefilter
Unterstützt eine beliebige Anzahl von Eingaben, die vom Gerät stammen
Unterstützt eine beliebige Anzahl von Ausgaben (aktuelle Anforderung ist drei Datenströme: Vorschau, Datensatz und Foto)
Leitet alle Gerätesteuerelemente an Device MFT weiter (optional verarbeitet oder an das Gerät übergeben)
Parallele Nachbearbeitung des erfassten Datenstroms
3A-Verarbeitung unabhängig von der Framerate zulassen
Zulassen, dass Metadaten aus einem Datenstrom für andere Datenströme freigegeben werden
Zugriff auf GPU-Ressourcen
Zugriff auf MF MMCSS-Arbeitswarteschlangen
Zugriff auf MF Allocator
Einfache Schnittstelle (ähnlich wie MFT)
Flexible interne Architektur für die IHV/OEM-Erweiterbarkeit
Entwurfseinschränkungen
Keine Änderung der Aufnahme-API-Oberfläche
Vollständige Abwärtskompatibilität. Beispielsweise keine Regressionen beim Arbeiten mit älteren Apps und Szenarien.
Aufnahmestapelarchitektur
In diesem Artikel wird die Unterstützung für eine filterweite Benutzermoduserweiterung für den Aufnahmetreiber beschrieben. Diese Komponente hat Zugriff auf MF-APIs, Threadpools, GPU und ISP-Ressourcen. Die breite Filtererweiterung bietet die Flexibilität, eine beliebige Anzahl von Datenströmen zwischen sich selbst und dem Geräte-Ks-Filter zu haben. Diese Flexibilität ermöglicht eine nahtlose Out-of-Band-Kommunikation zwischen der Benutzermoduserweiterung und dem Treiber, die für dedizierte Metadaten und 3A-Verarbeitungsdatenströme verwendet werden können.
Gerätetransformations-Manager (DTM)
Der Aufnahmestapel führt eine neue vom System bereitgestellte Komponente ein, den Device Transform Manager (DTM). Dies befindet sich in DeviceSource und verwaltet Devproxy MFT und Device MFT. DTM führt die MediaType-Aushandlung, die Beispielverteilung und die gesamte MFT-Ereignisbehandlung durch. Außerdem wird die IMFTransform-Schnittstelle für DeviceSource und andere erforderliche private Schnittstellen verfügbar gemacht, die DeviceSource zum Verwalten von Gerätedatenströmen benötigt. Diese Komponente abstrahiert Devproxy und Device MFT von der Pipeline. Die Pipeline sieht die DTM nur als Gerät und die Datenströme aus DTM als Datenstrom des Geräts.
Devproxy
Devproxy ist ein asynchroner MFT, der die Befehle und Videoframes zwischen dem AVStream-Kameratreiber und Media Foundation marshallt. Dies wird von Windows bereitgestellt und unterstützt die Anzahl der Ausgaben des Kameratreibers. Außerdem besitzt dies die Allokatoren für alle Pins, die vom Gerät verfügbar gemacht werden.
Geräte-MFT
Device MFT ist eine Erweiterung des Benutzermodus auf den Aufnahmetreiber. Es handelt sich um ein m x n asynchrones MFT. Es ist auf dem System mit dem Aufnahmetreiber installiert und wird vom Anbieter des Aufnahmetreibers bereitgestellt.
Die Anzahl der Eingabedatenströme von Device MFT muss mit der Anzahl der Ks-Pins übereinstimmen, die vom Gerät verfügbar gemacht werden. Die von den Eingabedatenströmen von Device MFT unterstützten Medientypen müssen mit den Medientypen übereinstimmen, die von den KS-Pins verfügbar gemacht werden.
Die Anzahl der ausgabestreams, die von Device MFT verfügbar gemacht werden, sind die Datenströme, die von DeviceSource und Aufnahmestapel, Aufnahme-API und Anwendungen angezeigt werden und können ein, zwei oder drei Datenstrom sein. Die Anzahl der Eingabe- und Ausgabedatenströme von Device MFT muss nicht identisch sein. Außerdem müssen Eingabe- und Ausgabedatenströme nicht über die gleichen Medientypen verfügen und weisen in der Regel unterschiedliche Medientypen auf. Die Anzahl der Medientypen muss nicht übereinstimmen.
Der erste Ks-Pin, der im Benutzermodus durch den Ausgabedatenstrom von Devproxy dargestellt wird, wird dem ersten Eingabedatenstrom von Device MFT zugeordnet, dem zweiten Ks-Pin, der im Benutzermodus durch den Ausgabedatenstrom von Devproxy mit dem zweiten Eingabedatenstrom von Device MFT dargestellt wird usw.
Device MFT erhält einen Zeiger auf Devproxy, DX-Gerät und MF WorkQueue-ID. Frames, die aus dem Gerät kommen, werden direkt in die Eingabe des entsprechenden Geräte-MFT als MF Samples eingespeist. Mit all diesen Daten kann Device MFT die aufgenommenen Beispiele veröffentlichen und Proben an den Vorschau-, Aufzeichnungs- und Foto-Pins bereitstellen.
Alle Befehle und Steuerelemente, die zum Gerät wechseln, werden an Device MFT umgeleitet. Geräte-MFT verarbeitet die Steuerelemente oder über Devproxy an den Treiber weiter. Dadurch wird die Befehlsbehandlung durch den Aufnahmetreiberstapel optimiert.
Übersicht über die Funktionen
Bei der Initialisierung der Aufnahmepipeline instanziiert DeviceSource DTM, wenn ein Device MFT für das Gerät vorhanden ist. Es übergibt eine Instanz von Devproxy, die das Gerät an die Initialisierungsroutine von DTM darstellt. DTM erstellt Geräte-MFT und führt grundlegende Überprüfungen durch, z. B. überprüft, wie viele Ausgabe-Pins von Devproxy mit der Anzahl der Eingabe-Pins von Device MFT, Unterstützung für obligatorische Schnittstellen usw. übereinstimmen.
DeviceSource fragt DTM ab, um die unterstützten Ausgabemedientypen abzurufen. DTM ruft dies aus den Ausgabe-Pins von Device MFT ab. DeviceSource macht den Präsentationsdeskriptor und den Streamdeskriptor basierend auf diesen Informationen für die Aufnahmepipeline verfügbar.
SourceReader verwendet die verfügbar gemachten Medientypen der DeviceSource und legt die Standardmedientypen für jeden Datenstrom fest. DeviceSource legt wiederum die Standardmedientypen für die Ausgabedatenströme der DTM fest. DTM legt den Medientyp für den Ausgabedatenstrom des Device MFT mithilfe der SetOutputStreamState-Methode fest.
Wenn SetOutputStreamState aufgerufen wird, sendet Device MFT eine Nachricht an DTM, um den Medientyp des Eingabedatenstroms basierend auf dem ausgewählten Ausgabemedientyp zu ändern und wartet. Als Reaktion auf diese Meldung fragt DTM den bevorzugten Eingabemedientyp für den Eingabedatenstrom des Geräte-MFT mithilfe von GetPreferredInputStreamState ab. Dadurch wird der Mediatyp für den entsprechenden Ausgabedatenstrom von Devproxy festgelegt. Wenn dies erfolgreich ist, legt DTM denselben Medientyp mithilfe von SetInputStreamState auf den Eingabedatenstrom von Device MFT fest. Nach Erhalt dieses Anrufs schließt Device MFT SetOutputStreamState ab.
CaptureEngine wählt einzelne Datenströme aus, indem bestimmte Datenströme auf DeviceSource aktiviert werden. Dies wird über einen SetOutputStreamState-Aufruf an Device MFT durch DTM weitergegeben. Geräte-MFT platziert die spezifischen Ausgabedatenströme im angeforderten Zustand. Wie bereits erwähnt, benachrichtigt Device MFT auch DTM über die erforderlichen Eingabedatenströme, die aktiviert werden müssen. Dies führt dazu, dass die Datenstromauswahl an Devproxy weitergegeben wird. Am Ende dieses Prozesses sind alle erforderlichen Datenströme in Devproxy und Device MFT bereit zum Streamen.
SourceReader startet deviceSource, wenn CaptureEngine ReadSample aufruft. DeviceSource startet wiederum die DTM, indem MFT_MESSAGE_NOTIFY_BEGIN_STREAMING gesendet und MFT_MESSAGE_NOTIFY_START_OF_STREAM Nachrichten gesendet werden, die den Start der Pipeline angeben. DTM startet Devproxy und Device MFT, indem MFT_MESSAGE_NOTIFY_BEGIN_STREAMING und MFT_MESSAGE_NOTIFY_START_OF_STREAM Nachrichten weitergegeben werden.
Hinweis
Weisen Sie die erforderlichen Ressourcen beim Starten des Streamings anstelle der Device MFT initialize zu.
DTM ruft SetOutputStreamState auf die Ausgaben von Device MFT mit dem Streamingstatusparameter auf. Geräte-MFT startet streaming in diesen Ausgabedatenströmen. DTM startet das Streaming für die Devproxy-Ausgabestreams, die über einen gültigen Medientypsatz verfügen. Devproxy weist die Beispiele zu und ruft sie vom Gerät ab. Diese Beispiele werden in den Geräte-MFT in den relevanten Eingabenadel eingespeist. Geräte-MFT verarbeitet diese Beispiele und gibt die Ausgabe für DeviceSource. Von DeviceSource fließen die Beispiele über SourceReader zu CaptureEngine.
CaptureEngine stoppt einzelne Datenströme, indem einzelne Datenströme über eine interne Schnittstelle auf DeviceSource deaktiviert werden. Dies wird in einen bestimmten Ausgabedatenstrom übersetzt, der auf Device MFT über SetOutputStreamState deaktiviert wird. Device MFT kann wiederum anfordern, bestimmte Eingabedatenströme über DAS METransformInputStreamStateChanged-Ereignis zu deaktivieren. DTM verteilt dies an entsprechende Devproxy-Streams.
Solange sich das Gerät MFT selbst im Streamingzustand befindet, kann er jeden Eingabedatenstrom anfordern, um zu einem der gültigen DeviceStreamState zu wechseln. Beispielsweise könnte sie an DeviceStreamState_Stop oder DeviceStreamState_Run oder DeviceStreamState_Pause usw. gesendet werden, ohne dass sich dies auf andere Datenströme auswirkt.
Der Ausgabedatenstromübergang wird jedoch von der Aufnahmepipeline gesteuert. Beispielsweise werden die Vorschau-, Datensatz- und Fotostreams von der Aufnahmepipeline aktiviert oder deaktiviert. Selbst wenn die Ausgaben deaktiviert sind, könnte ein Eingabedatenstrom weiterhin gestreamt werden, solange sich der Geräte-MFT selbst im Streamingzustand befindet.
Lebensdauer des Geräte-MFT
Das Gerät MFT wird geladen, nachdem der KS-Filter erstellt wurde. Es wird entladen, bevor der KS-Filter geschlossen wird.
Wenn die DeviceSource erstellt wird, wird die Geräte-MFT erstellt, und wenn die DeviceSource heruntergefahren wird, wird die Geräte-MFT synchron heruntergefahren.
Um das Herunterfahren zu unterstützen, muss device MFT die IMFShutdown-Schnittstelle unterstützen. Nachdem gerätebasiertes> Herunterfahren aufgerufen wurde, muss ein anderer Schnittstellenaufruf in device MFT einen MF_E_SHUTDOWN Fehler zurückgeben.
Arbeitsspeichertyp
Frames können in Systemspeicherpuffer oder DX-Speicherpuffern pro Einstellung des Kameratreibers erfasst werden. Welcher Puffer aus dem Kameratreiber stammt, wird zur weiteren Verarbeitung direkt in den Device MFT eingespeist.
Devproxy weist die Puffer basierend auf der Einstellung des Treibers zu. Wir benötigen Device MFT, um MF-Allocator-APIs zu verwenden, um die beispiele zuzuweisen, die für die Ausgabe-Pins für nicht eingefügte Transformationen erforderlich sind.
Medientypänderung beim Streaming
Clients von SourceReader können die Medientypen anzeigen, die von den Ausgabestreams des Geräts MFT als systemeigene unterstützte Medientypen verfügbar gemacht werden. Wenn der systemeigene Medientyp geändert wird, sendet SourceReader Mediatype-Benachrichtigungsaufrufe über DeviceSource an das Gerät MFT. Es liegt in der Verantwortung des Geräte-MFT, alle ausstehenden Beispiele aus der Warteschlange dieses Datenstroms zu leeren und zeitnah zum neuen Medientyp in diesem Stream zu wechseln. Wenn es erforderlich ist, den Eingabemedientyp zu ändern, sollte er den aktuellen Eingabemedientyp in diesen ändern. DTM ruft den aktuellen Medientyp aus dem Eingabedatenstrom des Device MFT ab und legt ihn für die Ausgabedatenströme des Devproxys und die Eingabe des Geräte-MFT nach jeder änderung des systemeigenen Medientyps fest.
Änderung des Eingabemedientyps in Device MFT
Da dies ein m x n MFT ist, kann es Auswirkungen auf die Mediatypen und Zustandsänderungen des Eingabestreaming-Pins geben, wenn sich die Medientypen oder Zustandsänderungen des Ausgabestreaming-Pins ändern. Insbesondere, wenn die folgenden Änderungen vorgenommen werden:
Ausgabemedientypänderungen
Wenn eine Anwendung systemeigene Medientypen ändert, übergibt sie den Aufnahmestapel als Ausgabe-Pin-Medientypänderung in Device MFT.
Wenn sich der Ausgabemedientyp ändert, kann er eine Änderung des Eingabemedientyps auslösen. Nehmen wir beispielsweise an, dass alle Ausgabe-Pins mit 720p gestreamt werden. Dies führt zum Streamen von der Kamera bei 720p. Gehen Sie als Nächstes davon aus, dass der Datensatzdatenstrom seinen nativen Medientyp auf 1080p ändert. In diesem Fall müsste einer der Geräte-MFT-Eingabedatenströme, die Daten aus dem Datensatzdatenstrom abrufen, den Medientyp ändern.
Ausgabenadel ist deaktiviert
- Wenn eine Anwendung eine der Geräte-MFT-Ausgaben deaktiviert, wenn dieselbe Eingabe von mehreren Ausgaben gemeinsam genutzt wird, muss die Eingabe möglicherweise den Medientyp ändern. Wenn beispielsweise ein 1080p-Ausgabedatenstrom beendet wird und alle anderen Datenströme, die eine Eingabe freigeben, mit 720p streamen, sollte der Eingabedatenstrom seinen Medientyp auf 720p ändern, um Energie zu sparen und die Leistung zu verbessern.
DTM verarbeitet METransformInputStreamStateChanged-Benachrichtigungen von Device MFT, um den Medientyp und den Zustand der Geräte-MFT-Eingabe und devproxy-Ausgabe unter diesen Bedingungen zu ändern.
Bevorzugte Ausgabemedientypen von Device MFT
Es wird empfohlen, dass die Geräte-MFT Ausgabemedientypen im NV12-Format erzeugen. YUY2 ist die nächste beste Alternative. MJPEG- und RGB-Medientypen werden nicht empfohlen.
Geräte-MFT leeren
Beim Verwalten von Geräte-MFT sind zwei Arten von Spülungen erforderlich:
Globale Spülung
Geräte-MFT-breite Spülung. Dies geschieht in der Regel, wenn die DTM eine Stoppstreamingnachricht an Device MFT sendet.
Geräte-MFT wird erwartet, dass alle Beispiele aus ihren Eingabe- und Ausgabewarteschlangen abzulegen und synchron zurückgegeben werden.
Geräte-MFT sollte keine neue Eingabe anfordern oder Benachrichtigungen über neue verfügbare Ausgabe senden.
Lokale Spülung
- Ausgabeheftspezifisches Spülen. Dies geschieht in der Regel, wenn ein Datenstrom beendet wird.
Alle Ereignisse, die vor dem Leeren gepostet wurden, werden vom Geräte-MFT-Manager gelöscht. Nach dem Leeren setzt das Gerät MFT die interne METransformHaveOutput-Tracking-Anzahl zurück.
Entwässerung des Geräte-MFT
Geräte-MFT empfängt keine separate Entwässerungsnachricht, da keine Entwässerung in einer Liveaufnahmequelle erforderlich ist.
Fototrigger
In diesem Modell werden sie nicht direkt an den Treiber gesendet, sondern der Fototrigger und die Fotosequenz gestartet und angehalten, sondern an Device MFT umgeleitet. Das Gerät MFT verarbeitet den Auslöser oder leitet ihn bei Bedarf an den Kameratreiber weiter.
Warmstart
DeviceSource versucht, einen bestimmten Ausgabedatenstrom warm zu starten, indem der Datenstrom in den Zustand angehalten wird. Dtm ruft wiederum die IMFDeviceTransform::SetOutputStreamState-Methode auf Device MFT auf, um einen bestimmten Ausgabedatenstrom zum Anhalten des Zustands zu übertragen. Dies führt dazu, dass der entsprechende Eingabedatenstrom angehalten wird. Dies wird durch Device MFT erreicht, indem METransformInputStreamStateChanged an DTM angefordert und die IMFDeviceTransform::SetInputStreamState-Methode verarbeitet wird.
Variable Fotosequenz
Mit dieser Architektur wird die Fotosequenz mit dem Kameragerätetreiber und device MFT implementiert, wodurch die Komplexität des Kameragerätetreibers erheblich reduziert wird. Die Start- und Stopp-Fotosequenztrigger werden an Device MFT gesendet und behandeln die Fotosequenz einfacher.
Fotobestätigung
Das Gerät MFT unterstützt die Fotobestätigung über die IMFCapturePhotoConfirmation-Schnittstelle . Die Pipeline ruft diese Schnittstelle über DIE IMFGetService::GetService-Methode ab.
Metadaten
Devproxy fragt den Treiber nach metadatenpuffergröße ab und weist den Speicher für Metadaten zu. Metadaten, die vom Treiber stammen, werden weiterhin von Devproxy im Beispiel festgelegt. Geräte-MFT verwendet die Metadaten des Beispiels. Metadaten können entweder mit dem Beispiel über den Ausgabedatenstrom übergeben oder für die Nachbearbeitung verwendet werden.
Da Device MFT eine beliebige Anzahl von Eingaben unterstützt, kann eine dedizierte Eingabenadel nur für Metadaten oder Out-of-Band-Metadaten verwendet werden. Der Medientyp für diesen Pin ist benutzerdefiniert, und der Treiber entscheidet über die Größe und Anzahl der Puffer.
Dieser Metadatendatenstrom wird über DTM hinaus verfügbar gemacht. Der Stream kann in den Streamingzustand versetzt werden, wenn Device MFT das Streaming startet. Wenn z. B. Ausgabedatenströme für streaming ausgewählt sind, kann Device MFT DTM anfordern, einen oder mehrere Videostreams zu starten, und den Metadatendatenstrom auch mithilfe des METransformInputStreamStateChanged-Ereignisses .
Hinweis: Es ist nicht erforderlich, dass die Anzahl der Eingabenadeln mit der Anzahl der Ausgabe-Pins in diesem Modell übereinstimmt. Es kann eine separate Pin für Metadaten oder 3A geben.
Behandeln von Ereignissen im Device Transform Manager (DTM)
Device Transform Manager-Ereignisse werden in den folgenden Referenzartikeln definiert:
IMFDeviceTransform-Schnittstelle
Die IMFDeviceTransform-Schnittstelle ist für die Interaktion mit Device MFT definiert. Diese Schnittstelle erleichtert die Verwaltung von M-Eingängen und n-Ausgabegeräte-MFT . Zusammen mit anderen Schnittstellen muss Device MFT diese Schnittstelle implementieren.
Allgemeine Ereignisverteilung
Wenn ein Ereignis in Devproxy (oder innerhalb des Geräts) auftritt, müssen wir dies an das Device MFT und an die DeviceSource weitergeben.
Geräte-MFT-Anforderungen
Schnittstellenanforderungen
Geräte-MFTs müssen die folgenden Schnittstellen unterstützen:
-
Dadurch können alle ksproperties, Ereignisse und Methoden die Geräte-MFT durchlaufen. Dadurch erhält Device MFT die Möglichkeit, diese Funktionsaufrufe innerhalb von Device MFT zu verarbeiten oder einfach an den Treiber weiterzuleiten. In dem Fall, in dem die KsEvent-Methoden behandelt werden, muss device MFT die folgenden Schritte ausführen:
Wenn Device MFT ein beliebiges KSEVENT_TYPE_ONESHOT-Ereignis behandelt, dupliziert es das Handle, wenn es KSEVENT_TYPE_ENABLE empfängt.
Wenn das Festlegen oder Auslösen des Ereignisses abgeschlossen ist, wird CloseHandle für das duplizierte Handle aufgerufen.
Wenn Device MFT Nicht-KSEVENT_TYPE_ONESHOT-Ereignisse behandelt, sollte es das Handle duplizieren, wenn es KSEVENT_TYPE_ENABLE empfängt und CloseHandle für das duplizierte Handle aufruft, wenn das ks-Ereignis deaktiviert wird, indem die KsEvent-Funktion mit dem ersten Parameter (ks-Ereignis-ID) und dem zweiten Parameter (Ereignislänge) auf Null festgelegt wird. Die Ereignisdaten und die Länge sind gültig. Die Ereignisdaten identifizieren ein bestimmtes ks-Ereignis eindeutig.
Wenn Device MFT Nicht-KSEVENT_TYPE_ONESHOT-Ereignisse behandelt, sollte es das Handle duplizieren, wenn es KSEVENT_TYPE_ENABLE empfängt und CloseHandle für die duplizierten Handles aufrufen soll, wenn die ks-Ereignisse durch Aufrufen der KsEvent-Funktion mit allen Parametern auf Null deaktiviert werden.
Benachrichtigungsanforderungen
Geräte-MFTs müssen die folgenden Meldungen verwenden, um DTM über die Verfügbarkeit von Beispielen, jegliche Änderung des Eingabedatenstromzustands usw. zu informieren.
Threadanforderungen
Geräte-MFT darf keine eigenen Threads erstellen. Stattdessen muss Media Foundation-Arbeitswarteschlangen verwendet werden, die basierend auf der AN DIE DMFT übergebenen ID über die IMFRealTimeClientEx-Schnittstelle zugewiesen werden. Dadurch wird sichergestellt, dass alle threads, die im Geräte-MFT ausgeführt werden, die richtige Priorität erhalten, bei der die Aufnahmepipeline ausgeführt wird und Threadprioritätsinversionsvorgänge vermieden werden.
InputStream-Anforderungen
Streamanzahl
- Die Anzahl der Eingabedatenströme in Device MFT muss mit der Anzahl der vom Treiber unterstützten Datenströme übereinstimmen.
MediaTypes
Die Anzahl der Medientypen und die tatsächlichen Medientypen, die von der Eingabe des Geräts MFT unterstützt werden, müssen mit der Anzahl und den Vom Treiber unterstützten Medientypen übereinstimmen.
Die Zahl kann nur unterschiedlich sein, wenn die von der Eingabe von Device MFT unterstützten Medientypen eine Teilmenge der vom Treiber unterstützten Medientypen sind.
Die vom Treiber unterstützten Medientypen und die Eingabe von Device MFT können Standard- oder benutzerdefinierte Medientypen sein.
Registrieren von Device MFT
Das Kameragerät INF muss über den folgenden Geräteschnittstelleneintrag verfügen, der die CLSID der CoClass des Device MFT angibt.
[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%
Diese INF-Einträge führen dazu, dass die folgenden Registrierungsschlüssel eingegeben werden:
Hinweis
Dies ist ein Beispiel nur (nicht der tatsächliche 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 >>>
MFT-Verkettung von Geräten
Geräte-MFT ist der empfohlene Benutzermodus-Plug-In-Mechanismus für IHVs und OEMs, um die Kamerafunktionalität unter Windows zu erweitern.
Vor Windows 10, Version 1703, unterstützte die Kamerapipeline nur ein DMFT-Erweiterungs-Plug-In.
Ab Windows 10, Version 1703, unterstützt die Windows-Kamerapipeline eine optionale Kette von DMFTs mit maximal zwei DMFTs.
Ab Windows 11, Version 22H2, unterstützt die Windows-Kamerapipeline eine optionale Kette von DMFTs mit maximal vier DMFTs.
Dies bietet größere Flexibilität für OEMs und IHVs, um Wert-Add-In in Form von Nachbearbeitungskamerastreams bereitzustellen. Beispielsweise könnte ein Gerät PDMFT zusammen mit einer IHV DMFT und einem OEM DMFT verwenden.
In der folgenden Abbildung ist die Architektur dargestellt, die eine Kette von DMFTs umfasst.
Erfassen Sie Beispiele, die vom Kameratreiber zu DevProxy fließen, und durchlaufen Sie dann die DMFT-Ketten. Jede DMFT in der Kette hat die Möglichkeit, die Probe zu verarbeiten. Wenn das DMFT das Beispiel nicht verarbeiten möchte, kann es als Pass-Through fungieren, nur das Beispiel an den nächsten DMFT übergeben.
Bei Steuerelementen wie KsProperty wechselt der Aufruf in den Datenstrom – der letzte DMFT in der Kette ruft zuerst den Aufruf ab. Der Anruf kann dort behandelt oder an vorherige DMFT in der Kette übergeben werden.
Fehler werden dann von DMFT an DTM weitergegeben. Bei IHV/OEM-DMFTs kann eines der DMFT-Dateien nicht instanziiert werden, ein schwerwiegender Fehler für DTM.
Anforderungen an DMFTs:
Die Anzahl der Eingabenadeln der DMFT muss mit der Ausgabeheftanzahl der vorherigen DMFT übereinstimmen. Andernfalls würde DTM während der Initialisierung fehlschlagen. Die Anzahl der Eingabe- und Ausgabe-Pins desselben DMFT muss jedoch nicht übereinstimmen.
DMFT muss Schnittstellen unterstützen – IMFDeviceTransform, IMFShutdown, IMFRealTimeClientEx, IKsControl und IMFMediaEventGenerator; IMFTransform muss möglicherweise unterstützt werden, wenn MFT0 konfiguriert ist oder die nächste DMFT in der Kette IMFTransform-Unterstützung erfordert.
Auf 64-Bit-Systemen, die frame Server nicht verwenden, müssen sowohl 32-Bit- als auch 64-Bit-DMFTs registriert werden. Da eine USB-Kamera möglicherweise an ein beliebiges System angeschlossen wird, für "externe" (oder nicht posteingangsfreie) USB-Kameras sollte der USB-Kameraanbieter sowohl 32-Bit- als auch 64-Bit-DMFTs bereitstellen.
Konfigurieren der DMFT-Kette
Ein Kameragerät kann optional ein DMFT COM-Objekt in einer DLL mithilfe einer benutzerdefinierten INF-Datei bereitstellen, die Abschnitte des Posteingangs USBVideo.INF verwendet.
In der benutzerdefinierten . Geben Sie im Abschnitt "Interface AddReg" der INF-Datei die DMFT CLSIDs an, indem Sie den folgenden Registrierungseintrag hinzufügen:
CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft.CLSID%,%Dmft2.CLSID%
Wie in den folgenden INF-Beispieleinstellungen gezeigt (ersetzen Sie die %Dmft0.CLSID% und % Dmft1.CLSID% durch die tatsächlichen CLSID-Zeichenfolgen, die Sie für Ihre DMFTs verwenden), gibt es maximal 2 CLSIDs in Windows 10, Version 1703, und der erste ist am nächsten mit DevProxy und der letzte ist der letzte DMFT in der Kette.
Die PLATTFORM DMFT CLSID ist {3D096DDE-8971-4AD5-98F9-C74F56492630}.
Einige Beispieleinstellungen für CameraDeviceMftCLSIDChain :
Keine IHV/OEM DMFT oder Plattform-DMFT
- CameraDeviceMftCLSIDChain = "" (oder nicht erforderlich, diesen Registrierungseintrag anzugeben)
IHV/OEM DMFT
- CameraDeviceMftCLSIDChain = %Dmft.CLSID%
Plattform DMFT <-> IHV/OEM DMFT
CameraDeviceMftCLSIDChain = "{3D096DDE-8971-4AD5-98F9-C74F56492630}",%Dmft.CLSID%
Hier ist ein Screenshot des Ergebnisregistrierungsschlüssels für eine USB-Kamera mit Platform DMFT und einer DMFT (mit GUID {D671BE6C-FDB8-424F-81D7-03F5B1CE2CC7}) in der Kette.
IHV/OEM DMFT0 <-> IHV/OEM DMFT1
- CameraDeviceMftCLSIDChain = %Dmft0.CLSID%,%Dmft1.CLSID%,
Hinweis
Die CameraDeviceMftCLSIDChain kann maximal 2 CLSIDs aufweisen.
Wenn CameraDeviceMftCLSIDChain konfiguriert ist, werden die älteren CameraDeviceMftCLSID-Einstellungen von DTM übersprungen.
Wenn CameraDeviceMftCLSIDChain nicht konfiguriert ist und die ältere CameraDeviceMftCLSID konfiguriert ist, würde die Kette wie folgt aussehen (wenn ihre USB-Kamera und von Platform DMFT und Platform DMFT unterstützt werden) DevProxy <–> Platform DMFT – Platform DMFT <–> OEM/IHV DMFT oder (wenn die Kamera von Platform DMFT oder Platform DMFT nicht unterstützt wird) DevProxy <-> OEM/IHV DMFT deaktiviert.
Beispieleinstellungen für INF-Dateien:
[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 und MFT-Registrierung von Geräte-MFTs
Anstatt das COM-Objekt des Treibers global zu registrieren, wird das COM-Treiberobjekt unter dem Geräteschlüssel registriert. Dies ermöglicht die MFT-COM-Registrierung innerhalb des Containers und verhindert, dass globale Registrierungsschlüssel erstellt werden, wodurch die Treiberpaketisolation erhalten bleibt. MFTs werden aus ähnlichen Gründen auch unter dem Geräteschlüssel registriert.
Änderungen am Treiber-INF
Bei der Installation des Gerätetreibers muss die INF jetzt alle COM-Objekte und MFT-Registrierungen unter dem Geräteschlüssel vornehmen. MFT- und COM-Registrierungen müssen sich wie hier gezeigt ändern:
MFT-Registrierungen
| Vorher | After |
|---|---|
| INF AddReg: HKCR, MediaFoundation\Transforms\{clsid}\... |
Gerätesoftware PRO Instanz INF AddReg: HKR, MediaFoundation\Transforms\{clsid}\... |
| Registrierungsspeicherort: HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\... |
Registrierungsspeicherorte: software key\MediaFoundation\Transforms\{clsid}\... |
COM-Registrierungen
In Windows 26100 und höher müssen alle COM-Registrierungen für Geräte-MFTs AddComServer/AddComClass-Direktiven in der INF verwenden. Ein Syntaxbeispiel wird hier gezeigt:
[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%
In früheren Versionen der Device MFT COM-Registrierung wurde AddReg verwendet, um die COM-Klasse manuell zu installieren.
| Vorher | After |
|---|---|
| INF AddReg: HKLM,Software\Classes\CLSID\{clsid}\... HKCR,CLSID\{clsid}\... HKCR,Wow6432Node\CLSID\{clsid}\... HKCR,WowAA32Node\CLSID\{clsid}\... |
Gerätesoftware PRO Instanz INF AddReg: HKR,Classes\CLSID\{clsid}\... HKR,Classes\CLSID\{clsid}\... HKR,Classes\Wow6432Node\CLSID\{clsid}\... HKR,Classes\WowAA32Node\CLSID\{clsid}\... |
Die INF-Syntax für die Unterscheidung basierend auf der Betriebssystemversion finden Sie unter Kombinieren von Plattformerweiterungen mit Betriebssystemversionen. Ab Fenster 11 25300 muss der INF diesen neuen Registrierungsschlüsseln entsprechen. Ältere Betriebssystemversionen verwenden die herkömmlichen Registrierungsschlüssel zur Kompatibilität. Der INF muss diese Registrierungsschlüssel am alten Speicherort auf älteren Betriebssystembuilds einrichten und die neuen Schlüssel an ihrem neuen Speicherort für neuere Betriebssystembuilds erstellen. For example, for an MFT registration on an older build the INF creates the key under the following registry entry:
HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\
Bei einer MFT-Registrierung für einen neuen Build erstellt der INF den Schlüssel unter dem folgenden Registrierungseintrag:
**software key**\MediaFoundation\Transforms\{clsid}\
Dieser Eintrag definiert, wo Softwareschlüssel den Softwareschlüssel eines Geräts darstellt.
Weitere Informationen finden Sie unter Öffnen des Softwareschlüssels eines Geräts.
Ein Syntaxbeispiel für die Ausrichtung verschiedener Betriebssystemversionen wird hier gezeigt:
[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
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für