[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 #13 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
The start-time is use to decide when to stop dropping incoming buffers and what
timestamp should the first buffer (on src pad) should have. So if you set it to
0, all buffers will be included. An possibly unwanted side effect is that if
you have a source that produce it's first buffer 5s after we switched to
playing state, then it will produce 5s of silence in a burst.

Them start-time mode first comes into play. With that mode, the mixer should
set it's start time to the first timestamp that arrives. It only consider 1
buffer on one pad, and make this the first timestamp of the output.

When you want to let you live pipeline run for a while (e.g. let it stabilize),
you can set a start time in the future, the mixer will then drop buffers until
they are at least that time, and then will start mixing. The first output
produce will be at least that time.

In your test, you introduce 5 second delay on the first buffer, that means it's
5 second late. audiotestsrc never drops anything, so for a while, all buffers
will be late compare to the already processed stream (the one that had defined
the start-time, but being first). Unlike a real use case of latency, it should
eventually catch up.

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