Public Support

Hallo Clemens,

wichtig bei der Implementation ist zu beachten, dass der Stream Type als Entität über einen Sample Stream transportiert wird (siehe: Doku). Das heißt, wenn sich der Stream Type in einem Sample Stream immer wieder ändert, muss man bei der Filter Implementation auch auf diese Änderungen reagieren (z.B. AcceptType)

• Senden alle Filter unterschiedliche Stream Types oder alle den gleichen?
• Gibt es einen Grund dafür, dass alle Samples auf einem Input Pin empfangen werden müssen?
• Kennst du die Funktionalität der "Dynamic Pins" in ADTF?

Dynamic Pins

Hiermit kann man beliebig viele Pins von beliebigen Typen im Configuration Editor mit z.B. einem Filter verbinden. Im Code kann man dann zur Laufzeit via RequestDynamicInputPin oder RequestDynamicOutputPin pro angefragtem/verbundenem Pin darauf reagieren und entsprechend eine der CreateInputPin(...) oder CreateOutputPin() Funktionen aufrufen.

Hallo Rick,

1.: Alle Eingangsdaten sind vom gleichen Typ. Es muss also kein AcceptType() überschrieben werden.
2.: Das spart in unserer Konfiguration das Konfigurieren von sehr vielen Verbindungen. So müssen alle Verbindungen bis zum Filter durchgeschleift werden und das durch mehrere Sub-Graphen. In ADTF2 hatte uns das an vielen Stellen den Konfigurationsaufwand erleichtert.
3. "Dynamic Pins" kennen wir. Das wäre die Alternative, um beliebige Eingangspins zu konfigurieren.

Wäre alternativ ein erweiterter SampleStream denkbar, auf dessen Sample-Queue mehrere Writer schreiben können? Ähnlich wie das folgendes Darstellung suggeriert: Sample Stream

Hi zusammen,

nein so einen Sample Stream wird es nicht geben. Sample Streams bilden nie eine Logik ab. Das braucht's in dem Fall aber.

Was es aber geben wird, ist ein Filter der beliebig viele Eingangspins auf einen Ausgangspin mapped. Der kann sich dann korrekt darum kümmern, dass die Daten wirklich zueinander passen und sich auch um die Trigger kümmern. Darum geht's in dem erwähnten Ticket ACORE-10391.

Wenn ihr jetzt eine Lösung braucht, dann könnt ihr folgendes ausprobieren

#include <adtffiltersdk/adtf_filtersdk.h>

using namespace adtf::util;
using namespace adtf::ucom;
using namespace adtf::base;
using namespace adtf::streaming;
using namespace adtf::filter;

class cStreamMerger: public cFilter
{
public:
    ADTF_CLASS_ID_NAME(cStreamMerger,
                       "stream_merger.filter.adtf.cid",
                       "Stream merger");
public:
    cStreamMerger()
    {
        m_pWriter = CreateOutputPin("output");
    }

    tResult RequestDynamicInputPin(const tChar* strName,
                                   const iobject_ptr<const IStreamType>& pType) override
    {
        CreateInputPin(strName, pType);
        RETURN_NOERROR;
    }

    tResult AcceptType(ISampleReader* /*pReader*/,
                       const iobject_ptr<const IStreamType>& pType) override
    {
        m_pWriter->ChangeType(pType);
        RETURN_NOERROR;
    }

    tResult ProcessInput(ISampleReader* /*pReader*/, const iobject_ptr<const ISample>& pSample) override
    {
        m_pWriter->Write(pSample);
        RETURN_NOERROR;
    }

private:
    ISampleWriter* m_pWriter = nullptr;
};

Wie ihr seht, schert sich der gar nicht um die Typen, das heißt da müsst Ihr dann selber sehr genau drauf schauen, dass das passt.

Hoffe das hilft fürs erste,

Grüße,

Martin

Wenn ihr was Ähnliches für unterschiedliche Daten haben wollt, seht Euch bitte die Substreams in ADTF 3.7 an.

Hallo Martin,

danke für deine Antwort. Die Aussage ist auf jeden Fall eindeutig.
Der Filter hilft auf jedem Fall bei genau dem Problem.

Vielen Dank.
Damit kann das Ticket dann zu.