[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 #5 from Aleksey Yulin  2009-03-16 09:26 UTC -------
(In reply to comment #4)

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

This is the scanario we have: seek event reaches the rtspsrc which performs the
seek. Then the newsegment event is generated by rtp depayload and is passed
through the demuxer downstream. But as i described before it looks like this
newsegment is started from 0, but demuxer continues to set real TS packets
timestamps for the outgoing buffers (like 7:26:30). Shouldn't the demuxer patch
the received newsegment event before sending it downstream?


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