Controlling the queue behaviour

[Sameer Naik]

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Eric Zhang-6]

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 <[hidden email]>

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sudarshan Bisht]

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 <[hidden email]> 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 <[hidden email]>

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
Regards,

Sudarshan Bisht

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wim Taymans]

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.

Wim

>
> Reagrds
> ~Sameer
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sameer Naik]

Thanks Wim,

i was hoping to get a response from you.
I will make the said changes in code and get back on the status

Thanks again
Regards
~Sameer


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.
>
> Wim
>
> > Reagrds
> > ~Sameer
> >
> >
> > -------------------------------------------------------------------------
> >----- _______________________________________________
> > gstreamer-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel