Why do gstreamer filters have no passthrough mode by default?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Why do gstreamer filters have no passthrough mode by default?

diracsbracket
I am trying to learn GStreamer and its audio filter plugins and was wondering
why these filters have no passthrough mode by default?

I am for example looking at the Clementine music player's use of GStreamer,
It uses for example a "equalizer-nbands" element with 10 bands.

To "disable" the equalizer, Clementine just sets all the gains to 0dB.
I don't know how the "equalizer-nbands" element is implemented (does it 
detect that all gains are 0, or does it simply does all the calculations with
0?), but it seems to me that for any filter, there should be a default passthrough mode
of operation to disable it? I can't see such modes in the GStreamer audio plugins however.

Any thoughts on this?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why do gstreamer filters have no passthrough mode by default?

gotsring
My 2 cents:
I'll admit that I rarely use GStreamer for audio, but at least from my
experience with video streams, a passthrough option isn't normally required.
In fact, it would probably break the pipeline.

A typical video pipeline that I'd use is:
souphttpsrc location="http://webcam.local/mjpeg" ! queue ! jpegparse !
jpegdec ! videorate ! format/x-raw, framerate=20/1 ! timeoverlay ! x264enc !
matroskamux ! filesink location=test.mp4

In GStreamer, filters are anything other than a src or sink element, so
everything in the above pipeline except for the souphttpsrc and filesink are
filters. Most of those elements do some form of format conversion, so if I
tried disabling one, no conversion would take place, the output format would
be wrong for the next element, and the whole pipeline would crash.

Of course, some elements like timeoverlay just alter the stream in some
manner while keeping the same format, in this case add a runtime overlay to
the video frame. This would be perfect for an "is_enabled" property that you
could disable at runtime. The author of timeoverlay could have added this
property to easily disable the element. Or, GStreamer could have an
"is_enabled" property in some base class that encoders, parsers, muxers,
converters, etc. would have to ignore... doesn't really make sense, in my
opinion.

It's also worth pointing out that there is a way to dynamically alter the
pipeline that doesn't rely on the implementation of individual elements:
just add or remove the entire element! This way, there are no extra steps
that end up doing nothing; the buffers are passed directly to the next
element that we care about.
See docs on pipeline manipulation here:
https://gstreamer.freedesktop.org/documentation/application-development/advanced/pipeline-manipulation.html?gi-language=c#dynamically-changing-the-pipeline



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel