Re: [gst-devel] request for comment : mute, solo, bypass

[Benjamin O. <in...@pu...>]

On Fri, 5 Nov 2004, Stefan Kost wrote:

> There is one optimization the original buzz-software seems to make. When a src
> machine produced a buffer of silence, it tagges the buffer as such. The
> scheduler in buzz then just bypasses all following machines (to save cpu
> cycles). Any idea how such a thing can be done in gst?
>
Not sure this can be done easily by a scheduler or similar, since there
are elements that do stuff with silence buffers, like the encoders or
visualizers. or even echo plugins. Marking silence buffers sounds like an
interesting idea to me though (either by using a buffer flag or by using
interrupt events, not sure what's better, though I tend to think the first
is). You could then add shortcuts to the filters' chainfuncs in the form
of
if (GST_BUFFER_IS_SILENT (buf)) { gst_pad_push (src, buf); return; }
and see how mu7ch cycles that saves.

> The next thing is, when I temporarily unlink a part from the nextwork and
> therwith a chain of elements is not connected to a sink, do our schedulers (e.g.
> opt) skip them then? Means when I mute a filter, I would like to unlink its
> previous elements and set its output to silence.
>
The correct thing if you want to disable elements is to change their state
(probably to PAUSED, maybe even further down). Playing elements should be
and are scheduled. (For example in autopluggers, or the filesrc ! typefind
pipeline.) In 0.10 even unlinked sinkpads will be scheduled, they'll
produce EOF events.
So in the case where you want to have silence instead of disabled
elements, you would either connect a custom identity that produces silence
when its sink is unlinked or you connect a silence element instead of the
disabled pipeline.

Benjamin