[Bug 739010] [PLUGIN MOVE] Move GstAggregator to gstreamer (core)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=739010
  GStreamer | gstreamer (core) | git

--- Comment #25 from Olivier Crete (Tester) <olivier.crete at ocrete.ca> 2014-11-17 04:41:44 UTC ---
I've been giving the timeout thing a bit more thought, and I've come to believe
that we're looking at it from the wrong side. Instead of declaring that a sink
pad is unresponsive after a timeout, the srcpad should operate on a deadline.
For example, with videomixer, we generally want to produce an output buffer
every 1/x FPS, so when we push out a buffer, we know exactly when is the last
possible moment to push out the next buffer. For the audiomixer, we also know
this deadline. This deadline is then the time when we should wake up the srcpad
task loop and call the aggregate function if enough data was not yet received.
Obviously, if enough data was received, the GstAggregator should call aggregate
earlier so as to push out the buffer as soon as possible. 
So instead of having a "unresponsive" flag on each pad, I'd just have a
deadline-reached variable for the entire element, and then aggregate everything
there at this point.

Also, to make this alternate design race-free, we'd need to add a queue inside
the GstAggregatorPad that would buffer up to "timeout" buffers to make sure
they're directly available when the deadline is reached.

To match other elements, we should rename "timeout" into "latency".

Lookinag at the QoS event handling (bug #739996), which I think should also be
in the GstAggregator class which should export a
gst_aggregator_get_earliest_time().

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.