Public Support

Supportanfrage

ich habe einen Stream, der MediaSamples überträgt, die sich zwar einen gemeinsamen Header teilen, aber abhängig vom dort enthaltenen Typ und payload anders interpretiert werden müssen. Unten findet sich ein vereinfachtes Beispiel.
Wie geht man bei der Typdefinition in ADTF3 damit am besten um?

Konkreter:

• Ist es okay, wenn eine MediaDesription nur den Beginn eines MediaSamples beschreibt? Damit wäre die größe der beschriebenen Daten kleiner als das tatsächliche MediaSample
• In ADTF2 wurde aus Performancegründen von dynamischen Beschreibungen (Größe eines Arrays abhängig von einem Wert im Header) abgeraten. Gilt das weiterhin für ADTF3?
• Sollte ich in dem Fall sicherheitshalber komplett auf MediaDescription verzichten?

Vereinfachtes Beispiel. Inhalt des Streams sind MediaSamples vom Typ tDataA oder tDataB.

struct tHeader
{
    uint32_t type;
    uint32_t payload; // Big Endian
};

struct tDataA
{
    tHeader header;
    uint8_t data;
}

Struct tDataB
{
    tHeader header;
    uint32_t other_data[42];
}

Lösung

mit den Ethernet- sowie SOME/IP-Samples in der DevTb verhält es sich ähnlich.

Für Raw-Ethernet-Samples schauts konkret so aus:

Das Sample besteht aus einen Header mit fester Struktur, definiert von der DevTb, sowie dem eigentlichen Ethernet-Frame, der je nach Protokoll ganz unterschiedlich aussehen kann.
Die Mediadescription beschreibt nur den Sample-Header detailliert -
der Ethernet-Frame wird als Array beschrieben, dessen Länge im Header steht.

Nach meinem Kenntnisstand hält sich der Performance-Overhead dieser 'dynamischen' Array-Beschreibung in Grenzen, solange sich das Array ganz am Ende des Samples befindet.

Um nochmal explizit auf deine Fragen einzugehen:

Eine Mediadescription, die nur den Anfang des Samples beschreibt, ist mMn technisch unproblematisch.
Wenn möglich rate ich aber, das ganze Sample zu beschreiben indem du hinten ein dynamisches Array in die Beschreibung aufnimmst -
dann passt auch die Länge.
Die Performance sollte dadurch nur unwesentlich sinken.

Im Zweifel ist eine partielle Mediadescription besser wie gar keine -
so können Komponenten, die auf DDL-Basis arbeiten (z.B. das Media Description Display) zumindest eingeschränkt mit dem Sample was anfangen.

struct tEthernetSampleHeader
{
    tInt64 tmTimestampBeginNs = 0;
    tInt64 tmTimestampEndNs = 0;
    tInt32 nErrorCode = 0;
    tUInt32 nFrameCheckSequence = 0;
    tUInt32 nFrameSize = 0;
    tUInt8 aFrameData[0];
};

<structs>
    <struct name="tEthernetSample" version="1" ddlversion="4.0">
        <element name="tmTimestampBeginNs" type="tInt64" arraysize="1">
            <deserialized alignment="1"/>
            <serialized bytepos="0" byteorder="LE"/>
        </element>
        <element name="tmTimestampEndNs" type="tInt64" arraysize="1">
            <deserialized alignment="1"/>
            <serialized bytepos="8" byteorder="LE"/>
        </element>
        <element name="nErrorCode" type="tInt32" arraysize="1">
            <deserialized alignment="1"/>
            <serialized bytepos="16" byteorder="LE"/>
        </element>
        <element name="nFrameCheckSequence" type="tUInt32" arraysize="1">
            <deserialized alignment="1"/>
            <serialized bytepos="20" byteorder="LE"/>
        </element>
        <element name="nFrameSize" type="tUInt32" arraysize="1">
            <deserialized alignment="1"/>
            <serialized bytepos="24" byteorder="LE"/>
        </element>
        <element name="aFrameData" type="tUInt8" arraysize="nFrameSize">
            <deserialized alignment="1"/>
            <serialized bytepos="28" byteorder="LE"/>
        </element>
    </struct>
</structs>