[Bug 670080] Seeking problems on recorded mpegts streams

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed May 2 05:19:25 PDT 2012


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

--- Comment #3 from Holger Kaelberer <hk at getslash.de> 2012-05-02 12:19:21 UTC ---
Created an attachment (id=213275)
 View: https://bugzilla.gnome.org/attachment.cgi?id=213275
 Review: https://bugzilla.gnome.org/review?bug=670080&attachment=213275

fix seeking on recorded live streams

This patch fixes the problem for us. 

For a more detailed description cf. git log in attached patch. We use this on
different kind of streams (live, httpsrc) in production environment and
consider it therefore tested.

I know mpegtsdemux is about to die, but anyway ask you to consider it for
upstream, as long as tsdemux shows the same problem and does not support
everything mpegtsdemux does.

This was ported fluendo's flutsdemux, Julien Moutte gave us an ok for posting
this here. Shouldn't be a license problem as mpegtsdemux is already doubly
licensed, no? Credits go to Fluendo! ;-)

Regarding tsdemux: I only had time to give a quick look and it seems to show
exactly the same behaviour as mpegtsdemux on the recorded live streams:
calculation of lower segment boundary as calculated after seeking is too low
with respect to the first buffers arriving, which are in turn dropped due to
clipping in the decoder. The same approach taken for mpegtsdemux (resetting
base-pts, in post seeking processing) might also help for tsdemux.

-- 
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.


More information about the gstreamer-bugs mailing list