[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