GNOME Bugzilla – Bug 760554
Losing buffers when having multiple outputs
Last modified: 2016-01-14 21:34:25 UTC
Hi, During development for an element I faced a problem that multiple elements connected to tee are not always receiving all buffers. To make sure this problem is not caused by my element I created another element name testelement from videofilter template, this element is not doing anything rather than printing the buffer pts that it's receiving and it will handle an empty buffer for output. After running this gst-launch command : gst-launch-1.0 filesrc location= /content/media/bbb_sunflower_2160p_30fps_normal.mp4 ! qtdemux ! h264parse ! avdec_h264 ! tee name=t \ t. ! queue ! testelement ! videoscale ! videoconvert ! xvimagesink display=:1 \ t. ! queue ! testelement ! videoscale ! videoconvert ! xvimagesink display=:2 \ t. ! queue ! testelement ! videoscale ! videoconvert ! xvimagesink display=:3 \ t. ! queue ! testelement ! videoscale ! videoconvert ! xvimagesink display=:4 \ t. ! queue ! testelement ! videoscale ! videoconvert ! xvimagesink display=:5 \ t. ! queue ! testelement ! videoscale ! videoconvert ! xvimagesink display=:6 \ t. ! queue ! testelement ! videoscale ! videoconvert ! xvimagesink display=:7 \ t. ! queue ! testelement ! videoscale ! videoconvert ! xvimagesink display=:8 &> buffer_test.txt If you take a look at line 263 for example you will see only 4 instances has received the buffer with pts 1133333333 or 7 of them with 1166666666 instead of 8, I'll attach the output to this bug. I've tested this with 4 Ximagesink and this thing was still happening, my system is a skylake core i7 and cpu usage is below 50% for this test. The GStreamer version for this test was 1.6.0 but I had same issue with 1.4.1 and 1.2.0 I could not recreate this by putting fakesink right after testelement. enabling debug for xvimagesink was not showing any drop or losing frames problem. Thank you for your help in advance
Created attachment 318916 [details] testelement print output
Created attachment 318917 [details] testelement project
My guess is that buffers are lost due to QoS handling. Note: gst-inspect-1.0 testelement | grep -A3 qos qos : Handle Quality-of-Service events flags: readable, writable Boolean. Default: true and the same may be true for other filters between your element and the sink. Try disabling qos event sending at the sinks with xvimagesink qos=false and see if it still happens then.
(In reply to Tim-Philipp Müller from comment #3) > My guess is that buffers are lost due to QoS handling. Note: > > gst-inspect-1.0 testelement | grep -A3 qos > > qos : Handle Quality-of-Service events > flags: readable, writable > Boolean. Default: true > > and the same may be true for other filters between your element and the sink. > > Try disabling qos event sending at the sinks with xvimagesink qos=false and > see if it still happens then. Thank you for your response, That resolved the issue. but is there any way to have QOS active and drop frames only before tee element if we're slow ?
I think you can do that by setting qos=false on all filters between tee and the video sinks, then only the video decoder will act on QoS events (assuming they make it through the tee to the decoder; but keep in mind that a QoS issue in any one of the branches will make the decoder drop frames then, so perhaps you don't want that either). And you may need/want to set a higher max-lateness value on the video sinks, so they don't drop stuff that's too late (but the QoS event will still be sent). Closing as NOTABUG since it's expected behaviour.