Support Request #7789
closedStreamTime acting in a Playback Config
Description
Support Anfrage:
Ich habe eine Config mit einem HD-Player und einem Filter, in dem ein cKernelTimer mit 10 ms timeout läuft.
In der Timer-Methode wird geprüft, wie viel Zeit zwischen dem aktuellen und dem letzten Aufruf vergangen ist.
Da kommt öfters mal 0 als Differenz raus, was für den darin laufenden Algo ein Problem darstellt.
Das DAT-File beinhaltet mehrere Streams, die schnellste Update-Rate eines Streams beträgt im Mittel 10 ms.
Der HD-Player aktualisiert die StreamTime nur, wenn er ein MediaSample verschickt. (Richtig?)
Die Datenrate der Streams schwankt aber leicht.
Wenn zwischen zwei Updates nur 9 ms vergangen sind, reicht das natürlich nicht um den cKernelTimer erneut zu triggern.
Danach kommt dann z.B. ein neues Update 11 ms später, die StreamTime wird direkt um 20 ms erhöht und der cKernelTimer direkt zweimal hintereinander getriggert. Zweimal mit der gleichen StreamTime.
Gibt es eine vernünftige Lösung, dass der cKernelTimer trotzdem zwischendrin getriggert wird?
Ich hatte mal aus einem anderen DAT-File einen Stream mit höherer UpdateRate reingemerged. Das löst das Problem, ich betrachte das allerdings nicht als 'vernünftige Lösung' ;)
Lösung:
Die Stream Time wird diskret vor jedem verschickten Sample erhöht. Der Kernel wird synchron über diesen Zeitsprung informiert und überprüft dann welche Timer in der Zeitspanne hätten laufen sollen. Leider hat er dafür nur den letzen und den neuen Zeitstempel zur Verfügung. Er kann also leider nur die Anzahl der notwendigen Timer-Aufrufe feststellen. Selbst wenn er dabei die Zeit interpolieren würde, kann er die Stream Time nicht mehr in die Vergangenheit zurücksetzen, damit ein pClock->GetStreamTime() im Anwender Code den passenden Zeitstempel liefert.
Also ja, die Genauigkeit, der Timer hängt von der maximalen Datenrate im DAT-File ab. (Das ist ein Punkt der in ADTF 3 besser gelöst wird, da hier auch die Trigger von Verarbeitungsketten mit aufgezeichnet werden).
Leider bleiben nur die zwei Möglichkeiten:
- zum einen den Algorithmus so anzupassen, dass eine Zeitdauer zwischen den Aufrufen von 0 kein Problem darstellt (das könnte theoretisch auch im Live-Betrieb auftreten wenn der OS-Kernel durch die Last nicht nachkommt)
- so wie beschrieben höherfrequente Datenströme mit aufzeichnen/einfügen. Da oft ein CAN oder Flexray Bus mit aufgezeichnet wird, kommt das Problem in anderen Use-Cases nicht so sehr zum tragen.
Zusätzlich wurde das Produktticket ACORE-10107 Playback: Improve Timer Handling erstellt.
Siehe Kommentar 14