Public Support

Hallo Gerd,

ich habe das Produktticket noch einmal ans CCB gegeben zur erneuten Bewertung.
Nächste Woche kann ich dazu mehr sagen, ob es ggf. einen Fix gibt, einen alternativen Workaround bzw. die Entscheidung ausfällt.
Vielleicht lässt sich der Offset noch auf irgendeinen Postprocess korrigieren, dazu kann ich dir aber so nicht konkreten ohne weitere Infos sagen.

Ich bitte dich daher noch um etwas Geduld.

Hallo Gerd,

lasst den Workaround bitte weg und stellt dann im Playback im Harddisk Player den reset_recording_offset auf false.
Damit wird der "falsche" Offset nicht abgezogen und die Zeitstempel sind korrekt bzw. es können keine negativen Zeitstempel auftreten.

Bitte um Feedback ob das Thema damit gelöst ist, ich habe die Ticketzeit auf Ende der Woche gesetzt.
Wenn ja auch die Frage, ob das Thema für alle Kunden sichtbar gemacht werden darf oder BOSCH exklusiv bleiben soll...

Hallo Gerd,

ich habe leider immer noch kein Feedback, da der Fachmann aktuell nicht erreichbar ist.
Ich bitte dich noch etwas um Geduld, ich bin an der Sache dran, leider haben die bisherigen Infos ja noch nicht weitergeholfen.

Hallo Gerd,

ich habe heute nochmal mit dem Fachmann gesprochen.

• #26928:[IADTFFileWriter]: Provide option to set offset - {HD - TicketID 23542LIHKL}

Als Lösung wurde vorgeschlagen, den Workaround von EB nicht anzuwenden und im Playback (Harddisk Player), wenn man das mit der Streaming Lib erzeugte DAT File wieder abspielt, das Property reset_recording_offset auf false zu setzen.

Das bringt euch laut Aussage nichts, weil ihr keinen Player verwendet, nur DAT nach DAT mit der Streaming Lib kopiert.

• Zeitstempel im DAT File selbst sind nie negativ
• Nur durch einen falschen Offset können sie ggf. negativ werden, allerdings nur durch Abzug des Offset im Playback -> ihr verwendet keinen Player

1) Wo tritt nun konkret euer Problem auf ?
2) Macht ihr selbst noch Zeitkorrekturen im Ziel DAT bzw. mit der Streaming Lib ? Die Streaming Lib macht das von Haus aus nämlich nicht...

Wie gesagt, sehen wir das nur im Playback relevant, deshalb beschreib doch noch einmal bitte im Detail, was ihr genau macht und wo ihr dann die Auswirkung habt, wenn ihr das File nicht abspielt...

Danke !

Das Problem hat damals ein indischer Kollege festgestellt, den ich aber nicht mehr kennengelernt habe, da er gekündigt hat.
Ganz nachvollziehen konnte ich es nie wirklich. EB hat das wohl besser verstanden?!

Habe ein Tool mit der StreamingLib geschrieben, welches die Zeitstempel der Video-Datenblöcke ausgibt.
LB_XL814_20160224_145147_Compressed_old_videoA_timestamps.txt zeigt die Video Zeitstempel vom originalen DAT
LB_XL814_20160224_145147_Compressed_videoA_timestamps.txt zeigt die Video Zeitstempel vom kopierten DAT (ohne den EB workaround)

Man sieht, dass der tsOffset verändert ist und damit der erste FileTimeStamp ebenfalls und es ergibt sich dadurch ein
anderes Delta zwischen den ersten beiden Samples. Wie gesagt, es werden hier nur die Video A Samples ausgewertet.

Die Frage ist, woher dieses Verhalten kommt?

Ob der EB workaround wirklich eine Lösung ist, weiß ich nicht...

Nach der Kompression der Videodaten wird ein Vergleichstool aufgerufen, und dieses stellt eben einen Unterschied bei der FileTime
des ersten Datenblock fest, den wir aktuell tollerieren (müssen).

Hier noch der Code zum kopieren des Media Descriptors, was aber vermutlich damit nichts zu tun hat:

//****************************************** Record description ******************************************//

