Entwurfshandbuch für Geräte-MFT

Der Videoaufnahmestapel in Windows unterstützt eine Erweiterung des Benutzermodus in Form von DMFT. Dies ist eine „pro-Gerät“ Erweiterungskomponente, die IHVs bereitstellen und von der Aufnahmepipeline als erste Transformation nach der Aufnahme eingefügt wird. DMFT empfängt verarbeitete Frames vom Gerät. Weitere Nachbearbeitungsvorgänge auf den Frames können innerhalb der DMFT durchgeführt werden. Die 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

Entwurfsziele

• Gerätefilterweite Benutzermoduserweiterung mit der gleichen Lebensdauer wie der Gerätefilter

• Unterstützt eine beliebige Anzahl von Eingaben durch das Gerät

• Unterstützt eine beliebige Anzahl von Ausgaben (aktuelle Anforderung beträgt drei Datenströme: Vorschau, Datensatz und Foto)

• Leitet alle Gerätesteuerelemente an Device MFT weiter (welches diese optional verarbeitet oder an das Gerät übergibt)

• 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 Capture-API-Oberfläche

• Vollständige Abwärtskompatibilität. Beispielsweise keine Regressionen beim Arbeiten mit Legacy-Apps und -Szenarien.

Architektur von Aufnahmestapeln

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 filterweite Erweiterung bietet die Flexibilität, über eine beliebige Anzahl von Datenströmen zwischen sich selbst und dem Geräte-Ks-Filter zu verfügen. Diese Flexibilität ermöglicht eine nahtlose Out-of-Band-Kommunikation zwischen der Benutzermoduserweiterung und dem Treiber, was für dedizierte Metadaten und 3A-Verarbeitungsdatenströme verwendet werden kann.

Device Transform Manager (DTM)

Der Aufnahmestapel führt eine neue vom System bereitgestellte Komponente ein, den Device Transform Manager (DTM). Dieser 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ätestreams 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 Gerätestreams.

Devproxy

Devproxy ist eine asynchrone MFT, die die Befehle und Videoframes zwischen dem AVStream-Kameratreiber und Media Foundation marshallt. Diese wird von Windows bereitgestellt und unterstützt eine Anzahl von n Ausgaben des Kameratreibers. Außerdem besitzt sie 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 eine m x n asynchrone MFT. Sie 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 Ausgabedatenströme, die von Device MFT verfügbar gemacht werden, sind die Datenströme, die von DeviceSource und Aufnahmestapel, Capture API und Anwendungen angezeigt werden; dies können ein, zwei oder drei Datenströme 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, der zweite Ks-Pin, der im Benutzermodus durch den Ausgabedatenstrom von Devproxy dargestellt wird, wird dem zweiten Eingabedatenstrom von Device MFT zugeordnet usw.

Device MFT erhält einen Zeiger auf Devproxy, DX-Gerät und MF WorkQueue ID. Frames, die aus dem Gerät stammen, werden direkt in die Eingabe der entsprechenden Device MFT als MF Samples eingespeist. Mit all diesen Daten kann Device MFT die aufgenommenen Proben veröffentlichen und Proben an die Vorschau-, Aufzeichnungs- und Foto-Pins bereitstellen.

Alle an das Gerät gerichteten Befehle und Steuerelemente werden an Device MFT umgeleitet. Device MFT verarbeitet die Steuerelemente oder gibt sie ü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 eine Device MFT für das Gerät vorhanden ist. Es übergibt eine Instanz von Devproxy, die das Gerät in der Initialisierungsroutine von DTM darstellt. DTM erstellt Device MFT und führt grundlegende Validierungen durch, z. B. die Überprüfung, ob die Anzahl der Ausgangspins von Devproxy mit der Anzahl der Eingangspins von Device MFT übereinstimmt, Unterstützung für obligatorische Schnittstellen usw.

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 der 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 Aufrufs 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. Device 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- 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.

DTM ruft SetOutputStreamState auf den Ausgaben von Device MFT mit dem Streamingstatusparameter auf. Device MFT beginnt mit dem Streaming in diesen Ausgabedatenströmen. DTM startet das Streaming für die Devproxy-Ausgabedatenströme, die über einen gültigen Medientypsatz verfügen. Devproxy weist die Beispiele zu und ruft sie vom Gerät ab. Diese Beispiele werden an Device MFT in den relevanten Eingabepin eingespeist. Device MFT verarbeitet diese Beispiele und übergibt die Ausgabe an 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-Datenströme.

Solange sich die Device MFT selbst im Streamingzustand befindet, kann sie jeden Eingabedatenstrom anfordern, um zu einem der gültigen DeviceStreamState zu wechseln. Beispielsweise könnte sie sie an DeviceStreamState_Stop oder DeviceStreamState_Run oder DeviceStreamState_Pause usw. senden, ohne dass sich dies auf andere Datenströme auswirkt.

