<div dir="ltr">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. <div><br></div><div>v4l2src ! queue name=loc_q  ! videoscale ! capsfilter ! vmixer. \</div><div>udpsink ! rtph264depay ! avdec_h264 ! queue name=rem_q ! videoscale ! input-selector name=is ! capfilster ! vmixer. \</div><div>videotestsrc ! is.  \</div><div>videomixer name=vmixer ! xvimagesink</div><div><br></div><div>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 </div><div><br></div><div><div>v4l2src ! queue name=loc_q  ! videoscale ! capsfilter ! xvimagesink \</div><div>udpsink ! rtph264depay ! avdec_h264 ! queue name=rem_q ! videoscale ! input-selector name=is ! capfilster ! xvimagesink \</div><div>videotestsrc ! is.  </div></div><div><br></div><div>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</div><div><br></div><div><div>DEBUG: queue_pushing_cb - Entered</div><div>DEBUG: queue_pushing_cb - Enabling stream</div><div>DEBUG: queue_underrun_cb - Entered</div><div>DEBUG: queue_pushing_cb - Entered</div><div>DEBUG: queue_underrun_cb - Entered</div><div>DEBUG: queue_pushing_cb - Entered</div><div>DEBUG: watchdog_cb - Entered</div><div>DEBUG: watchdog_cb - Entered</div><div>DEBUG: watchdog_cb - Enabling mock</div><div>DEBUG: queue_underrun_cb - Entered</div><div>DEBUG: queue_pushing_cb - Entered</div><div>DEBUG: queue_pushing_cb - Enabling stream</div><div>DEBUG: queue_underrun_cb - Entered</div><div>DEBUG: queue_pushing_cb - Entered</div><div>DEBUG: queue_underrun_cb - Entered</div><div>DEBUG: watchdog_cb - Entered</div><div>DEBUG: watchdog_cb - Entered</div><div>DEBUG: watchdog_cb - Enabling mock</div></div><div><br></div><div>Entered - entered the callback function</div><div>Enabling stream - toggled the input-selector active pad to use the remote h264 stream</div><div>Enabling mock - toggled the input-selector active pad to use the videotestsrc</div><div><br></div><div>I've verified the exact behavior even when my watchdog is set to a period of 5secs.</div><div>Any ideas?</div><div><br></div><div>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 ?</div><div><br></div><div>Sérgio</div></div>