Prerolling and The Segment event getting delayed after the Seek event

[Sebastian Dröge]

On So, 2016-03-13 at 22:28 -0700, DeepakRohan wrote:
> Hi,
> 
>       I am using gstreamer 1.2.4 and please mention that the below questions
> are all pertaining to streaming through souphttpsrc
> 
>       I have few doubts regarding when does the pipeline gets pre-rolled.
> 1. Is it when we receive the first chain function or the New segment event
> before chain function
> 2. Or when we send the new segment event to all the source pads and also
> that atleast one data has been pushed on all linked source pads.

When all sinks with async=true in the pipeline have received their
first buffer, or alternatively immediately if you have a live pipeline.

> Also,
> a)    What i am doing in my plugin is that I initially buffer for 60MB. My
> target file to be played is an MP4 file through souphttpsrc which is movie
> of 1 hour and 40 minute in duration. After I have buffered anything >= 60MB
> in my chain function, only then I proceed further for moov atom and mdat
> parsing. The issue I see is right from the beginning of the playback there
> are a lot of audio-video drops. The issue is still seen even if I make the
> buffering to 20MB. Here after I have parsed the moov header only then I send
> the new segment event to all the source pads.
> Please enlighten me why I get the above behavior

That shouldn't cause any problems if you forward data *only* after
those 60MB are buffered and from there on continuously forwarded data
at least in real-time. Unless you have any sinks with async=false, in
which case what you're trying to do can't possibly work without
adjusting synchronization information in the pipeline. (Everything
would be considered too late in the sink by the amount of time it took
to buffer those 60MB).

> b)    Also I have seen that whenever I do a seek to position to any required
> offset or an application seek to duration, sometimes the segment event comes
> after few seconds (as far as I see 3 to 8 seconds) after seeking.
> Can anyone explain me the why the above behavior occurs and how to possibly
> resolve that.

Why is that a problem? Depending on your pipeline and the elements, but
usually the SEGMENT event is sent downstream after the demuxer knows
from which new position it should play and possibly after it go the
first data from that position. How long that takes shouldn't matter,
it's going to be as fast as possible unless there's a bug.

Also are you doing a seek with the FLUSH flag? If not, the pipeline
would first drain all previous data before you receive the data from
the new position.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160314/7955ea60/attachment.sig>