[gst-devel] Problem choosing the right scheduling mode

[Stefan Kost]

Just one idea - can't you use
src ! level ! fakesink
?

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
>