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.
> Stefan
>> Dominique Würtz wrote:
>>> Hi,
>>>> 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!
>>>> Cheers,
>>>> Dominique
>>>>>> -------------------------------------------------------------------------
>> 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
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>> _______________________________________________
>> gstreamer-devel mailing list
>>gstreamer-devel at lists.sourceforge.net>>https://lists.sourceforge.net/lists/listinfo/gstreamer-devel>>>>>>>