Der Ausgabedatenstromübergang wird jedoch von der Aufnahmepipeline gesteuert. Beispielsweise werden die Vorschau-, Datensatz- und Fotodatenströme von der Aufnahmepipeline aktiviert oder deaktiviert. Selbst wenn die Ausgaben deaktiviert sind, könnte ein Eingabedatenstrom weiterhin gestreamt werden, solange sich Device MFT selbst im Streamingzustand befindet.

Lebensdauer von Device MFT

Device MFT wird geladen, nachdem der KS-Filter erstellt wurde. Wird entladen, bevor der KS-Filter geschlossen wird.

Aus Sicht der Pipeline wird bei der Erstellung der Device Source die Device MFT erstellt und beim Herunterfahren der DeviceSource wird die Device MFT synchron heruntergeladen.

Um das Herunterfahren zu unterstützen, muss Device MFT die IMFShutdown-Schnittstelle unterstützen. Nach dem Aufruf von Device MFT->Shutdown muss jeder andere Schnittstellenaufruf in der Device MFT einen MF_E_SHUTDOWN-Fehler zurückgeben.

Arbeitsspeichertyp

Frames können in Systemspeicherpuffern oder DX-Speicherpuffern, je nach Einstellung des Kameratreibers, erfasst werden. Welcher Puffer aus dem Kameratreiber stammt, wird zur weiteren Verarbeitung direkt in die 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 Ausgabepins für nicht eingefügte Transformationen erforderlich sind.

Medientypänderung beim Streaming

Clients von SourceReader können die Medientypen anzeigen, die von den Ausgabestreams der Device MFT als systemeigene unterstützte Medientypen verfügbar gemacht werden. Wenn der systemeigene Medientyp geändert wird, sendet SourceReader Mediatyp-Benachrichtigungsaufrufe über DeviceSource in die Device MFT. Es liegt in der Verantwortung der Device MFT, alle ausstehenden Beispiele aus der Warteschlange dieses Datenstroms zu leeren und zeitnah zum neuen Medientyp in diesem Datenstrom zu wechseln. Wenn es erforderlich ist, den Eingabemedientyp zu ändern, sollte sie den aktuellen Eingabemedientyp in diesen ändern. DTM ruft den aktuellen Medientyp aus dem Eingabedatenstrom der Device MFT ab und legt ihn für die Ausgabedatenströme von Devproxy und die Eingabe der Device MFT nach jeder Änderung des systemeigenen Medientyps fest.

Änderung des Eingabemedientyps in Device MFT

Da dies eine m x n MFT ist, kann es Auswirkungen auf die Medientypen 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, wirkt sich das auch auf den Aufnahmestapel als Ausgabepin-Medientypänderung in Device MFT aus.

  • Wenn sich der Ausgabemedientyp ändert, kann er eine Änderung des Eingabemedientyps auslösen. Nehmen wir beispielsweise an, dass alle Ausgabepins mit 720p gestreamt werden. Dies führt zum Streamen von der Kamera bei 720p. Gehen Sie als Nächstes davon aus, dass der Aufnahmedatenstrom seinen systemeigenen Medientyp auf 1080p ändert. In diesem Fall müsste einer der Device MFT-Eingabedatenströme, der Daten in den Aufnahmedatenstrom holt, seinen Medientyp ändern.

• Ausgabepin ist deaktiviert

  • Wenn eine Anwendung eine der Device MFT-Ausgaben deaktiviert, während 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 Device MFT-Eingabe und devproxy-Ausgabe unter diesen Bedingungen zu ändern.

Bevorzugte Ausgabemedientypen von Device MFT

Es wird empfohlen, dass die Device MFT Ausgabemedientypen im NV12-Format erzeugt. YUY2 ist die nächstbeste Alternative. MJPEG- und RGB-Medientypen werden nicht empfohlen.

Device MFT leeren

Beim Verwalten von Device MFT sind zwei Arten von Leerung erforderlich:

• Globale Leerung

  • Device MFT-weite Leerung. Dies geschieht in der Regel, wenn DTM eine Stoppstreamingnachricht an Device MFT sendet.

  • Von Device MFT wird erwartet, alle Beispiele aus ihren Eingabe- und Ausgabewarteschlangen abzulegen und synchron zurückzugeben.

  • Device MFT sollte keine neue Eingabe anfordern oder Benachrichtigungen über eine neue verfügbare Ausgabe senden.

• Lokale Leerung

  • Ausgabepin-spezifische Leerung. Dies geschieht in der Regel, wenn ein Datenstrom beendet wird.

Alle Ereignisse, die vor dem Leeren gepostet wurden, werden von Device MFT Manager gelöscht. Nach dem Leeren setzt Device MFT seine interne METransformHaveOutput-Trackinganzahl zurück.

