Public Support

Supportanfrage

ich bin bei der Entwicklung von Komponenten für die aktuelle 3er Version auf einige Unklarheiten gestoßen, die ich auf diesem Wege versuchen möchte aufzuklären:

1. Mir ist die Verwendung der Funktion create_adtf_default_stream_type (media_description_type.h) nicht klar. Ich hätte erwartet, dass ich einfach eine IStreamType-Instanz zurückgegeben bekomme, allerdings erwartet die Funktion selbst in der Überladung ohne die cSampleCodecFactory-Referenz die Angabe von strStructName und strMediaDescription. Was passiert hier im Hintergrund? Muss bzw. kann ich das Verhalten für meine eigenen Streamtypen reproduzieren?
2. Wie wird die Kompatibilität zwischen zwei Pins festgestellt? Im Configuration Editor war es mir ohne weiteres möglich, einen Out-Pin meiner Streaming Source im Streaming Graph mit einem In-Pin eines Filters im Filter Graph zu verbinden, für den ich einen anderen Streamtypen gesetzt hatte.
3. Welche Rolle spielen Mediadescriptions überhaupt? Werden sie in irgendeiner Form zur Validierung oder sonstiger Logik herangezogen? Oder habe sie nur einen deklarativen Zweck?

Lösung

Zu 1.) Das ist nur eine Hilfsfunktion:

tResult create_adtf_default_stream_type(const tChar* strStructName, const tChar* strMediaDescription,
                                        ucom::iobject_ptr<adtf::streaming::IStreamType>& pStreamType,
                                        ddl::tDataRepresentation eRep)
{
    ucom::object_ptr<adtf::streaming::IStreamType> pType =
            ucom::make_object_ptr<adtf::streaming::cStreamType>(stream_meta_type_default());
    RETURN_IF_FAILED(set_stream_type_media_description(*pType, strStructName, strMediaDescription, eRep));
    pStreamType.Reset(pType);
    RETURN_NOERROR;
}

Die macht also nichts anderes als einen neuen Stream Type zu erzeugen (mit Metatyp "adtf/default") und dann die 3 Properties zu setzen.

So etwas kann man für seine eigenen Stream Types machen, muss man aber nicht.

2.) Die Kompatibilität wird erst zur Laufzeit überprüft. Das ist auf die Design Entscheidung zurückzuführen, dass sich Stream Types im Lauf der Zeit ändern dürfen. Dadurch lassen sich insbesondere Zyklen im Graph leichter realisieren, bei denen bei Filtern die Datenbeschreibung der Outputs von denen der Inputs abhängen.

Die Überprüfung wird standardmäßig über den Meta Typ realisiert, man kann aber bei einem Reader auch mittels SetAcceptTypeCallback eine eigene Funktion dafür registrieren.

3.) Die Media Description hat in erster Linie den Zweck alle Daten allgemein verarbeiten zu können. Sie richtet sich hier natürlich an Visualisierungen. Aber da sie auch eine De-/Serialisierung beschreibt, kann sie auch dafür verwendet werden (im Recorder oder den IPC Sourcen und Sinks). Sie ermöglicht es auch allgemeine exporter (über adtf_file/adtfdat_processing) in verschiedene Formate (MDF, HDF, CSV, ...) zu implementieren.

Sie ist daher nicht notwendig um einen Filter Graphen zu bauen, der einfache Regelungstätigkeiten übernimmt. Aber wenn man die Daten mit weiteren Standard ADTF Komponenten verarbeiten oder visualisieren will ist sie von großem Nutzen.