Understanding about the 'tee' element
nicolas at ndufresne.ca
Sat May 7 11:43:45 UTC 2022
Le sam. 7 mai 2022, 05 h 45, neoragex2002 via gstreamer-devel <
gstreamer-devel at lists.freedesktop.org> a écrit :
> Hey all,
> Recently I'm learning about how to use 'tee' and found things really weird.
> What I'm doing is below:
> $ gst-launch-1.0 videotestsrc pattern=18 ! 'video/x-raw, width=1920,
> height=1080' ! \
> tee name=t \
> t. ! queue ! videoconvert ! fpsdisplaysink sync=false \
> t. ! queue ! videoconvert ! fpsdisplaysink name=sink0 sync=false
> A probe function of gst-python was also been written to to hook the 'sink'
> pad of sink0 in the 2nd tee-branch.
> As you can see the probe function was very simple. It just slept for
> random msec.
> import random
> def probe_func(pad, info):
> delay = random.randint(0,2)
> GLib.usleep(delay*200000) # 200ms x delay
> return Gst.PadProbeReturn.OK
> But I found things are going weird: the display of the 1st tee-branch was
> frequently choked because of the random sleeps in the 2nd tee-branch.
> It seems that the queue in 2nd tee-branch was totally USELESS to decouple
> the running of the two branches.
The Python interpreter is single threaded, as a side effect the probes are
being serialized. Don't use python if you need to interact with multiple
> All I want is an 'independent enough' behavior of the 2nd tee-branch that
> does not block the 1st branch. and I also want my probe func could
> read EVERY frame AT ITS OWN PACE, instead of DISCARDING some frames to
> catch up the pace of 1st branch by using `queue leaky=2 max-size-buffers=1'
> in the 2nd tee-branch.
> Can anyone kindly enough to explain this for me?
> Thanks in advance,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gstreamer-devel