Ausgleichen von Device MFT

Device MFT empfängt keine separate Ausgleichsnachricht, da kein Ausgleich in einer Liveaufnahmequelle erforderlich ist.

Foto-Trigger

Bei diesem Modell werden Fotoauslöser und die Start- und Stoppauslöser für die Fotosequenz nicht direkt an den Treiber gesendet, sondern an Device MFT weitergeleitet. Device MFT verarbeitet den Trigger oder leitet ihn bei Bedarf an den Kameratreiber weiter.

Warmstart

DeviceSource versucht, einen bestimmten Ausgabedatenstrom warm zu starten, indem der Datenstrom in den Pause-Zustand überführt wird. DTM ruft wiederum die IMFDeviceTransform::SetOutputStreamState-Methode auf Device MFT auf, um einen bestimmten Ausgabedatenstrom in den Pause-Zustand zu überführen. Dies führt dazu, dass der entsprechende Eingabedatenstrom auf Pause gesetzt wird. Dies wird von Device MFT erreicht, in des METransformInputStreamStateChanged an DTM anfordert und die IMFDeviceTransform::SetInputStreamState-Methode verarbeitet.

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-Fotosequenzauslöser werden an Device MFT gesendet und behandeln die Fotosequenz einfacher.

Fotobestätigung

Device 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 der Metadatenpuffergröße ab und weist den Speicher für Metadaten zu. Metadaten, die vom Treiber stammen, werden weiterhin von Devproxy im Beispiel festgelegt. Device 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 ein dedizierter Eingabepin 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 mithilfe des METransformInputStreamStateChanged-Ereignisses anfordern, einen oder mehrere Videostreams und den Metadatendatenstrom zu starten.

Hinweis: Es ist nicht erforderlich, dass die Anzahl der Eingabepins mit der Anzahl der Ausgabepins in diesem Modell übereinstimmt. Es kann einen separaten 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:

• METransformFlushInputStream

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformNeedInput

IMFDeviceTransform-Schnittstelle

Die IMFDeviceTransform-Schnittstelle ist für die Interaktion mit Device MFT definiert. Diese Schnittstelle erleichtert die Verwaltung von m-Eingaben und n-Ausgaben in Device 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 Device MFT und an DeviceSource weitergeben.

Anforderungen an Device MFT

Schnittstellen-Anforderungen

Device MFTs müssen die folgenden Schnittstellen unterstützen:

• IMFDeviceTransform

• IKsControl

  • Dadurch können alle ksproperties, Ereignisse und Methoden die Device MFT durchlaufen. Dadurch erhält Device MFT die Möglichkeit, diese Funktionsaufrufe innerhalb von Device MFT zu verarbeiten oder einfach an den Treiber weiterzuleiten. Für den Fall, dass sie KsEvent-Methoden behandelt, muss die Device MFT die folgenden Schritte ausführen:

    • Wenn Device MFT ein beliebiges KSEVENT_TYPE_ONESHOT-Ereignis behandelt, dupliziert es den Handle, wenn es KSEVENT_TYPE_ENABLE empfängt.

    • Wenn das Festlegen oder Auslösen des Ereignisses abgeschlossen ist, wird CloseHandle für den duplizierten Handle aufgerufen.

    • Wenn Device MFT nicht-KSEVENT_TYPE_ONESHOT-Ereignisse behandelt, sollte es den Handle duplizieren, wenn es KSEVENT_TYPE_ENABLE empfängt und CloseHandle für den duplizierten Handle aufrufen, 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 -Länge sind gültig. Die Ereignisdaten identifizieren ein bestimmtes ks-Ereignis eindeutig.

    • Wenn Device MFT nicht-KSEVENT_TYPE_ONESHOT-Ereignisse behandelt, sollte es den Handle duplizieren, wenn es KSEVENT_TYPE_ENABLE empfängt und CloseHandle für die duplizierten Handles aufrufen, wenn die ks-Ereignisse durch Aufrufen der KsEvent-Funktion – mit allen Parametern auf Null – deaktiviert werden.

• IMFRealTimeClientEx

• IMFMediaEventGenerator

• IMFShutdown

• IMFSampleAllocatorControl

Meldepflichten

Device MFTs müssen die folgenden Meldungen verwenden, um DTM über die Verfügbarkeit von Beispielen, jegliche Änderung des Eingabedatenstromzustands usw. zu informieren.

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

Threadanforderungen

Device MFT darf keine eigenen Threads erstellen. Stattdessen muss sie Media Foundation-Arbeitswarteschlangen verwenden, welche – basierend auf der an DMFT übergebenen ID – über die IMFRealTimeClientEx-Schnittstelle zugewiesen werden. Dadurch wird sichergestellt, dass alle Threads, die in der Device MFT ausgeführt werden, die richtige Priorität erhalten, in welcher die Aufnahmepipeline ausgeführt wird und Threadprioritätsinversionsvorgänge vermieden werden.

