[gst-devel] Controlling the queue behaviour

sudarshan bisht bisht.sudarshan at gmail.com
Mon Dec 29 06:00:15 CET 2008


Hi ,

     If your pipeline does not PREROLL , that means there is some problem in
caps negotiation in the pipeline , and try to use both the queues only
after  the demuxer element .

 That looks like this :-

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




On Mon, Dec 29, 2008 at 9:11 AM, Eric Zhang <nicolas.m.zhang at gmail.com>wrote:

> Hi, gstreamer-devel:
>
>     Normally, it should be no problem if you just change your gstreamer
> from 0.10.9 to 0.10.21. "max-size-buffers" should also work.
>
>     So, I think you should provide more debug infos and do some tests(E.g:
> put a probe before your video/audio sinks and see whether there is buffers
> flow into them; Turn on debug infos on basesink and your sink elements and
> see what the sinks exactly do during preroll) yourself and figure out why
> the preroll can't be performed.
>
> Eric Zhang
>
> 2008/12/28 Sameer Naik <sameer.subscriptions at damagehead.com>
>
> 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
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>


-- 
Regards,

Sudarshan Bisht
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20081229/c77acc41/attachment.htm>


More information about the gstreamer-devel mailing list