[gst-devel] Controlling the queue behaviour

Sameer Naik sameer.subscriptions at damagehead.com
Sun Dec 28 06:48:21 CET 2008

I have written a  gstreamer plugin that does video decoding on specialized 
hardware, and also written a videosink plugin that opens the framebuffer 
device,etc . For optimizing the entire pipeline the videosink plugin has the 
_pad_alloc functionality, that directly makes available the framebuffer memory 
to the decoder plugin, so that the output images can directly be written to 
the video memory. I would also mention, that the videosink can make available 
3 such buffers (triple buffering) to the decoder, so effectively the decoder 
should not request for more than three buffers at the same time, in which case 
if it does the _pad_alloc function will not return any buffer.
Now, if i construct my pipeline as such

gst-launch filesrc location=file.mpeg ! demultiplexer name=demux ! videodecoder 
! queue ! videosink  demux. ! audiodecoder ! audioconvert ! queue ! audiosink

what happens is, due to the queue element (after the videodecoder), the part 
of the bin goes into its own thread. as a result, the videodecoder ends up 
making a lot more buffer requests to the videosink, than the videosink can 
really allocate. 
Due to this, in gstreamer version 0.10.9 i would add the queue before the 
videodecoder. like so

gst-launch filesrc location=file.mpeg ! demultiplexer name=demux ! queue ! 
videodecoder ! videosink  demux. ! audiodecoder ! audioconvert ! queue ! 

and everything works fine. 

But the current version 0.10.21 does not allow me to do this, as in the 
pipeline does not PREROLL.

I would like to know, whether it is possible to control how the queue 
functions so that it does not store more than 3 buffers. i tried specifying 
max-size-buffers=3 on the queue, but it did not help.
I would also be interested in knowing any other ways this can be taken care 


More information about the gstreamer-devel mailing list