Prerolling and The Segment event getting delayed after the Seek event

[DeepakRohan]

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.

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

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.

Thank you in Advance.

[Sebastian Dröge-3]

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[DeepakRohan]

Hi Sebastian,

I am doing seek event using the GST_SEEK_FLAG_FLUSH flag.
Even then I see that whenever I do a seek from my side I get Flush Start and Flush Stop very next to my seek event. But the segment event comes after few seconds.

The pipeline is like the below one:
gst-launch-1.0 souphttpsrc location=http://<IP>/huge.mp4 ! mymp4demux name=d d.audio_00 ! queue ! decodebin ! alsasink d.video_00 ! queue ! decodebin ! autovideosink

And can you please explain the concept of "sinks with async=true in the pipeline", I couldn't understand that part.
And how can I confirm if all the sinks are in async=TRUE state in the pipeline.

[Sebastian Dröge-3]

On Mo, 2016-03-14 at 01:50 -0700, DeepakRohan wrote:

> Hi Sebastian,
>
> I am doing seek event using the GST_SEEK_FLAG_FLUSH flag.
> Even then I see that whenever I do a seek from my side I get Flush Start and
> Flush Stop very next to my seek event. But the segment event comes after few
> seconds.
>
> The pipeline is like the below one:
> gst-launch-1.0 souphttpsrc location=http://<IP>/huge.mp4 ! mymp4demux name=d
> d.audio_00 ! queue ! decodebin ! alsasink d.video_00 ! queue ! decodebin !
> autovideosink

Where does it come after a few seconds? Inside your demuxer? The sink?
Also why do you have your own MP4 demuxer instead of using the one from
GStreamer? Does it work better with GStreamer's?

>
> And can you please explain the concept of "sinks with async=true in
> the pipeline", I couldn't understand that part.
> And how can I confirm if all the sinks are in async=TRUE state in the
> pipeline.

Are you setting the async property yourself on any sink? If not it will
default to TRUE.

--
Sebastian Dröge, Centricular Ltd · http://www.centricular.com


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[jslootbeek]

I am encountering the same delay while seeking with decodebin. In the past, we used wavparse, but replaced that with decodebin to fix another issue, however, the decodebin switch introduced this delay.
Rohan, we're you able to solve this issue?
It may be worth nothing that I am using pygst when encountering this issue, and calling the seek with the GST_SEEK_FLAG_ACCURATE and GST_SEEK_FLAG_FLUSH flags.