[Bug 791285] gstaggregator with start-time-selection=first uses incorrect base_time when waiting for data on sink pads

[GStreamer (GNOME Bugzilla)]

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

--- Comment #15 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
I'm not sure I understand 1 and 2 here. In live mode, audiomixer no longer
waits for upstream data. It calculate when is the deadline for data to be
produce in order for that data to be on-time at the sink. If start-time is 0,
it will setup the timer immediatly when we go to playing (at least this what it
should do, I think this is buggy). In start-time first, it will setup the timer
when the first buffer comes in, base on when that buffer need to be mixed and
ready to go to reach the sink on time. And then with start-time set, we set to
timeout base on that, no need to look at the buffers. All this is base on the
declared latency of upstream segment.

In live mode, we pop data from the internal queues and mix them. If a source is
having a huge latency (like in your test, 5s) that is not declared, then that
source will be ignored from the mixing. The unit test helps understand, but
does not seem valid. With RTP, if you have this case, you can increase the
latency on rtpjitterbuffer element. What is not out-of-the box is this latency,
we don't have a dynamic latency mode in GStreamer.

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