[gst-devel] Controlling the queue behaviour
sameer.subscriptions at damagehead.com
Mon Dec 29 20:49:01 CET 2008
i was hoping to get a response from you.
I will make the said changes in code and get back on the status
On Monday 29 December 2008 4:32:45 pm Wim Taymans wrote:
> 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