Designhandbuch 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 bereitgestellte Erweiterungskomponente, die von IHVs bereitgestellt wird und die Aufnahmepipeline als erste Umwandlung nach dem Erfassen eingefügt wird. Der DMFT empfängt nachbearbeitete 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.

Terminologie

Designziele

• 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 sind drei Datenströme: Vorschau, Aufnahme und Foto)

• Leitet alle Gerätesteuerungen an das Device MFT weiter, das 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-Erweiterungsfähigkeit

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 Ks-Gerätefilter 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 Probenverteilung 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 Video-Frames zwischen dem AVStream-Kameratreiber und Media Foundation koordiniert. Dies wird von Windows bereitgestellt und unterstützt die Anzahl der Ausgaben des Kameratreibers. Außerdem besitzt diese Komponente die Allokatoren für alle Pins, die vom Gerät bereitgestellt 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, Aufnahmestapel, der Aufnahme-API und Anwendungen angezeigt werden und 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, 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 die MF WorkQueue-ID. Frames, die aus dem Gerät kommen, werden direkt als MF-Samples in den entsprechenden Geräte-MFT-Eingang eingespeist. Mit all diesen kann Device MFT die aufgenommenen Proben nachverarbeiten und Proben an den Vorschau-, Aufzeichnungs- und Foto-Pins bereitstellen.

Alle Befehle und Steuerelemente, die zum Gerät gelangen, werden an Device MFT umgeleitet. Das Geräte-MFT verarbeitet die Steuerelemente oder leitet sie über Devproxy an den Treiber weiter. Dadurch wird die Befehlsverarbeitung durch den Aufnahmetreiberstapel vereinfacht.

Ü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 wirkt bei der Erstellung von Geräte-MFT mit und führt grundlegende Überprüfungen durch, zum Beispiel, ob die Anzahl der Ausgabepins von Devproxy mit der Anzahl der Eingabepins des Geräte-MFT übereinstimmt, die Unterstützung für obligatorische Schnittstellen und Ähnliches.

DeviceSource fragt DTM ab, um die unterstützten Ausgabemedientypen abzurufen. DTM erhält dies von den Ausgabe-Pins von Device MFT. 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. Das MFT-Gerät stellt die spezifischen Ausgabeströme im gewünschten Zustand ein. Wie bereits erwähnt, benachrichtigt Device MFT auch DTM über die erforderlichen Eingabedatenströme, die aktiviert werden müssen. Dies führt dazu, dass DTM die Datenstromauswahl an Devproxy überträgt. 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 die Nachrichten MFT_MESSAGE_NOTIFY_BEGIN_STREAMING und MFT_MESSAGE_NOTIFY_START_OF_STREAM gesendet werden, die den Start der Pipeline anzeigen. DTM startet Devproxy und Device MFT, indem es die Nachrichten MFT_MESSAGE_NOTIFY_BEGIN_STREAMING und MFT_MESSAGE_NOTIFY_START_OF_STREAM weitergibt.

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 einen gültigen Medientyp haben. Devproxy weist die Proben zu und holt sie vom Gerät ab. Diese Samples werden in den relevanten Eingabepin des Geräte-MFT eingespeist. Geräte-MFT verarbeitet diese Samples und gibt 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 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 Übergang des Ausgabedatenstroms wird jedoch von der Erfassungspipeline gesteuert. Beispielsweise können die Vorschau-, Aufnahme- und Fotostreams von der Aufnahmepipeline aktiviert oder deaktiviert werden. 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.

Aus einer Pipeline-Perspektive wird, wenn die Gerätequelle erstellt wird, die Geräte-MFT erstellt, und wenn die Gerätequelle heruntergefahren wird, wird die Geräte-MFT synchron heruntergefahren.

