Project

General

Profile

Actions

Support Request #590

closed

ADTFS-46662 Mapping and handling for legacy media types

Added by hidden about 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Customer:
ELEKTROBIT
Department:
SUPPORT
Requester's Priority:
Normal
Support Level:
3rd Level
Resolution:
Product Issue Opened
Affected Products:
Platform:
Ubuntu 16.04 64bit, Windows 7 64bit
Topic:
ADTF::Common
FAQ Links:

Description

Supportanfrage

Hallo,

in der Doku findet man zu den Legacy Mediatypes etwas widersprüchliche Infos.
doc/adtf_html/page_adtf2_serializer_support.html
doc/adtf_html/page_porting_adtf2.html

Das Handling beim Playback von .dat-Files scheint aber wiederum anders gelöst.

1. Hier wäre etwas verbesserte Dokumentation sinnvoll. Auch das generelle Konzept von Mediatypes wird bisher vor allem dadurch beschrieben, dass es besser als in ADTF 2 ist und sich an gstreamer orientiert. (gstreamer müsste man sich da aber auskennen)
doc/adtf_html/page_stream_type.html

2. Das Mapping das der ADTF Playback Input durchführt, sollte dokumentiert, oder idealerweise durch ein Header-File zur Verfügung gestellt werden. Sonst muss man da jeweils mühsam reverse engineering machen. Meine Beobachtung war z.B. folgendes:

A. ADTF 2 Media Type
MEDIATYPE_STRUCTURED_DATA /MEDIA_SUBTYPE_FLOAT_64
wird
ADTF 3 Stream Type
stream_type_plain<tFloat64>

Entsprechendes mit MEDIA_SUBTYPE_FLOAT_32

B. MEDIATYPE_NETWORK_DATA/MEDIA_SUBTYPE_NETWORK_DATA_IP
wird
zu "adtf2/legacy metatype"

C. Und
0/0
wird
auch zu "adtf2/legacy metatype"
(noch nicht gecheckt, wo da die description landet)

Das Vorgehen bei A. (weil kein legacy medatype) und bei C. (keine adtf_default_sream_type) widerspricht den Empfehlungen in doc/adtf_html/page_porting_adtf2.html

3. Auf einen legacy filter schein ein falscher Mediatype auf dem Input Pin keine Auswirkungen zu haben. Ich hab das mit dem demo legacy data filter ausprobiert: der verarbeitet alle ADTF 2 Streams ohne mucken, der Returnwert von OnTypeChanged hat keine Auswirkungen.

Grüße,
Jochen

Lösung

Erstmal zum Mapping, das mit Akzeptieren aller Typen muss ich erst noch nachstellen.

  • adtf.core.media_type
    • MAJOR = MEDIA_TYPE_STRUCTURED_DATA und Sub = MEDIA_SUBTYPE_STRUCT_UINT8, MEDIA_SUBTYPE_STRUCT_UINT16, MEDIA_SUBTYPE_STRUCT_UINT32, MEDIA_SUBTYPE_STRUCT_UINT64, MEDIA_SUBTYPE_STRUCT_FLOAT32, MEDIA_SUBTYPE_STRUCT_FLOAT64
      -> stream_type_plain<Type>
    • ansonsten stream_meta_type_legacy mit major und minor.
      • Falls DDL verfügbar wird diese auch übernommen.
  • adtf.type.video
    • stream_meta_type_image
  • adtf.type.audio
    • stream_meta_type_audio

Für alle anderen ADTF2 Media Typ Klassen, muss es dann auch eine entsprechende Deserialisierung in ADTF 3 geben.

Für adtf.core.media_type heißt das, für alles wo es eine direkte Entsprechung in ADTF 3 gibt mappen wir das, der Rest wird legacy.

-> http://km-aev.in.audi.vwg/redmine/issues/40228

Es gibt in ADTF 3 leider noch kein default Handling wenn während des Streamings etwas schief geht. Um den Fehler selber abzufangen könnt z.b. im angesprochenen demo legacy data filter folgendes in der Init Methode machen.

        RETURN_IF_FAILED(m_oInputPin.Create("input", pType));
        m_oInputPin.SetStreamErrorCallback([](tResult oStreamError) -> tResult
        {
            // error handling here
            LOG_RESULT(oStreamError);
            _runtime->SetRunLevel(adtf::base::tADTFRunLevel::RL_Session, tFalse);

            return oStreamError;
        });

Ziel ist es hier in Zukunft einen zentralen Error Handler zu haben.

Actions

Also available in: Atom PDF