Verhandlungspartner

[Das dieser Seite zugeordnete Feature DirectShow-ist ein Legacyfeature. Es wurde von MediaPlayer, IMFMediaEngineund Audio/Video Capture in Media Foundationersetzt. Diese Features wurden für Windows 10 und Windows 11 optimiert. Microsoft empfiehlt dringend, dass neuer Code MediaPlayer-, IMFMediaEngine und Audio-/Videoaufnahme in Media Foundation anstelle von DirectShow-verwendet, wenn möglich. Microsoft schlägt vor, dass vorhandener Code, der die Legacy-APIs verwendet, um die neuen APIs zu verwenden, falls möglich umgeschrieben werden.]

Wenn zwei Pins eine Verbindung herstellen, benötigen sie einen Mechanismus für den Austausch von Mediendaten. Dieser Mechanismus wird als Transportbezeichnet. Im Allgemeinen ist die DirectShow-Architektur neutral über Transporte. Zwei Filter können zustimmen, eine Verbindung mit jedem Transport herzustellen, der beide unterstützen.

Der häufigste Transport ist der lokalen Speicher Transport, in dem sich die Mediendaten im Hauptspeicher befinden. Es gibt zwei Varianten des lokalen Speichertransports, das Pushmodell und das Pullmodell. Im Pushmodell verschiebt der Quellfilter Daten an den downstream-Filter, wobei die IMemInputPin Schnittstelle auf dem Eingabestift des nachgeschalteten Filters verwendet wird. Im Pullmodell fordert der downstream-Filter Daten aus dem Quellfilter mithilfe der IAsyncReader Schnittstelle auf der Ausgabe-Pin des Quellfilters an. Weitere Informationen zu diesen beiden Datenflussmodellen finden Sie unter Datenfluss im Filterdiagramm-.

Im lokalen Speichertransport wird das objekt, das für die Zuordnung von Speicherpuffern verantwortlich ist, als allocatorbezeichnet. Ein Allocator unterstützt die IMemAllocator Schnittstelle. Beide Pins teilen einen einzigen Allocator. Jeder Pin kann einen Zuweisungsstift bereitstellen, aber der Ausgabenadel wählt den zu verwendenden Allocator aus.

Die Ausgabenadel legt außerdem die Allocatoreigenschaften fest, die bestimmen, wie viele Puffer vom Allocator, der Größe jedes Puffers und der Speicherausrichtung erstellt werden. Die Ausgabenadel wird möglicherweise auf den Eingabestift für die Pufferanforderungen zurückstellen.

In einer IMemInputPin Verbindung funktioniert allocator-Aushandlung wie folgt:

1. Optional ruft die Ausgabenadel IMemInputPin::GetAllocatorRequirementsauf. Diese Methode ruft die Pufferanforderungen der Eingabenadel ab, z. B. die Speicherausrichtung. Im Allgemeinen sollte die Ausgabenadel die Anforderung der Eingabenadel berücksichtigen, es sei denn, es gibt einen guten Grund.
2. Optional ruft die Ausgabenadel IMemInputPin::GetAllocatorauf. Diese Methode fordert einen Zuweisungsgeber von der Eingabenadel an. Die Eingabenadel stellt einen oder gibt einen Fehlercode zurück.
3. Die Ausgabenadel wählt einen Ocator aus. Sie kann eine von der Eingabenadel bereitgestellte oder eigene erstellen.
4. Die Ausgabenadel ruft IMemAllocator::SetProperties auf, um die Allocatoreigenschaften festzulegen. Der Allocator berücksichtigt jedoch möglicherweise nicht die angeforderten Eigenschaften. (Dies kann beispielsweise passieren, wenn der Eingabenadel den Allocator bereitstellt.) Der Allocator gibt die tatsächlichen Eigenschaften als Ausgabeparameter in der SetProperties--Methode zurück.
5. Die Ausgabe ruft IMemInputPin::NotifyAllocator auf, um den Eingabenadel der Auswahl zu informieren.
6. Die Eingabenadel sollte IMemAllocator::GetProperties aufrufen, um zu überprüfen, ob die Allocator-Eigenschaften akzeptabel sind.
7. Der Ausgabe-Pin ist für das Commit und die Dekommitierung des Allocators verantwortlich. Dies tritt auf, wenn das Streaming gestartet und beendet wird.

In einer IAsyncReader--Verbindung funktioniert die Allocator-Aushandlung wie folgt:

1. Die Eingabenadel ruft IAsyncReader::RequestAllocator auf der Ausgabenadel auf. Der Eingabenadel gibt die Pufferanforderungen an und stellt optional einen Zuweisungsgeber bereit.
2. Die Ausgabenadel wählt einen Ocator aus. Sie kann die von der Eingabenadel bereitgestellte, falls vorhanden, verwenden oder eigene erstellen.
3. Die Ausgabenadel gibt den Allocator als ausgehenden Parameter in der RequestAllocator--Methode zurück. Die Eingabenadel sollte die Eigenschaften des Allocator überprüfen.
4. Der Eingabe-Pin ist für das Commit und die Dekommittierung des Allocators verantwortlich.
5. Während des Allocator-Aushandlungsprozesses kann jeder Pin die Verbindung nicht herstellen.
6. Wenn der Ausgabenadel den Ocator des Eingabehefts verwendet, kann dieser Allocator nur verwendet werden, um Beispiele an diesen Eingabenadel zu übermitteln. Der besitzereigene Filter darf den Allocator nicht verwenden, um Proben an andere Pins zu übermitteln.

Verwandte Themen

Bereitstellen eines benutzerdefinierten Allocator-