[gstreamer-bugs] [Bug 550634] [mpeg ts demuxer] Doesn't support seeking and duration reporting

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=550634

  GStreamer | gst-plugins-bad | Ver: git




------- Comment #4 from Edward Hervey  2009-03-16 08:21 UTC -------
So there's two different scenarios here for seeking/duration support:

* push-based (current behaviour).
** Duration reporting
  This can only be done in two different ways:
  * Upstream elements knows about duration in time (rtp source?) and pushes out
newsegments in time, in that case we should just forward it.
  * Upstream elements doesn't know about duration in time, and pushes out a
newsegment in bytes. If there's a specified stop position from which we can
figure out the size in bytes, we could estimate the duration and constantly
update it based on the current bitrate. Not perfect, but better than nothing.
If the newsegment doesn't contain a stop position... we can't seek and report
duration.

** Seeking
  Two different ways again:
  * mpegtsdemux sees an incoming seek in time, it pushes it upstream first. If
upstream can handle it, we *should* be fine (haven't tested it). We then just
forward the newsegment in time that we receive.
  * If upstream didn't accept the time seek, we need to interpolate based on
the know bitrate the position in bytes, send the seek upstream, and return
whatever upstream says (True/False). When the newsegment in bytes comes
through, figure out duration as above and once we have enough information
regarding bitrate and initial timestamp, push out the newsegment

* pull-based (not implemented).
  This is for local content (any source able to handle pull-based requests in
bytes). This will require quite a few modifications in the source code to
handle this. One obvious thing that seems missing for example, is that the
upstream offset in bytes of every handled packet is discarded right from the
start, whereas it should be remembered and passed along so that we can store
that information in an index.

** Duration reporting
  We can can seek upstream for the first/last PES and figure out the duration
from the difference in time between the two. This supposes it's one continuous
stream (identical PAT/PMT). If it's a concatenation of several streams it will
requires seeking upstream to find more PES values to figure out the proper
layout.

** Seeking
  Two ways to do this:
  * Without an index/GstIndex : We need to estimate the upstream byte position
from current bitrate, and then gradually seek upstream to find the correct
position (many ways to do that : bisection, 3 way interpolation, ...) and once
we have it, start pushing out data.
  * With an index/GstIndex : As we push out buffers, we store the position in
time and bytes of *key* locations (keyframes in the various streams for ex). We
then use that information to seek quickly in past positions, and use the
technique above for positions in the future (except storing the information we
learn along the way, and maybe also using the information in the index to
extrapolate the upstream bytes seek position faster).


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=550634.