InputStream-Anforderungen

Datenstromanzahl

• 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 der Device MFT unterstützt werden, müssen mit der Anzahl und den vom Treiber unterstützten Medientypen übereinstimmen.

• Die Zahl darf nur unterschiedlich sein, wenn die von der Eingabe der Device MFT unterstützten Medientypen eine Teilmenge der vom Treiber unterstützten Medientypen sind.

• Die vom Treiber unterstützten Medientypen und die Eingabe der Device MFT können Standard- oder benutzerdefinierte Medientypen sein.

Vorgehensweise beim Registrieren von Device MFT

Das Kameragerät-INF muss über den folgenden Geräteschnittstelleneintrag verfügen, der die CLSID der CoClass der 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:

[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 >>>

Device MFT-Verkettung

Device 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 Werterhöhung in Form von Nachbearbeitungskameradatenströmen bereitzustellen. Beispielsweise könnte ein Gerät PDMFT zusammen mit einer IHV DMFT und einer OEM DMFT verwenden.

In der folgenden Abbildung ist die Architektur dargestellt, die eine Kette von DMFTs umfasst.

Aufnahmebeispiele fließen vom Kameratreiber zu DevProxy und durchlaufen dann die DMFT-Ketten. Jede DMFT in der Kette hat die Möglichkeit, das Beispiel zu verarbeiten. Wenn die DMFT das Beispiel nicht verarbeiten möchte, kann sie als Passthrough fungieren und das Beispiel an die nächste DMFT übergeben.

Bei Steuerelementen wie KsProperty wechselt der Aufruf Datenstrom-aufwärts – die letzte DMFT in der Kette erhält den Aufruf zuerst. Der Aufruf kann dort behandelt oder an vorherige DMFTs in der Kette übergeben werden.

Fehler werden dann von DMFT an DTM und dann an Anwendungen weitergegeben. Bei IHV/OEM-DMFTs ist jede der DMFT-Dateien, die nicht instanziiert werden kann, ein schwerwiegender Fehler für DTM.

Anforderungen an DMFTs:

• Die Anzahl der Eingabepins der DMFT muss mit der Ausgabepinanzahl der vorherigen DMFT übereinstimmen. Andernfalls würde DTM während der Initialisierung fehlschlagen. Die Anzahl der Eingabe- und Ausgabepins derselben 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 keine Frameserver 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.

Geben Sie im Abschnitt „Interface AddReg“ der benutzerdefinierten 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 %Dmft0.CLSID% und % Dmft1.CLSID% durch die tatsächlichen CLSID-Zeichenfolgen, die Sie für Ihre DMFTs verwenden), gibt es maximal 2 erlaubte CLSIDs in Windows 10, Version 1703, wobei die erste am nächsten an DevProxy ist und die letzte die letzte DMFT in der Kette darstellt.

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 Plattform-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%,

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 es sich um eine USB-Kamera handelt und sie von Plattform-DMFT unterstützt wird und Plattform-DMFT aktiviert ist): DevProxy <–> Platform DMFT <–> OEM/IHV DMFT oder (wenn die Kamera von Plattform-DMFT nicht unterstützt wird oder Plattform-DMFT nicht aktiviert ist): DevProxy <–> OEM/IHV DMFT.

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 Device 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 an Treiber-INF

Bei der Installation des Gerätetreibers muss die INF jetzt alle COM-Objekt- und MFT-Registrierungen unter dem Geräteschlüssel vornehmen. MFT- und COM-Registrierungen müssen sich wie hier gezeigt ändern:

MFT-Registrierungen

COM-Registrierungen

In Windows 26100 und höher müssen alle COM-Registrierungen für Device MFTs AddComServer/AddComClass-Anweisungen in der INF verwenden. Hier ist ein Syntaxbeispiel:

[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.

Die INF-Syntax für die Unterscheidung basierend auf der Betriebssystemversion finden Sie unter Kombinieren von Plattformerweiterungen mit Betriebssystemversionen. Ab Windows 11 25300 muss die INF diesen neuen Registrierungsschlüsseln entsprechen. Ältere Betriebssystemversionen verwenden die herkömmlichen Registrierungsschlüssel zur Kompatibilität. Die 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. Bei einer MFT-Registrierung auf einem älteren Build erstellt die INF den Schlüssel beispielsweise unter dem folgenden Registrierungseintrag:

HKLM\SOFTWARE\Classes\MediaFoundation\Transforms\{clsid}\ 

Bei einer MFT-Registrierung für einen neuen Build erstellt die INF den Schlüssel unter dem folgenden Registrierungseintrag:

**software key**\MediaFoundation\Transforms\{clsid}\ 

Dieser Eintrag definiert, wo software key 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