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

[Tim Müller]

On Wed, 2013-11-13 at 09:20 +0100, Eric Trousset wrote:

Hi Eric,
 
> > > 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?
> 
> It returns 0:00:00.000, and I would like it to return 0:00:30.000

Are you waiting for the ASYNC_DONE message on the bus after doing the
seek before you do that query?


> > If you seek to 30s, the position query should report something around 30s
> > when the seek is done.
> 
> The problem is that I am not seeking for the first request because I
> don't want to expose the first image of the video. So I keep track of
> the starting point of the video, and do my first http request using
> this position as my start range. But then the pipeline think this is
> the position 0. So when resuming the playback of a movie, I don't have
> the correct time.

If you don't want to show the first image from before the seek, that can
be done differently. Almost all videosinks - those deriving from
GstVideoSink anyway - should have a "show-preroll-frame" property, which
you can set to FALSE, so then you can do:

   - set "show-preroll-frame" on videosink to FALSE
   - set pipeline to PAUSED
   - wait for ASYNC_DONE message on bus
   - set "show-preroll-frame" on videosink to TRUE
   - do a flushing seek to 30s
   - set pipeline to PLAYING
   - (wait for ASYNC_DONE message on bus before querying position)


> > > 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?
> 
> Lets say I want to jump forward 10s, I ask the pipeline the current position. And then I request the server for data at time = current_pos + 10s.
> But then something seems to go wrong with the decoder. It stops decoding frames even after saying it has found a keyframe...

Right, that would have to be investigated I guess. Could be an issue
with the demuxer, with the parser or with the decoder.


> > It sounds like it starts outputting data after the seek without waiting for a
> > keyframe, which would explain the artefacts, but not the 'freezing'.
> 
> That is was I can't understand, according to the logs, it seems thing
> are going pretty well, but it somehow stops. 

> > 
> > 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).
> 
> I'm using 0.10.36. with flutsmpeg demuser
> 
> > 
> > 
> > > 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.
> 
> In the httpsrc (based on souphttpsrc), when receiving chunks
> Actually, should I set the buffer offset to some value after a seek?

You should not mess with those directly at all really, but fix issues in
the demuxer/parser/decoder if there are any. It should Just Work really.

Cheers
 -Tim

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