[Bug 753196] aggregator: seek_forward.synchronized takes too long

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Sep 11 02:17:14 PDT 2015


https://bugzilla.gnome.org/show_bug.cgi?id=753196

--- Comment #2 from Thibault Saunier <tsaunier at gnome.org> ---
I had a quick look at the issue and I can see that in GstVideoAggregator when
seeking to 20secs (on that same pipeline), we end up dropping all buffers from
20s to 40s entering that condition:

   
https://phabricator.freedesktop.org/diffusion/GSTBAD/browse/master/gst-libs/gst/video/gstvideoaggregator.c;6d1eda9391d3143b5fc633edfd94b89dbba209ab$1107

Getting the message:

    stvideoaggregator.c:1115:gst_videoaggregator_fill_queues:<_mixer:sink_1>
replacing old buffer with a newer buffer, start 0:00:00.000000000 out end
0:00:20.033333333

I can see that after the seek, we output a segment with [start=20.0,
duration=-1] and we get buffers with timestamp like:

    timestamp: 20.0   running time: 0
    timestamp: 20.033 running time: 0.033

In gst_videoaggregator_fill_queues we have

    output_start_time=20.0 and output_end_time=20.0333333

and we expect the buffers running times to be inside those boundaries,
which is why buffers are dropped until we get a buffer with
timestamp=40.0, running_time=20.0

I do not completely understand the current algorithm and am not
sure yet what is wrong exactly, maybe from those information you
might have a better idea of where what we are doing is wrong.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list