[gst-devel] Problem choosing the right scheduling mode
housirer at gmx.de
Mon Aug 7 10:09:01 CEST 2006
Stefan Kost schrieb:
> Just one idea - can't you use
> src ! level ! fakesink
No. The level element only emits signals in regular time intervals,
passing the peak value of the last inteval to the callback. What I need
is a buffer with a continuous stream of min/max information.
> Dominique Würtz wrote:
>> I'm currently trying to implement an element which generates peak
>> information (min/max value pairs) from audio data to be used for
>> waveform drawing. Reading through the PWG and experimenting with the
>> various scheduling modes, I found each mode to be unsuitable for
>> different reasons I want to explain below. The main issue with my
>> element is the possibly significant input/ouput buffer size ratio:
>> * For very low zoom factors, you take many audio samples and ouput a
>> relatively small number of peak values.
>> * OTOH, a high zoo factor means taking only a bunch of samples and
>> render them into a large chunk of peaks (say 1 sample could be displayed
>> 50 pixels wide)
>> So here is what I found when evaluating the scheduling modes:
>> 1. chain-based: incoming (audio data) is pushed on the sink pad. This
>> works ok of low zoom factors, because I can collect the incoming buffers
>> (for ex. using a GstAdapter) push out the generated data once I have a
>> sufficient amount of samples at the input. However, for high zoom
>> factors, it won't work (well). In this case, I have to generate a large
>> number of peak data for a relatively low number of input samples. This
>> is bad, firstly because I think buffer sizes of maybe 100kbytes are
>> simply bad practice and secondly large buffers mean possible overhead,
>> because the downstream element could only need part of the data,
>> discarding the major part of the expensively calculated data.
>> 2. GstTask-based: this would basically work well. Main problem here is
>> that it requires the upstream elements to provide random access, which
>> unfortunately not the case for elements like wavparse and actually not
>> required for my task.
>> So to sum things up, at this point I see no way to get things done with
>> current GStreamer but I'd be glad if someone come up with an idea.
>> Just as a suggestion, the optimal scheduling mode for this kind of
>> element would be an additional pull-based chain mode: a chain callback
>> is attached to a _source_ pad where data is pulled (no random access!)
>> from sink pads. The new gst_pad_pull() function could then also be used
>> as an alternative to get_range() in GstTask-based elements, making it
>> possible to connect chain-based elements upstream.
>> I hope I explained myself properly and appreciate any comments!
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys -- and earn cash
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel