Videomixer blocking upstream queue pushing, running signals.

Sérgio Agostinho sergio.r.agostinho at gmail.com
Tue Dec 9 03:46:23 PST 2014


I'm trying to implement a Skype like functionality using the videomixer to
display a remote video stream and my local video stream on the same
imagesink. After some initial tests I verified that the videomixer blocks
data flow if one of the streams of the input streams stops sending data. In
an attempt to work around this I decided to implement the following
pipeline.

v4l2src ! queue name=loc_q  ! videoscale ! capsfilter ! vmixer. \
udpsink ! rtph264depay ! avdec_h264 ! queue name=rem_q ! videoscale !
input-selector name=is ! capfilster ! vmixer. \
videotestsrc ! is.  \
videomixer name=vmixer ! xvimagesink

The main idea was to use the signals "pushing" and "underrun" from the
'rem_q' queue to toggle the active pad of the input-selector. In my initial
tests, I removed the videomixer from the pipeline and connected the local
and remote video source to independent image sinks

v4l2src ! queue name=loc_q  ! videoscale ! capsfilter ! xvimagesink \
udpsink ! rtph264depay ! avdec_h264 ! queue name=rem_q ! videoscale !
input-selector name=is ! capfilster ! xvimagesink \
videotestsrc ! is.

With this setup, I verified that when data is flowing through 'rem_q',
queue emits intermittently a  "pushing" and "underrun", which make me
interpret is as data being pushed as soon as it arrives. Based on this
behavior I decided to implement a watchdog timer functionality that would
switch the input-selector active-pad to the videotestsrc if the  "pushing"
signal was not triggered at least once in the last 50ms. This worked as
intended! Later on, when I decided to replace my two imagesinks by the
videomixer with one imagesink, the queue signals started to behave
differently even though the videomixer is pushing data out continusly. When
I send some data into the udpsink the following happens

DEBUG: queue_pushing_cb - Entered
DEBUG: queue_pushing_cb - Enabling stream
DEBUG: queue_underrun_cb - Entered
DEBUG: queue_pushing_cb - Entered
DEBUG: queue_underrun_cb - Entered
DEBUG: queue_pushing_cb - Entered
DEBUG: watchdog_cb - Entered
DEBUG: watchdog_cb - Entered
DEBUG: watchdog_cb - Enabling mock
DEBUG: queue_underrun_cb - Entered
DEBUG: queue_pushing_cb - Entered
DEBUG: queue_pushing_cb - Enabling stream
DEBUG: queue_underrun_cb - Entered
DEBUG: queue_pushing_cb - Entered
DEBUG: queue_underrun_cb - Entered
DEBUG: watchdog_cb - Entered
DEBUG: watchdog_cb - Entered
DEBUG: watchdog_cb - Enabling mock

Entered - entered the callback function
Enabling stream - toggled the input-selector active pad to use the remote
h264 stream
Enabling mock - toggled the input-selector active pad to use the
videotestsrc

I've verified the exact behavior even when my watchdog is set to a period
of 5secs.
Any ideas?

The second issue, so far I haven't been able to verify any difference in
the behaviors on the "pushing" and "running" signals of the queue. Do these
differences manifest themselves if I start changing the the min-size-*
parameters ?

Sérgio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20141209/3990e3b0/attachment.html>


More information about the gstreamer-devel mailing list