[Bug 740236] New interleave2 based on GstAggregator and create GstAudioAggregator from audiomixer

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=740236
  GStreamer | gst-plugins-bad | git

--- Comment #36 from Olivier Crête <olivier.crete at ocrete.ca> 2014-11-26 21:20:12 UTC ---
First, thanks for your thoughtful review

(In reply to comment #26)
> Review of attachment 291387 [details]:
> ::: gst-libs/gst/base/gstaggregator.c
> @@ +1024,3 @@
> 
> +  GST_OBJECT_LOCK (self);
> +  data.min += self->priv->subclass_min_latency;
> 
> min latency can not be CLOCK_TIME_NONE then? What if subclass does not know but
> knows the max?

I think if you don't know, then we've lost, live pipelines (with live src &
live sink) can't really work without a known latency, so you may as well return
0. For the max, GST_CLOCK_TIME_NONE is really GST_CLOCK_TIME_MAX, ie, it has no
limit on how much it can buffer.

(In reply to comment #28)
> Review of attachment 291388 [details]:
> 
> I do not understand why you would say it is a hack at all? The subclass can
> have information about the fact it is EOS that baseclass does not know, and we
> need to let the subclass tell us if it is the case, for example here in
> videoaggregator, in the case we have output_end_time == output_start_time, we
> *know* at that point that we are EOS, we have not received any EOS event on the
> pad but we do not care at that point.

Normally, returning GST_FLOW_EOS means that you tried to push a buffer after a
pad has reached eos. Ie, it is a fatal error resulting from a programming
error. I guess we could add a gst_aggregator_push_eos() for that case. Although
it does seem a strange one.


(In reply to comment #29)
> Review of attachment 291389 [details]:
> 
> I am not sure I understand what the behaviour is after that patch?

Before this patch, it all pads go unresponsive, GstVideoAggregator based
elements would call the aggregate function in a loop forever (and
AudioAggregator just sent EOS). After the patch, the aggregate function will be
called once (which allows the subclass to send downstream any data it still
has), then it will wait for another buffer to arrive.

(In reply to comment #31)
> Review of attachment 291393 [details]:
> 
> I am not sure we are supposed to answer to BYTE position with decoded data like
> that.

This is directly taken from "interleave", I assume it had the right behavior.

(In reply to comment #33)
> Review of attachment 291395 [details]:
> 
> Do we support other format types? And what would happen in the other cases?

In the other format types, you just can't clip, and you can't really
synchronize either.

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