[gst-devel] RTSP stream and seeking operations

[Aleksey Yulin]

Further investigations show that there's the same SEEK issue while trying to
stream mpeg TS over using the HTTP streaming.

So it seems that the problem is actually in the Mpeg Transport Stream
demuxer (we use 'mpegtsdemux').

As we could see the demuxer creates an initial NEWSEGMENT starting from the
first TS timestamp for the downstream elements. That works fine, but when
SEEK is performed the new NEWSEGMENT event is generated before the demuxer -
in the RTP depayload element. This segment has a 0 as start and actual seek
position as a 'position'. 
But the demuxer instead of patching this NEWSEGMENT event (shifting to the
next known TS packet timestamp) seems to just pass it downstream. This would
be OK, but the demuxer continues to set buffers timestamps to the actual TS
packets timestamp so for downstream elements it looks like
out-of-valid-range buffers are coming so they whether start to skip these
buffers (like mpeg2decoder) or just returns UNEXPECTED (as mpegaudio
decoder) causing the pipeline to pause forever.

We've tried to send the valid NEWSEGMENT event after SEEK (from the
streaming thread context) and got the following: after seek the picture has
paused, but after some time (comparable to the new position value) the
playback started from the new position. This happens only with the first
SEEK - any subsequential seeks causes the pipeline to pause forever as
before.
-- 
View this message in context: http://www.nabble.com/RTSP-stream-and-seeking-operations-tp22178411p22532814.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.