[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 #10 from Olivier Crete (Tester) <olivier.crete at ocrete.ca> 2014-11-14 02:09:11 UTC ---
(In reply to comment #8)
> (In reply to comment #5)
> > The timeout seems to be using the System clock, I think that's very wrong, it
> > should be using the pipeline clock instead, ie GST_ELEMENT_CLOCK().
> 
> If we were basing it off buffer timestamps then yes, the pipeline clock would
> be more suitable.

Because we want the timeouts to follow the speed at which it is displayed,
which is based on the pipeline clock. We really have no guarantees that this
clock has anything to do with the system clock. Also, you add it to the latency
query, and you can only do that if you use the pipeline clock, you're comparing
apples and oranges.

> (In reply to comment #7)
> > I think the timeout functionality should also probably be based on the buffer
> > timestamp, not just on the time where it happens to arrive into the aggregator
> > based element.
> 
> Why, what conceptual problem does that fix?
> 
> It's actually based on the time between when the buffer is consumed by the
> subclass to when the next upstream buffer arrives.  If the buffer has not
> arrived after the timeout, then the pad is unresponsive and we don't wait for
> it.  I thought of it as the time between data was here and the deadline when
> data needs to be here in order to continue processing.

I think it should work along the same lines as rtpjitterbuffer. So the variable
we want to control is how long can useful data stay in the aggregator before it
is pushed out. And that should be based on the oldest valid unit of data stuck
in the aggregator.

-- 
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.