[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 #13 from Matthew Waters <ystreet00 at gmail.com> 2014-11-14 11:30:01 UTC ---
(In reply to comment #9)
> The unresponsive functionality should inform the subclass at which time it is
> now, according to the pipeline clock, that way, the subclass can fill in the
> right amount of "gap data", but not more. I guess this could also be used to
> process incoming GAP events and give them to the subclasses.

That's handled elsewhere by the subclasses atm.  GstAggregator currently
doesn't deal at all with how the data is matched against stream times.

(In reply to comment #10)
> 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.

The speed of what? display? Why would you dynamically adjust the timeout based
on some speed?

I think that some small duration in two separate clocks will amount to a close
enough elapsing of time that it does not make a difference.

> > (In reply to comment #7)
> 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.

Which is exactly the same as 'if a buffer does not occur on a pad after the
timeout, ignore it and generate a frame anyway'.

ASCII diagram :)

b1, b2, b3 = buffer
f = generated frame
| = timeout occurences

----- running time ------>
. timeout |(b1)  timeout |(b2)|(b3)
b1- - - - - - - - - b3- - - - - -  -> to sink1
- - - - - - - b2- - - - - - - - -  -> to sink2
__________f__________f________f

As is visible from the great diagram, a frame is generated at most after the
timeout has occured.

(In reply to comment #11)
> Basically, to fulfill the latency promise made in the response to the latency
> query, a buffer has to exit the element when the pipeline clock reaches
> buffer_in_running_time + element_latency + upstream_latency at the latest.

Which is upheld in the current code.

(In reply to comment #12)
> Another thing, it's missing an API for subclasses to set the amount of latency
> they are adding.

Subclasses can override the latency query where they call the base class and
then add their own if they need.

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