[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 #17 from Matthew Waters <ystreet00 at gmail.com> 2014-11-14 23:29:36 UTC ---
(In reply to comment #16)
> But knowing the deadline would be useful to the subclasses, I'm currently
> trying to implement a raw audio subclass based on the audiomixer code and
> porting interleave to us it as I need a synchronized interleave.

So, at aggregate() time, each pad either has data or not with which your
element deals with accordingly.  If a pad doesn't have data then it timed out
at some point previously and you render black/silence/nothing/absence of
something.

> > (In reply to comment #10)
> The speed of the clock. If the pipeline clock is a bit faster than the system
> clock, then every packet will arrive late at the sink.

So, just add the miniscule difference to the 'processing latency' and be done
with it.  Besides the clock isn't going to wake you up at exactly the time you
asked for anyway.

> > 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.
> 
> Most clocks go about the same speed, why do we even bother with having a
> pipeline clock then? If we want it in core, let's do it right.

Because clocks drift over time.  For small timeouts/durations they are close
enough.

> I think that the mistake you're making is assuming that the time where the
> buffer is entering the aggregator is a useful point to start from even though
> we have no idea if it's early or it's late. I think all of this should be based
> on the time when it should reach the sink (ie, the buffer timestamp).

No, it's the time that the buffer *leaves* the aggregator that is used for the
start of the timeout.  The buffer entering only cancels the timeout.

> > (In reply to comment #11)
> It's not, you're waiting on a completely different clock which for all we know
> could go measurably slower.

See above.

> > (In reply to comment #12)
> They could, but it would be nice to a gst_aggregator_set_latency() like the
> encoder & decoder base classes, it's quite handy.

Sure :)

> (In reply to comment #14)
> > Another consideration that was brought to my attention is that if you take a
> > random pipeline clock it might only advance while the pipeline is playing and
> > we do want to timeout a pad in paused so that we are not forever waiting to
> > generate a buffer because of a buffer that's never going to arrive.
> 
> The whole thing is really only for live sources. On a non-live sources, you can
> read more data or get a EOS, so this timeout doesn't apply. On a live stream,
> you won't get any buffers unless you're in playing anyway.

It could also be useful for non-live sources to have a live mixer drop frames
if they take too long to produce so the pipeline can still render other streams
that arrive in time.  Say adding a new stream to an aggregator sink pad which
could take a while to set up.

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