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

Wed Nov 13 02:15:00 PST 2013

Hi, 
I've made a log of what is going on went doing the seek.
I displayed log from the demuxer and the parser, plus some traces from my player.

The seek occurs on the "Player_SetPosition( 95000 ms)" line.
But then I can't see anything wrong with the log, except that at one point it seems to stop processing data.

Any clue?
Regards,
Eric

> -----Original Message-----
> From: Eric Trousset [mailto:etrousset at awox.com]
> Sent: mercredi 13 novembre 2013 09:50
> To: Discussion of the development of and with GStreamer
> Subject: RE: trying to do server side time seek on h264 mpegts media...
> 
> 
> 
> > -----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
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Player_logs_timeseek_failling.txt
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20131113/47d8b4d1/attachment-0001.txt>