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

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Nov 27 01:30:08 PST 2014


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

--- Comment #40 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-11-27 09:30:03 UTC ---
(In reply to comment #36)

> > Review of attachment 291388 [details] [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.

This is not true. It can be an error, but it can also be completely expected
behaviour. Downstream can return EOS when it decides that it is at the end of
stream now. Upstream might not know that this is the case, e.g. because
downstream has a different segment configured or because downstream has
additional knowledge about when the stream ends (think container format with a
known byte size and then a lot of garbage at the end after the container).

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


More information about the gstreamer-bugs mailing list