[gst-devel] Controlling the queue behaviour

Wim Taymans wim.taymans at gmail.com
Mon Dec 29 12:02:45 CET 2008

On Sun, 2008-12-28 at 11:18 +0530, Sameer Naik wrote:
> Hi,
> 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 ! 
> audiosink
> 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 ç
> of.

For this, the sink should block in the buffer_alloc function until an
old buffer is rendered and there is a buffer available again for
rendering into. When shutting down you should of course unblock and
return WRONG_STATE from the buffer_alloc function.


> Reagrds
> ~Sameer
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

More information about the gstreamer-devel mailing list