Behandeln der Datentypaushandlung in AVStream-Codecs

Wenn ein Gerät initialisiert wird, analysiert das vom System bereitgestellte Devproxy-Modul die vom Treiber bereitgestellten Filterdeskriptoren. Darüber hinaus macht Devproxy die vom Treiber unterstützten Datenbereiche auf den Eingabe- und Ausgabepins der entsprechenden MFT (Media Foundation Transform) verfügbar.

Wenn das Streaming beginnt, verwenden die MF-Pipeline und Benutzermodusanwendungen diese Bereiche, um Datentypverhandlung mit dem Treiber durchzuführen.

Die folgenden Interaktionen treten während einer Datentypverhandlung auf:

1. Devproxy ruft die Datenbereiche ab, die vom Minidriver in jedem Pindeskriptor der Hardwarecodecfilter bereitgestellt werden.

2. Devproxy stellt eine Datenschnittanforderung an den Treiber aus.

3. Devproxy macht vollgeformte Typen für MF verfügbar.

4. DER MF-Topologie-Generator (das MF-Äquivalent zum DirectShow-Graph-Generator) erstellt die Streamingtopologie.

5. Nachdem der MF-Topologie-Generator einen Datentyp für einen Devproxy-Eingabe-/Ausgabepin abgeschlossen hat, legt er den Datentyp auf der Pin fest, indem die AVStrMiniPinSetDataFormat-Rückruffunktion des Minidrivers aufgerufen wird. Wenn der KS-Pin nicht vorhanden ist, ruft Devproxy KsCreatePin auf.

Um eine erfolgreiche Datentypverhandlung zu ermöglichen, muss der Minidriver die folgenden Schritte ausführen:

1. Geben Sie eine Liste der unterstützten Datenbereiche im DataRanges-Member von KSPIN_DESCRIPTOR für jeden verfügbar gemachten Pin an, der in den Hardwarecodecfiltern enthalten ist. Beispiel:

   const PKSDATARANGE VideoDecoderInputPinDataRanges[8] = {
       (PKSDATARANGE)&H264DataFormat,
       (PKSDATARANGE)&VC_1DataFormat,
       (PKSDATARANGE)&VC_1DataFormatVIH2,
       (PKSDATARANGE)&WMV9DataFormat,
       (PKSDATARANGE)&WMV9DataFormatVIH2,
       (PKSDATARANGE)&DX50DataFormat,
       (PKSDATARANGE)&DX50DataFormatVIH2,
       (PKSDATARANGE)&MPEG2DataFormat
   };
   

   In diesem Fall sind die angegebenen Bereiche von Wrappertypen wie KS_DATARANGE_MPEG2_VIDEO, KS_DATARANGE_VIDEO und KS_DATARANGE_VIDEO2. Im zuvor aufgeführten Codebeispiel ist jeder Bereich typecast to KSDATARANGE.

   Das letzte Element der Wrapperstrukturen wird als Formatblockstruktur bezeichnet, z. B. KS_DATARANGE_MPEG2_VIDEO. VideoInfoHeader.

   Ein Treiber, der fortlaufende Datenbereiche unterstützt, sollte die Maximalwerte in der Formatblockstruktur angeben. Ein Treiber, der diskrete Datenbereiche unterstützt, sollte ein Array angeben, das die diskreten Werte in den Formatblockstrukturen enthält.

   Wenn ein Treiber, der behauptet, ein bestimmtes Format zu unterstützen, später eine festgelegte Formatanforderung an dieses Format fehlschlägt, kann die Leistung verringert werden. Nur Listenformate, für die Sie Unterstützung garantieren.

2. Treiber sollten zulassen, dass ein Medientyp in KSSTATE_STOP/KSSTATE_RUN an einer Pin festgelegt werden kann. Hier ist keine andere Aktion erforderlich, als sicherzustellen, dass der Treiber dies nicht verbietet.

3. Der Treiber sollte einen Schnittpunkthandler in KSPIN_DESCRIPTOR_EX bereitstellen. IntersectHandler für jeden Pin.

4. Der Minidriver sollte einen Handler für die KSPROPERTY_CONNECTION_PROPOSEDATAFORMAT-Eigenschaft bereitstellen.

5. Wenn der Ausgabemedientyp festgelegt ist, sollte ein Encoder mögliche Eingabetypen (mithilfe eines Pindeskriptors) basierend auf dem angegebenen Ausgabemedientyp melden. Wenn ein Ausgabemedientyp nicht festgelegt ist, sollten Encoder keinen Eingabemedientyp melden.

6. Wenn der Eingabemedientyp festgelegt ist, sollten Decoder mögliche Ausgabetypen basierend auf dem angegebenen Eingabemedientyp melden.

7. Wenn der Eingabemedientyp festgelegt ist, sollten Videoprozessoren ihre Ausgabetypen basierend auf dem angegebenen Eingabemedientyp melden.

8. Der Treiber sollte die ICodecAPI-Schnittstelle unterstützen. Benutzermoduskomponenten können dann Codeckonfigurationsinformationen abrufen, indem sie diese Benutzermodusschnittstelle verwenden.

9. Beim Einrichten eines Encoders werden zuerst die ICodecAPI-Eigenschaften festgelegt, gefolgt vom Ausgabemedientyp. Danach sollte der Encoder nur Eingabetypen bereitstellen, die er mit der aktuellen Konfiguration unterstützen kann.

10. ICodecAPI-Eigenschaften und Codec-API-Medientypeigenschaften überlappen sich in einigen Bereichen, z. B. Profil und Ebene. In diesen Fällen überschreiben Codec-API-Eigenschaften, die sich auf den Medientyp beziehen, ICodecAPI-Eigenschaften. Nachdem der Medientyp festgelegt wurde, sollte der Minidriver keine Änderung dieser überlappenden Eigenschaften zulassen.

11. Beim Einrichten eines Decoders wird zuerst der Eingabetyp festgelegt. Danach sollte der Decoder nur Ausgabetypen bereitstellen, die er mit seinem aktuellen Eingabetyp unterstützen kann.

12. Die erwartete Eingabe für einen Encoder sollte 4:2:0 und mindestens NV12-Interlace/Progressive sein. Die erwartete Ausgabe ist ein komprimierter elementarer Stream im Format MPEG2 PS/TS oder H.264 Annex B.

13. Die erwartete Eingabe für einen Decoder ist ein elementarer Datenstrom. Die erwartete Ausgabe ist die nicht skalierte Version des Quellstreams als unkomprimierte NV12.

14. Pins an einem AVStream-Treiber sollten Zustände aufweisen, die voneinander unabhängig sind. Dies bedeutet, dass ein Eingabenadel vom KSSTATE_STOP zum KSSTATE_RUN wechseln kann, während der Ausgabestift im KSSTATE_STOP Zustand verbleibt.

15. Wenn der Minidriver GET-Anforderungen mit variablen Datenpuffergrößen empfängt, sollte der Minidriver einen NULL-Puffer als Abfrage für die Größe des erforderlichen Puffers interpretieren. In diesem Fall sollte der Treiber die erforderliche Länge im Feld Irp-IoStatus.Information> angeben und STATUS_BUFFER_OVERFLOW zurückgeben. Darüber hinaus sollte der Minidriver den Rückgabecode als Warnung und nicht als Fehler festlegen. Befolgen Sie z. B. diese Anleitung mit Datenschnitthandlern.