[gst-devel] Buffer-frames considered useless in 0.9

Stefan Kost ensonic at hora-obscura.de
Mon Sep 5 03:46:04 CEST 2005

Hi Andy,

let it die ;) I've got rid of when moving to 0.9 too.

> Greetings,
> I think the buffer-frames property of float caps is useless in GStreamer
> 0.9. I will remove mentions of it from the docs soon, unless I hear any
> objections (unlikely).
> The reason it was there was to allow for efficient processing of
> complicated audio processing pipelines, given the iteration-based
> scheduling in 0.8. If an element was written in loop mode, it was much
> easier to program when a pull was guaranteed to produce N samples rather
> than having to deal with different numbers of samples on every sink pad.
> Also it prevented buffering when pushing two source pads to two sink
> pads between two elements.
> It was never necessary that the underlying DSP algorithms, like the ones
> in LADSPA plugins, know their processing block size beforehand. So for
> the single-in, single-out, chain-scheduled case, buffer-frames was just
> a complication of capsnego.
> In 0.9 we can get rid of it because pull_range allows us to specify the
> number of samples the plugin should produce, if a flow is scheduled in
> pull mode. Push mode is a bit trickier; since there might be multiple
> sources, and push mode starts threads at each terminal source, you have
> to be prepared to get data from any thread. Fortunately Wim is clever
> and wrote GstCollectPads (gst/base/gstcollectpads.[ch]), an abstraction
> for use with multiple-sinkpad elements, which will use threads only if
> necessary.
> I'm working on a signal processing base class that will present a
> higher-level interface than buffers and pads; but the end of the story
> is that I think it's possible to do complicated DSP pipelines
> efficiently without the use of a buffer-frames property. So be advised
> that it is going away.
> (Pleasantly, this means you should be able to do "decodebin !
> audioconvert ! random-ladspa-plugin ! audioconvert ! alsasink", without
> the need for buffer-frames or getting strange errors at capsnego time.)
> Comments or questions?
> Regards,

More information about the gstreamer-devel mailing list