[Bug 675132] tsdemux: implement proper seeking with binary search and keyframe detection
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Mon Oct 28 07:29:38 CET 2013
https://bugzilla.gnome.org/show_bug.cgi?id=675132
GStreamer | gst-plugins-bad | git
Edward Hervey <bilboed> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bilboed at bilboed.com
--- Comment #6 from Edward Hervey <bilboed at bilboed.com> 2013-10-28 06:29:32 UTC ---
Update from discussions I had with Matej at the GStreamer conference:
Having a completely different codepath for "scanning for seeking" introduces
too much complexity.
There already is code which waits until a certain item (we have a PCR to
calculate the proper stream time and PTS/DTS) before pushing downstream
reconstructed packets. Search for ->pending_ts and ->pending to see what's
going on.
We should re-use this logic to do "scanning" instead of having a dedicated
codepath for doing header/packet/keyframe scanning. The reason is that
currently most of the overhead in tsdemux is due to i/o latency, which you
won't avoid by scanning 4-10 bytes out of 188 bytes. Furthermore by letting all
data go through the current "regular" codepath it allows all pieces of code to
collect more information (and therefore get a better byte offset the following
time round).
Changes:
* If seeking and reconstructing buffers, activate h264/mpeg2 header scanning
(and only in those cases).
* If doing accurate seek (and only then), once we have enough time information
determine whether we are at/before the requested seek location and we have a
keyframe. If we are, let the buffers go through. If we are not, re-request a
new byte offset from the packetizer (it will have a better estimation now),
drop pending buffers and carry on grabbing data from that location.
Note that we could also use that last item for non-accurate seeks if we end up
really too far from target seek time (say > 10s).
--
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