Um das Herunterfahren zu unterstützen, muss Device MFT die IMFShutdown-Schnittstelle unterstützen. Nachdem das MFT-Herunterfahren> des Geräts aufgerufen wurde, muss jeder andere Schnittstellenaufruf im Geräte-MFT einen MF_E_SHUTDOWN Fehler zurückgeben.

Speichertyp

Frames können je nach Einstellung des Kameratreibers in Systemspeicherpuffern oder DX-Speicherpuffern 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 des SourceReader können die Medientypen anzeigen, die von den Ausgabestreams des Geräts MFT als nativ unterstützte Medientypen bereitgestellt 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 Samples aus der Warteschlange dieses Datenstroms zu flushen und zeitnah zum neuen Medientyp 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 den nativen Medientyp ändert, kaskadiert dies durch den Aufnahmestapel und führt zu einer Änderung des Medientyps des Ausgabe-Pins in Device MFT.

  • Wenn sich der Ausgabemedientyp ändert, kann er eine Änderung des Eingabemedientyps auslösen. Nehmen wir zum Beispiel an, dass alle Ausgabepins mit einer Auflösung von 720p streamen. Dies führt zum Streamen von der Kamera bei 720p. Gehen Sie als Nächstes davon aus, dass der Datenstrom seinen nativen Medientyp zu 1080p wechselt. In diesem Fall müsste einer der Geräte-MFT-Eingabedatenströme, die Daten für den Aufzeichnungsdatenstrom abrufen, den Medientyp verändern.

• Ausgangspin ist deaktiviert

  • Wenn eine Anwendung einen der Ausgänge der Geräte-MFT deaktiviert, weil derselbe Eingang von mehreren Ausgängen gemeinsam genutzt wird, könnte es zur Optimierung erforderlich sein, dass der Eingang seinen Medientyp ändern muss. 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

  • MFT-Gesamtspülung für Geräte Dies geschieht in der Regel, wenn die DTM eine Stoppstreamingnachricht an Device MFT sendet.

  • Es wird erwartet, dass die Geräte-MFT alle Samples aus ihren Eingabe- und Ausgabewarteschlangen ablegt und synchron zurückzugeben.

  • Das Gerätemodul-MFT sollte keine neuen Eingaben anfordern oder Benachrichtigungen über neu verfügbare Ausgaben senden.

• Lokale Spülung

  • Pin-spezifisches Spülen. Dies geschieht in der Regel, wenn ein Datenstrom beendet wird.

Vom Geräte-MFT-Manager werden alle Ereignisse, die vor dem Flush-Vorgang gepostet wurden, 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.

Fotoauslöser

In diesem Modell werden der Fototrigger und die Fotosequenz-Start- und -Stopp-Trigger nicht direkt an den Treiber gesendet, sondern an Device MFT umgeleitet. Das Gerät MFT verarbeitet den Auslöser oder leitet ihn bei Bedarf an den Kameratreiber weiter.

Warmer Start

DeviceSource versucht, einen bestimmten Ausgabedatenstrom durch den Übergang in den Pausenzustand neu zu starten. DTM ruft wiederum die Methode IMFDeviceTransform::SetOutputStreamState auf dem Device MFT auf, um einen bestimmten Ausgabedatenstrom in den Pausenstatus zu versetzen. 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-Auslöser für die Fotosequenz werden an Device MFT gesendet, was die Handhabung der Fotosequenz erleichtert.

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 Te-Treiber stammen, werden vom Devproxy im Beispiel festgelegt. Geräte-MFT verarbeitet die Metadaten des Beispiels. Metadaten können entweder mit der Stichprobe ü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 anfordern, einen oder mehrere Videostreams sowie den Metadatendatenstrom mithilfe des METransformInputStreamStateChanged-Ereignisses zu starten.

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:

• 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-Eingängen und n-Ausgangsgeräte-MFT. Zusammen mit anderen Schnittstellen muss Device MFT diese Schnittstelle implementieren.

Allgemeine Ereignisverbreitung

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:

• IMFDeviceTransform

