*** Bug 347342 has been marked as a duplicate of this bug. ***

*** Bug 574074 has been marked as a duplicate of this bug. ***

We get the same seek issue while trying to stream a TS file over the rtsp or http.

As we've currently investigated the main cause of the issue is the absence of the valid NEWSEGMENT event after seek.

More detailed investigation results are described here:

http://www.nabble.com/RTSP-stream-and-seeking-operations-td22178411.html

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

(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?

The demuxer shouldn't 'patch' the newsegment in that scenario, but imho modify the timestamps of the outgoing buffers accordingly.

(In reply to comment #6)
> The demuxer shouldn't 'patch' the newsegment in that scenario, but imho modify
> the timestamps of the outgoing buffers accordingly.

I see. Maybe it's better then to initially substract the first PTS from the initial segment start and buffers timestamps?

Hi,

Can the 576739 bug be related with the one is being discussed here? It's about A/V sync problems when seeking RTSP/RTP content.

Regards

I believe this bug may be covered by Bug 585077 or vice-versa?

The bugs mentionned in the two comments above are NOT duplicates of this one.

By hacking gstmpegtsdemux to 
1. Not flush stream (ignore GST_EVENT_FLUSH_{START,STOP})
2. Provide fake times after seeking (make continuity) in gst_mpegts_demux_data_cb

it now seeks to any position (although it looks weird for user because it plays the remaining buffer content first).

After making gstmpegtsdemux to override start time from 0 to the new position seeking from RTSP started working better.

Created attachment 165964 [details] [review]
Patch to make seeking from RTSP with use of mpegtsdemux work.

Comment on attachment 165964 [details] [review]
Patch to make seeking from RTSP with use of mpegtsdemux work.

>From da27049537a5aa5e18f8919515e31cc714707eab Mon Sep 17 00:00:00 2001
>From: Vitaly _Vi Shukela <public_vi@tut.by>
>Date: Mon, 12 Jul 2010 22:21:28 +0300
>Subject: [PATCH] mpegdemux: Hack for seeking from RTSP streams.
>
>It makes the newsegment to start not from 0, but from seek time, also fixing the stop time.
>---
> gst/mpegdemux/gstmpegtsdemux.c |   21 +++++++++++++++------
> 1 files changed, 15 insertions(+), 6 deletions(-)
>
>diff --git a/gst/mpegdemux/gstmpegtsdemux.c b/gst/mpegdemux/gstmpegtsdemux.c
>index 507cfdd..79aaa0f 100644
>--- a/gst/mpegdemux/gstmpegtsdemux.c
>+++ b/gst/mpegdemux/gstmpegtsdemux.c
>@@ -2685,7 +2685,6 @@ gst_mpegts_demux_sink_event (GstPad * pad, GstEvent * event)
>       gst_event_parse_new_segment (event, &update, &rate, &format,
>           &start, &stop, &time);
> 
>-      gst_event_unref (event);
>       GST_INFO_OBJECT (demux, "received new segment: rate %g "
>           "format %d, start: %" G_GINT64_FORMAT ", stop: %" G_GINT64_FORMAT
>           ", time: %" G_GINT64_FORMAT, rate, format, start, stop, time);
>@@ -2699,14 +2698,24 @@ gst_mpegts_demux_sink_event (GstPad * pad, GstEvent * event)
>         tstop += BYTES_TO_GSTTIME (stop);
>         pos = BYTES_TO_GSTTIME (time);
> 
>+        gst_event_unref (event);
>+        tstart = pos;
>+        tstop += tstart;
>         event = gst_event_new_new_segment (update, rate,
>             GST_FORMAT_TIME, tstart, tstop, pos);
>         GST_DEBUG_OBJECT (demux, "pushing time newsegment from %"
>             GST_TIME_FORMAT " to %" GST_TIME_FORMAT " pos %" GST_TIME_FORMAT,
>             GST_TIME_ARGS (tstart), GST_TIME_ARGS (tstop), GST_TIME_ARGS (pos));
> 
>-        res = gst_mpegts_demux_send_event (demux, event);
>+      } else {
>+        gst_event_unref (event);
>+        start = time;
>+        stop += start;
>+        event = gst_event_new_new_segment (update, rate,
>+            GST_FORMAT_TIME, start, stop, time);
>+
>       }
>+      res = gst_mpegts_demux_send_event (demux, event);
>       break;
>     }
>     default:
>-- 
>1.7.1
>

Created attachment 165969 [details] [review]
Patch to make seeking from RTSP with use of mpegtsdemux work.

*** Bug 585077 has been marked as a duplicate of this bug. ***

While obviously not a solution, this maybe provide a temporary workaround for end users:

for MTS in *.MTS; do ffmpeg -i ${MTS} -vcodec copy -acodec copy -scodec none `echo ${MTS} | sed 's/MTS/mkv/g'`; done

OK, the above actually fails if a fails has subs embedded, since the none "codec" isn't recognized. ffmpeg has a different parameter to strip out subtitles (-sn):

for MTS in *.MTS; do ffmpeg -i ${MTS} -vcodec copy -acodec copy -sn `echo ${MTS} | sed 's/MTS/mkv/g'`; done

How is this bug? Ubuntu users seemed to think all was well now: https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/327872

I have absolutely no idea at all why downstream just marked it as "Fix released" out of the blue. My guess is that they don't want to have it on their bug list.

Could someone check if this is working correctly now with tsdemux (not mpegtsdemux) from GIT? There were lots of bugfixes related to timestamp handling and seeking recently.

Was anybody able to reproduce the problem in recent GStreamer ?

sorry, closed it by mistake.

I am closing this bug due to lack of response. Please test with new tsdemux from GIT. If the issue persists, please re-open.