[Bug 674536] tsdemux: Freeze on pts-wrap with streaming sources

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=674536
  GStreamer | gst-plugins-bad | git

--- Comment #19 from Holger Kaelberer <hk at getslash.de> 2012-06-28 14:16:34 UTC ---
(In reply to comment #18)
> If the absolute difference is very close to the maximum PCR value (let's say a
> diff of 1 << 30 for example), then we should bump up/down by the maximum PCR
> value because it means it is very probable that it is an actual pcr wraparound.

Ok, this should not interfere with the video-loop use-case where you can expect
resets about 30sec to 2h or so.

> 
> The question is what to do with values in between (i.e. it's not a glitch and
> it's not a compliant wrap-around).

Well that's what I tried to answer with the submitted patch: track the exact
pcr_diff after (multiple) timestamp resets and account for in calculating
current gstpcr values (calculate_skew())

... AND do the same for the PTS (gst_ts_demux_record_pts()).

Not sure if you can go with the latter only as does mpegtsdemux/flutsdemux that
seem to handle ts discontinuities only by updating stream->base_time. Actually
the observed freeze was triggered by too high PTS after the reset, because
gst_ts_demux_record_pts() handles discontinuities >10sec as rollovers of about
PTS_DTS_MAX_VALUE. But not when not tracking pcr resets I found
calculate_skew() falling in other cases like basetime or skew reset, breaking
the corrected PTS calculation.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.