trying to do server side time seek on h264 mpegts media...

[Tim Müller]

On Tue, 2013-11-12 at 15:22 +0100, Eric Trousset wrote:

Hi Eric,

> As said in the title, I’m try to do et server side time seek on a
> mpegts media.

Just to make sure: you mean you're doing something like

 gst-launch-1.0 playbin uri=http://example.com/path/to/foo.ts

? Or are you using GStreamer server-side as well?


> The initial seek is ok, eg I can start playing the media from anywhere
> using the correct http header, the pipeline et build et the media
> start playing ok. Thus, the query position, doesn’t take account of
> the starting position. So this is one of my question, how do I tell
> the pipeline that it didn’t start at position 0:00:00.000 but for
> example at 0:00:30.000?

I'm not sure I understand your question here. What does a position query
in TIME format return right after the seek has finished (ASYNC_DONE
message on the bus)? And what did you expect it to return?

If you seek to 30s, the position query should report something around
30s when the seek is done.

> Then, when I try to seek in the media, always using trickmodes, I can
> some time get the first image of the new position, but with a lot of
> artefacts. But then it freezes, and the ffmpegdec doesn’t produce
> traces anymore.

What exactly do you mean with 'always using trickmodes' here? What kind
of trickmodes? What exactly are you doing?

It sounds like it starts outputting data after the seek without waiting
for a keyframe, which would explain the artefacts, but not the
'freezing'.

What versions of things are you using? 0.10? 1.x? Which mpeg-ts demuxer
ends up being used in your case? (there were at least three in 0.10
days).


> It looks like the pipeline is still in playing state reporting an
> evolving position.

This would be expected after it first showed some frame again after the
seek (with artefacts or without).


> Anyone has a idea on how I can fix this?
> 
> I tried setting the buffer flag to DISCONT, changing offset and/or
> time stamps to some new values, with no results.

Tried doing this where? After a seek/flush, the first buffer should have
the DISCONT flag set (but hopefully the decoders have already flushed
everything anyway), but the demuxer should cater for that. Same for the
timestamps on the buffers, the demuxer should just output the right
thing there. 

Cheers
 -Tim

-- 
Tim Müller, Centricular Ltd - http://www.centricular.com