<div dir="ltr">Hi all,<div><br></div><div>I have an embedded device showing RTSP / H.264 video streams from IP cameras.</div><div><br></div><div>The pipeline is more or less like this:</div><div><br></div><div>gst-launch-1.0 rtspsrc XXX ! rtph264depay ! h264parse ! avdec_h264 ! waylandsink </div><div><br></div><div>In some cases the resolution of the video stream is too high for the device to decode comfortably (unfortunately this is not something I can control). In these cases, Gstreamer (waylandsink actually I guess) decides that the frames are arriving too late, and discards them. The result is that the video is frozen (or almost -- I see a frame being displayed every now and then).</div><div><br></div><div>I thought that displaying late frames was better than displaying a frozen video so I tried to add max-lateness=-1 to the sink. However this does not seem to change anything. Next I tried to set qos=false instead, this didn't help either.</div><div><br></div><div>However setting _both_ max-lateness=-1 and qos=false does work. WIth this I can see the video stream even if there is a very noticeable delay.</div><div><br></div><div>I am trying to undestand how this works and I have some questions; hopefully someone can help.</div><div><br></div><div>1. Why setting max-lateness=-1 alone is not enough? If I understand correctly this should make the sink consider that no frames are late, so it should not be sending qos events. Why is it necessary to combine max-lateness=-1 with qos=false ?</div><div><br></div><div>2. What is the difference in practice between max-lateness=-1 + qos=false and sync=false? Both seem to achieve a similar effect, but I have read that "setting sync=false is almost never the right solution for timing problems".</div><div><br></div><div>Thank you,</div><div><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Guillermo Rodriguez Garcia<br><a href="mailto:guille.rodriguez@gmail.com" target="_blank">guille.rodriguez@gmail.com</a></div></div></div>