• IKsControl-

  • 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. Falls die KsEvent-Methoden behandelt werden, muss die Device MFT die folgenden Schritte ausführen:

    • Wenn Device MFT ein 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.

• IMFRealTimeClientEx

• IMFMediaEventGenerator

• IMFShutdown-

• IMFSampleAllocatorControl

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.

• METransformHaveOutput

• METransformInputStreamStateChanged

• METransformFlushInputStream

Threadanforderungen

Geräte-MFT darf keine eigenen Threads erstellen. Stattdessen müssen Media Foundation-Arbeitswarteschlangen verwendet werden, die basierend auf der ID, die an die DMFT übergeben wird, ü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, unter der die Aufnahmepipeline läuft, und dass Thread-Prioritätsumkehrungen 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 und der Eingabe des Device MFT unterstützten Medientypen können Standard- oder benutzerdefinierte Medientypen sein.

Wie man Device MFT registriert

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:

[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 bis zu maximal vier DMFTs.

Dies bietet größere Flexibilität für OEMs und IHVs, um Mehrwert in Form der Nachbearbeitung von Kamerastreams 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.

Proben fließen vom Kameratreiber zu DevProxy und durchlaufen anschließend die DMFT-Ketten. Jede DMFT in der Kette hat die Möglichkeit, die Probe zu verarbeiten. Wenn das DMFT die Probe nicht verarbeiten möchte, kann es als Durchlauf fungieren und die Probe einfach an das nächste DMFT weitergeben.

Bei Steuerelementen wie KsProperty wird der Aufruf nach oben im Datenstrom gesendet – der letzte DMFT in der Kette erhält den Aufruf zuerst. Der Anruf kann dort behandelt oder an vorherige DMFT in der Kette übergeben werden.

Fehler werden von DMFT auf DTM und dann auf Anwendungen übertragen. Bei IHV/OEM-DMFTs kann eines der DMFT-Dateien nicht instanziiert werden, ein schwerwiegender Fehler für DTM.

Anforderungen an DMFTs:

• Die Input-Pin-Anzahl des DMFT muss mit der Output-Pin-Anzahl des 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, sollte der Anbieter externer (also nicht eingebauter) USB-Kameras 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 Sektionen der Inbox USBVideo.INF verwendet.

In der benutzerdefinierten .INF-Datei im Abschnitt "Interface AddReg" geben Sie die DMFT CLSIDs an, indem Sie den folgenden Registrierungseintrag hinzufügen:

CameraDeviceMftCLSIDChain (REG_MULTI_SZ) %Dmft0.CLSID%,%Dmft. CLSID%,%Dmft2.CLSID%

Wie im folgenden Beispiel in den INF-Einstellungen gezeigt (ersetzen Sie die %Dmft0.CLSID-% und % Dmft1.CLSID-% mit den tatsächlichen CLSID-Zeichenfolgen, die Sie für Ihre DMFTs verwenden), sind in Windows 10, Version 1703, maximal zwei CLSIDs zulässig. Die erste steht näher an DevProxy, und die letzte ist der abschließende 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%,

Wenn CameraDeviceMftCLSIDChain konfiguriert ist, werden die älteren CameraDeviceMftCLSID-Einstellungen von DTM übersprungen.

Wenn CameraDeviceMftCLSIDChain nicht konfiguriert ist und das ältere CameraDeviceMftCLSID konfiguriert ist, würde die Kette wie folgt aussehen: (wenn es sich um eine USB-Kamera handelt, die von Platform DMFT unterstützt wird und Platform DMFT aktiviert ist) DevProxy <–> Platform DMFT <–> OEM/IHV DMFT; oder (wenn die Kamera nicht von Platform DMFT unterstützt wird oder Platform DMFT deaktiviert 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 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

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.

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. Zum Beispiel erstellt die INF bei einer MFT-Registrierung auf einem älteren Build den Schlüssel unter dem folgenden Registrierungseintrag:

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