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

[Eric Trousset]

> -----Original Message-----
> From: Tim Müller [mailto:tim at centricular.com]
> Sent: mercredi 13 novembre 2013 09:39
> To: gstreamer-devel at lists.freedesktop.org
> Subject: Re: trying to do server side time seek on h264 mpegts media...
> 
> 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)

Thx for this, this should fix one of my problem, but I need to fix my other issue first, as I can manage to do only the first seek at the moment :)
Regards,
Eric

> 
> 
> > > > 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
> 
> 
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel