[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

--- Comment #16 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2014-03-20 14:29:30 UTC ---
For background information on demuxer behaviour when seeking:
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-seeking.txt#n115

So the question is basically: what to do in the demuxer when various seek flags
(ACCURATE, KEY_UNIT, SNAP_*) are set or not set.

ACCURATE is about accuracy of the position itself from the start (that is:
don't use bitrate estimate and just jump somewhere).

If a seek to position X is requested, the demuxer should start outputting data
so that a frame at position X can be decoded correctly. This implies that if NO
seek flags are set, it needs to output data from the keyframe before or at X,
so that X can be decoded correctly.

If the KEY_UNIT flag is set, the demuxer is theoretically free to pick whether
the start outputting from the keyframe before X or after X, but the segment
start needs to be updated to the position of that keyframe then, so it needs to
scan for a keyframe.

If KEY_UNIT is not set the segment start is X (and it needs to start outputting
data from the previous keyframe so that X can be decoded).

If KEY_UNIT | SNAP_AFTER are set, the demuxer needs to scan forward from X and
set segment start to keyframe after X.

SNAP flags are nice to have, but not essential. Movie players will use KEY_UNIT
usually.

Outputting data from X and letting parser/decoder throw away data to the
following keyframe is neither correct nor very fast. It is not correct because
if X is requested then the frame at position X needs to be decodable. It is not
super-fast either, because effectively you throw data at parser+decoder that's
going to be thrown away until you get a keyframe (but of course processing in
forward order is more efficient).

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