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