[gst-devel] Problem choosing the right scheduling mode

[Dominique Würtz]

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
>>   
>>     
>
>
>