static const tADTFMediaDescriptor* l_mediaDesc_p = m_datFileReader_p->GetMediaDescriptor();

if (nullptr == l_mediaDesc_p)
{
        outputLogEntry(LOG_SOURCE_COMPRESSION_TOOL, LOG_CLASS_ERROR, "Function GetMediaDescriptor() failed");
        return false;
    }

tResult l_Result = m_datFileWriter_p->SetMediaDescription(l_mediaDesc_p->strShortDesc, l_mediaDesc_p->strLongDesc, &(m_datFileReader_p->GetMediaDescriptor()->sDateTime));
    if (ERR_NOERROR != l_Result)
{
        outputLogEntry(LOG_SOURCE_COMPRESSION_TOOL, LOG_CLASS_ERROR, "Function SetMediaDescription() failed");
        return false;
    }

Martin, kannst du hier mal bitte einen Blick drauf werfen ?
Die Frage wäre noch, was beim Kopieren ggf. noch an anderen Stream Daten hinzukommt, dann könnte sich der Offset ändern...

Es ändert sich auch "nur" die FileTime des ersten Samples, der Rest ist gleich.

Ich kann leider nichts in der Streaming Lib entdecken, dass das erklären könnte. Insbesondere gibts genau für diesen Fall einige Tests, die unter anderem die Zeitstempel nach einem kopieren vergleichen.

Vielleicht ist folgendes auf Kundenseite möglich:

Im Konvertierungstool entweder per Logging oder Debugging herrausfinden welche Zeitstempel beim ersten Sample von Video_A an die IADTFFileWriter::Write Methode übergeben werden. Diese müssten sich mit der Ausgabe in LB_XL814_20160224_145147_Compressed_videoA_timestamps.txt decken. Wenn dem nicht so ist, bräuchten wir die Augangs-Dat-Datei, dann können wir versuchen das selbst nachzustellen (auch ohne das Konvertierungstool).

@Florian:
Die Daten sehen so aus, als wären sie in einem Recorder mit "use_sample_time=true" aufgezeichnet worden, soweit ich mich erinnere fällt das nicht mehr in den Supportbereich, oder?

Hier der Debug-Output beim Schreiben vom ersten Sample Video A.
Anbei der Anfang der besagten Sequenz

Hallo Gerd,

mir ist nicht ganz bewusst, was du uns kommentarlos mit dem Screenshot der Property aus der Doku mitteilen willst, die Frage war eigentlich, ob dieses Property gesetzt war oder nicht.

Die Doku dazu ist mir bekannt, dass Property ist auch nur für Audio Streams gedacht, ansonsten verfälscht es wie in der Doku beschrieben die Zeitstempel, steht so in der Doku (siehe Screenshot), ist deshalb auch mittlerweile deprecated und somit auch kein Support,da Verwendung aus genannten Gründen auf eigene Gefahr.
Aufgrund der Daten die uns bisher geschickt hast haben wir die Annahme wie Martin bereits geschrieben, dass dies gesetzt war.

Oder hätte ich deine letzte Nachricht anders deuten sollen ?

Wie die Datei aufgenommen wurde, lässt sich leider nicht mehr nachprüfen....

Gut, dann gehen wir mal davon aus, dass dem so ist dass unsere Vermutung korrekt ist.
Um euch weitere Hinweise geben zu können, bräuchten wir dann aber das Ausgangsfile.

Das File das du uns geschickt hast, ist a) bereits bearbeitet, wie man an der History sieht und b) hat es weder einen Offset (Offset = 0) noch enthält es Samples (leere Streams).
Das hilft natürlich nicht...

Hier die DAT-Info der originalen Datei.

Hallo Gerd,

ja das erklärt wie gesagt den negativen Zeitstempel bzw. die "falschen" Werte.
Bitte das Property nicht verwenden für euren Anwendungsfall.

Mehr können wir auch nicht mehr hier beitragen, wurde ja auch schon entsprechend bewertet.

PS: An der Thematik mit dem Upload-Problem sind wir dran, haben aber bisher noch keine Lösung.
Wir hoffen auch auf baldige Verfügbarkeit eines Austauschservers a la SendTo o.ä.

Supportfall abgeschlossen