<div dir="auto">You should check the latency of your pipeline. <div dir="auto">It is possibile that the computed latency is on the edge of the rendering deadline. Increase the logging should show when frames are dropped and for that reason. </div><div dir="auto"><br></div><div dir="auto">You can increase the latency of the synk with latency parameter. Try to increase the latency and add a queue before the sink. </div><div dir="auto">The queue should avoid the decoder to stall waiting the rendering. </div><div dir="auto"><br></div><div dir="auto">Best</div><div dir="auto">Matteo<br><div dir="auto"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 26, 2020, 05:10 QwjN1Y9mJvamZJ <<a href="mailto:km212121@gmail.com">km212121@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I forgot to mention that the "choppy" playback with gst-launch and the smooth<br>
one in MPC-BE take the same amount of time, so it's not like gst plays it<br>
back slower. I have suspicion, without data to back it up though, that some<br>
frames might be dropped for some reason, that's why the progression from one<br>
frame to the next is visible.<br>
<br>
I would like to know how to check what's actually going wrong in my<br>
pipeline: are buffers being dropped even though it's not a performance<br>
bottleneck?<br>
<br>
<br>
<br>
--<br>
Sent from: <a href="http://gstreamer-devel.966125.n4.nabble.com/" rel="noreferrer noreferrer" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank" rel="noreferrer">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div>