Support Request #93
closedProblems setting the offset
Added by hidden over 7 years ago. Updated about 7 years ago.
Description
Supportanfrage
Wir stoßen auf Probleme mit dem Workaround, solange #26928:[IADTFFileWriter]: Provide option to set offset - {HD - TicketID 23542LIHKL} nicht umgesetzt ist.
Es gibt einen "Workaround", den EB damals geliefert hat.
Dieser hat aber zur Folge, dass der erste Zeitstempel vom Ziel-DAT zum Original-DAT verändert wird.
Macht man den Workaround nicht, können auch neg. Zeitstempel auftreten.
Der Workaround sieht so aus:
while (IS_OK(m_datFileReader_p->Read(&l_pDataBlock))) // Iterate over all data blocks (this means independent of which stream they belong to)
{
tInt64 l_blkPos = m_datFileReader_p->GetCurrentBlockPos();
// Set the initial Offset to the 1st data block (workaround from EB)
if (1 == l_blkPos)
{
l_pDataBlock->SetFileTime(l_mediaDesc_p->tsOffset);
}
...
}
Lösung
Das Recorder Property use_sample_time ist auf true gesetzt.
Das erklärt die negativen Zeitstempel bei der Offsetkorrektur.
Dieses Property darf nicht verwendet werden für den Anwendungsfall, dies ist auch so in der Doku vermerkt.
Ticket wurde entsprechend bewertet.
Files
| LB_XL814_20160224_145147_Compressed_videoA_timestamps.txt (19.7 KB) LB_XL814_20160224_145147_Compressed_videoA_timestamps.txt | hidden, 2017-02-03 07:48 | ||
| LB_XL814_20160224_145147_Compressed_old_videoA_timestamps.txt (19.7 KB) LB_XL814_20160224_145147_Compressed_old_videoA_timestamps.txt | hidden, 2017-02-03 07:48 | ||
| diff.png (63.5 KB) diff.png | hidden, 2017-02-03 08:50 | ||
| use_sample_time.png (80.2 KB) use_sample_time.png | hidden, 2017-02-08 12:38 | ||
| 1st_sample_video_A.png (22.3 KB) 1st_sample_video_A.png | hidden, 2017-02-08 13:15 | ||
| LB-XL_814_20130913_103757_new.dat (303 KB) LB-XL_814_20130913_103757_new.dat | hidden, 2017-02-08 13:35 | ||
| dat_info.png (60.5 KB) dat_info.png | hidden, 2017-02-09 06:39 |
Updated by hidden over 7 years ago
- Status changed from Accepted to In Progress
- Support Level changed from 2nd Level to 3rd Level
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.
Updated by hidden over 7 years ago
Hallo Florain,
vielen Dank für die Bemühungen.
Grüße Gerd
Updated by hidden over 7 years ago
- Topic changed from Streaming::Common to StreamingLib::Writer
Updated by hidden over 7 years ago
Hallo Gerd,
Aktueller Stand
seitens CCB wird es vorerst keine Umsetzung des Tickets geben, eine neue Streaming Lib 2.x ist derzeit nicht geplant (Stand heute).
Weiteres Vorgehen
Wir versuchen einen verbesserten oder alternativen Workaround zu finden.
Sollte das nicht möglich sein, trage ich das nochmal so ans CCB.
Updated by hidden over 7 years ago
Hallo Florian,
danke, bin mal gespannt...
Gruß Gerd
Updated by hidden over 7 years ago
- Subject changed from Probleme beim Anpassen des Offsets to Problems setting the offset
- Status changed from In Progress to Customer Feedback Required
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...
Updated by hidden over 7 years ago
Hallo Florian,
wir verwenden hier gar keinen HD_Player! Es ist ein Kopieren, mit gleichzeitigem Komprimieren der Videobilder,
von einer in eine andere DAT, mit Hilfe der StreamingLib.
Der Issue kann öffentlich gemacht werden, da es ein gnerelles Problem ist?!
Gruß Gerd
Updated by hidden over 7 years ago
- Project changed from 5 to Public Support
- Status changed from Customer Feedback Required to In Progress
- Private changed from Yes to No
Updated by hidden over 7 years ago
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.
Updated by hidden over 7 years ago
- Status changed from In Progress to Customer Feedback Required
Hallo Gerd,
ich habe heute nochmal mit dem Fachmann gesprochen.
Nach wie vor ist das Produktticket offen, zum Setzen des OffsetsAls 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.
Nach Durchsprache mit dem Fachmann, dass Problem nachzuvollziehen, stellt sich uns mit dieser Aussage die Frage, wo ihr dann ein Problem habt ?- 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 !
Updated by hidden over 7 years ago
- File LB_XL814_20160224_145147_Compressed_old_videoA_timestamps.txt LB_XL814_20160224_145147_Compressed_old_videoA_timestamps.txt added
- File LB_XL814_20160224_145147_Compressed_videoA_timestamps.txt LB_XL814_20160224_145147_Compressed_videoA_timestamps.txt added
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;
}Updated by hidden over 7 years ago
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.
Updated by hidden over 7 years ago
Hallo, hier noch die EB Analyse von damals. Die Lösung/Workaround hat ja nur bedingt geholfen.
Hallo Herr Eichhorn, hallo Roland.
Nachdem ich jetzt hier euer Tool zum kompilieren bekommen habe und mit
zusätzlich einen kleinen Zeitstempel-Analyse-Filter implementiert haben, bin
ich schon um einiges weiter gekommen. Das Hauptproblem liegt wohl daran, dass
das erste Sample im Orginal-file vom Stream VIDEO_B ist. Dieses Sample hat als
Timestamp 11657. Wird nun das DAT-File repariert, also sampleweise kopiert,
dann wird dieser Wert als Offset verwendet. Das Problem kommt jetzt bei Sample
2 - N aus dem Stream CAN. Der Zeitstempel des 2. Samples (== das erste Sample
aus CAN) besitzt den Zeitstempel 0. Im reparierten File ist dieser Zeitstempel
natürlich immer noch gültig, aber der Offset liegt jetzt ja bei 11657. Daher
ist das zweite Sample zeitlich VOR dem Start der Sequenz und bekommt daher
einen negativen Zeitstempel.
Updated by hidden about 7 years ago
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?
Updated by hidden about 7 years ago
Hallo Gerd,
Gesetz dem Fall use_sample_time=true ist das der Grund und hierfür gibt es keinen weiteren Support.
Bitte prüfe das !
Wenn nicht, ist dies das weitere Vorgehen:
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).
Updated by hidden about 7 years ago
- File use_sample_time.png use_sample_time.png added
Updated by hidden about 7 years ago
- File 1st_sample_video_A.png 1st_sample_video_A.png added
- File LB-XL_814_20130913_103757_new.dat LB-XL_814_20130913_103757_new.dat added
Hier der Debug-Output beim Schreiben vom ersten Sample Video A.
Anbei der Anfang der besagten Sequenz
Updated by hidden about 7 years ago
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 ?
Updated by hidden about 7 years ago
Hallo Florian,
war nur zur Doku, da hier noch andere Leute mitlesen, sorry.
Wie die Datei aufgenommen wurde, lässt sich leider nicht mehr nachprüfen....
Updated by hidden about 7 years ago
- Resolution set to Not Supported Scope
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...
Updated by hidden about 7 years ago
Sorry, aber ich komme mit dem Export aus dem ShowDatFile Dialog nicht zurecht.... werde es Morgen nochmals probieren,
da ich jetzt weg muss.
Updated by hidden about 7 years ago
OK, kein Problem...
Ich nehme an du beschneidest es, da das File zu groß ist ?
Wenn ja, bitte mach noch einen oder ein paar Screenshot(s) vom Orignalfile im Show DAT File Info (am besten mit ADTF >= 2.13.x), so dass wir den Offset sehen und Zeitstempel erstes Sample usw...
Nicht dass der Datexporter hier schon was anpasst und das Ergebnis verfälscht...
Updated by hidden about 7 years ago
- File dat_info.png dat_info.png added
Hier die DAT-Info der originalen Datei.
Updated by hidden about 7 years ago
Hier ein neuer Versuch, einen Teil zu schneiden.
Updated by hidden about 7 years ago
Ich bekomme einen Fehler, obwohl die Datei nur 181MB hat. Maximum = 195MB ?!
Updated by hidden about 7 years ago
Hallo Gerd,
ich habe die Probleme auch aber einer gewissen Größe, allerdings nur von außerhalb, im LAN direkt geht es.
Die File Größe ist auch auf 200 MB konfiguriert, von demher passt es.
Ich vermute ein Timeoutproblem auf dem apache, da es "nur" von außen auftritt.
Sobald wir das Problem gefunden/gelöst haben, melde ich mich noch einmal.
Danke für deinen Hinweis !!!
PS: Wird Zeit dass unser Austauschserver bald funktioniert...
Updated by hidden about 7 years ago
Hallo Florian,
habe mal in der Messtechnik nachgeschaut und es ist beim HD_Recorder
das Flag use_sample_time=true gesetzt. Dann ist es ziemlich wahrscheinlich,
dass die Sequenz auch damit aufgenommen wurde....
Updated by hidden about 7 years ago
- Description updated (diff)
- Status changed from In Progress to To Be Closed
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.ä.
Updated by hidden about 7 years ago
- Status changed from To Be Closed to Closed
Supportfall abgeschlossen