From: Sameer N. <sam...@da...> - 2008-12-28 05:48:30
|
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. Reagrds ~Sameer |