[Bug 675132] tsdemux: implement proper seeking with binary search and keyframe detection

[GStreamer (bugzilla.gnome.org)]

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.