pipeline multiqueue waits for elements

[mattias-12]

When I use multiqueue with two incomping flows I see that the 2 flows block
until the sending pipeline starts to send. 1 flow is produced from videotestsrc and the other from udpsrc.
Even though only 1 buffer was received on the udcpsrc part of the receiving pipeline, the videotestsrc part
starts to run infinitely.

It seems like the multiqueue element waits for 1 buffer on each input and then lets all
flows run freely.

How can the behavior of the multiqueue element be explained regarding this test?

sending pipeline:
gst-launch videotestsrc num-buffers=1 ! video/x-raw-yuv,width=100,height=40,framerate=15/1,format="(fourcc)I420" ! udpsink host=localhost port=8011


This receiving pipeline blocks until the sending pipeline starts and then only 1 buffer is dumped to the screen
gst-launch  videotestsrc ! multiqueue name=mq1  udpsrc port=8011 ! mq1.  mq1. ! fakesink dump=true mq1. ! fakesink

If I let the other fakesink dump, it blocks until the sending pipeline starts and then a infinite number of buffers are dumped to the screen.
gst-launch  videotestsrc ! multiqueue name=mq1  udpsrc port=8011 ! mq1.  mq1. ! fakesink mq1. ! fakesink dump=true



Thanks,

Mattias

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[mattias-12]

I try to understand the text from:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-multiqueue.html

_snip_
In addition, to prevent a non-linked stream from very quickly consuming
all available buffers and thus 'racing ahead' of the other streams, the
element must ensure that buffers and inlined events for a non-linked
stream are pushed in the same order as they were received, relative to
the other streams controlled by the element. This means that a buffer
cannot be pushed to a non-linked pad any sooner than buffers in any
other stream which were received before it.
_snip_


Does this mean that all buffers are synchronized? Or does the multiqueue
only wait until the first buffer of all flows and then lets them run
independently?

Thanks,

Mattias


mattias wrote:

> When I use multiqueue with two incomping flows I see that the 2 flows
> block
> until the sending pipeline starts to send. 1 flow is produced from
> videotestsrc and the other from udpsrc.
> Even though only 1 buffer was received on the udcpsrc part of the
> receiving pipeline, the videotestsrc part
> starts to run infinitely.
>
> It seems like the multiqueue element waits for 1 buffer on each input
> and then lets all
> flows run freely.
>
> How can the behavior of the multiqueue element be explained regarding
> this test?
>
> sending pipeline:
> gst-launch videotestsrc num-buffers=1 !
> video/x-raw-yuv,width=100,height=40,framerate=15/1,format="(fourcc)I420"
> ! udpsink host=localhost port=8011
>
>
> This receiving pipeline blocks until the sending pipeline starts and
> then only 1 buffer is dumped to the screen
> gst-launch  videotestsrc ! multiqueue name=mq1  udpsrc port=8011 !
> mq1.  mq1. ! fakesink dump=true mq1. ! fakesink
>
> If I let the other fakesink dump, it blocks until the sending pipeline
> starts and then a infinite number of buffers are dumped to the screen.
> gst-launch  videotestsrc ! multiqueue name=mq1  udpsrc port=8011 !
> mq1.  mq1. ! fakesink mq1. ! fakesink dump=true
>
>
>
> Thanks,
>
> Mattias
> --
>  Mattias Frank Barthel      
>  Vía Augusta 177 08021 Barcelona (Spain)
>  Video & Multimedia technologies
>  TELEFÓNICA R&D
>  T. 0034-93-365-3309
>  

--
 Mattias Frank Barthel      
 Vía Augusta 177 08021 Barcelona (Spain)
 Video & Multimedia technologies
 TELEFÓNICA R&D
 T. 0034-93-365-3309



------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel