erwin Posted February 9, 2010 Share Posted February 9, 2010 Ich versuch gerade für ein Plugin (TimeshiftPlus) die aktuelle Wiedergabeposition für den Datamanager verfügbar zu machen. Als Reference dafür benutze ich die PCR-Timestamps im Stream. Diese können allerdings Sprünge aufweisen. Teilweise werden diese Sprünge im DVBV-Sourcefilter behandelt (PCR/PTS-Gap) und kommen somit gar nicht bis in den Timeshiftdatenstream. Meine Frage nun an die Entwickler, mit welchen Unregelmäßigkeiten in der PCR-Reference muss ich rechnen und welche werde ich garantiert in den Timeshiftdaten nicht auffinden da sie bereits vorher behandelt wurden. mfg und thx erwin Quote Link to comment
Derrick Posted February 9, 2010 Share Posted February 9, 2010 Generell muss mit einem wrap around der zeitstempel gerechnet werden. Eine statistische analyse, wie oft und wann das vorkommt, kenne ich nicht. Der DVBViewer manipuliert die daten während der aufnahme (und sonst auch) nicht. Also wird dir nichts vorenthalten Bei VOD werden sendungen manchmal in einer schleife gesendet, sodass die pcr bewusst springt. Das wird aber mit einer discontinuity angezeigt. Quote Link to comment
erwin Posted February 9, 2010 Author Share Posted February 9, 2010 Dank dir erstmal. Generell muss mit einem wrap around der zeitstempel gerechnet werden. Eine statistische analyse, wie oft und wann das vorkommt, kenne ich nicht. Wenn sonst keine Sprünge vorkämen ist die Wrap-Periode gigantisch. ( 2 ^ 33 / 90000 )-Sekunden. Selbst wenn man diesen Fall nicht behandeln würde. Es würd fast keiner merken da extrem selten. Der DVBViewer manipuliert die daten während der aufnahme (und sonst auch) nicht. Also wird dir nichts vorenthalten Die Daten direkt nicht (oder doch den PCR?). Allerdings bei zu großen (was immer das heist) PCR/PTS-Gaps löst der DVBV-Filter ein "Rebuild Graph" aus, was zu einem Reset von Timeshift führt. Mit anderen Worten, in den aktuell vorhandenen Timsehiftdaten ist dieses Ereignis per PCR nicht nachvollziehbar. Das wird aber mit einer discontinuity angezeigt. Dahin ging meine Frage. Wenn discontinuity-Flag gesetzt ist, löst dann der DVBV-Filter ein "Rebuild Graph" aus? Oder erst wenn mehr als x-Sekunden Gap? Also wann genau "Rebuild Graph" und wann wird was durchgereicht? erwin Quote Link to comment
Derrick Posted February 9, 2010 Share Posted February 9, 2010 Da ich timeshift praktisch nie verwende, kann ich darüber auch nichts sinniges sagen. Nur ist ein wrap around was anderes als ein gap, es sei denn, die lücke ist > 26,5h Ansonsten muss @Griga hier übernehmen Quote Link to comment
Derrick Posted February 9, 2010 Share Posted February 9, 2010 Wenn discontinuity-Flag gesetzt ist, löst dann der DVBV-Filter ein "Rebuild Graph" aus? Oder erst wenn mehr als x-Sekunden Gap? Also wann genau "Rebuild Graph" und wann wird was durchgereicht? Das hatte ich übersehen. Nein, dieses flag wird vom DVBViewer gar nicht berücksichtigt. Könnte man checken, aber bis auf wenige ausnahmen (time-base discontinuities) wie beim genannten VOD kommt es ja auch nicht vor. Quote Link to comment
Griga Posted February 9, 2010 Share Posted February 9, 2010 Wenn sonst keine Sprünge vorkämen ist die Wrap-Periode gigantisch. ( 2 ^ 33 / 90000 )-Sekunden. Ungefähr 26:30 Stunden würde ich nicht gigantisch nennen. Wenn du die Sender durchschaltest und dabei die PCR auf der Eigenschaftsseite des DVBViewer Filters beobachtest, wirst du wahrscheinlich einen finden, der nahe dran ist. Ich könnte auch ein TS-Sample zur Verfügung stellen, das einen Wrap Around enthält. Wenn ein Wrap Around auftritt, sorgt der DVBSource dafür, dass die intern verarbeiteten PCRs trotzdem monoton steigen, indem er einen (anfangs mit 0 initialisierten) Offset berechnet PCR_ofs = PCR_ofs + 2^33 / 90000 und ihn auf nachfolgende PCRs anwendet PCR_out = PCR_in + PCR_ofs Ein solcher Sprung ist nicht als Diskontinuität zu werten. Alle anderen, bei denen die PCR eine Lücke von mehr als 3 Sekunden aufweist if Abs(PCR_out - Previous_PCR_out) > 3 * 90000 then //PCR discontinuity betrachtet der DVBSource bei Live-Betrieb als potentielles Unglück und schickt eine Message an die App. Bei Dateiwiedergabe (inklusive Timeshift) bügelt er dagegen sowas stillschweigend aus, und zwar, indem er die "sprunghafte" PCR_in verwirft und als Output den letzen PCR-Wert Previous_PCR_out wiederholt. Zuvor wird ein neuer Offset berechnet, der auch hierbei für Monotonie sorgt: PCR_ofs = Previous_PCR_out - PCR_in PCR_out = Previous_PCR_out Kurz gesagt wird der Offset so berechnet, dass, wenn man ihn auf die neu eingetroffene "sprunghafte" PCR anwenden würde, sich genau Previous_PCR_out ergibt. Auf nachfolgend eintreffenden PCRs wird dann wie ansonsten auch der (neue) Offset angewandt: PCR_out = PCR_in + PCR_ofs Das gleiche Verfahren kommt für jeden Stream separat bei den PTS zum Zuge, aufgrund der Erfahrung, dass ein DirectShow-Graph mit sich wiederholenden Zeitstempeln zurechtkommt, aber nicht mit einem Sprung, der die Wiedergabe i.a. zum Erliegen bringt. Bei Live-Betrieb kann man Zeitstempel-Diskontinuitäten nicht so glattbügeln, weil sie auch durch eine Signalunterbrechung entstehen können, während der die Streamtime im Filtergraphen weiterläuft. D.h. die offset-korrigierten Zeitstempel würden nach ihrer Umsetzung in DirectShow-Zeitstempel nicht mehr passen. Der DVBSource zeigt auf seiner Eigenschaftsseite die PCR immer unkorrigiert an (also auch ohne Wrap-Korrektur), die PTS im Anzeigemodus "DVB" dagegen mit einer (eventuellen) Korrektur. Damit hat man eine Vergleichsmöglichkeit. Die Korrektur findet nur innerhalb des DVBSource für seine eigenen Zwecke statt, beeinflusst also nicht den TS, den der DVBViewer bei Aufnahmen schreibt oder sonstwohin verteilt. Allerdings bei zu großen (was immer das heist) PCR/PTS-Gaps löst der DVBV-Filter ein "Rebuild Graph" aus Tut er nicht. Die Message veranlasst den DVBViewer, den Filtergraphen in den Stop-Zustand zu versetzen und sofort danach ein Run auszuführen. Dadurch wird der Graph quasi zurückgesetzt, die Streamtime beginnt wieder mit 0, und der DVBSource berechnet den Offset für die Umsetzung der DVB-PTS in streamtime-relative Zeitstempel neu. Quote Link to comment
erwin Posted February 10, 2010 Author Share Posted February 10, 2010 Dank dir Griga für die kompetente und sehr aufwendige Antwort. Danke. Ich hab das jetzt zusammenfassend so verstanden, dass bei Timeshift zunächst unabhängig von Wraps oder Sprüngen im PCR der TS *unverändert* (bezüglich des PCR im Adaptionsfeld) in die Datei geschrieben wird und erst dann beim Zurücklesen durch den DVBV-Source die beschriebenen Korrekturmassnahmen greifen. erwin Quote Link to comment
Griga Posted February 10, 2010 Share Posted February 10, 2010 Das hast du richtig verstanden. Das Problem, das im DVBSource zu lösen war und wohl auch von dir zu lösen ist: Wie mache ich aus dem Schrott, der als PCR eintrudelt, eine vernünftige Uhr? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.