<div dir="ltr"><div>Hello,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El sáb, 13 may 2023 a las 11:23, Tim-Philipp Müller via gstreamer-devel (<<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Hi,</div><div><br></div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>There are multiple places where frames can potentially be dropped here:</div><div><br></div><div>a) at the videosink if "too late", and "max-lateness" controls what's considered "too late".</div><div><br></div><div>b) at the videodecoder in response to QoS events from the sink (unless disabled via the "qos" property on the decoder or sink)</div><div><br></div><div>c) at elements in between the videodecoder and the videosink, such as e.g. videoconvert/scale in response to QoS events from the sink <span style="font-size:14.6667px">(unless disabled via the "qos" property on the filter or sink) (you don't have those here of course)</span></div><div><br></div><div>Qos events are always sent upstream, not only when a buffer is late (but elements won't drop anything then of course if the buffer was on time).</div><div><br></div><div>If you just set <i>max-lateness=-1</i> on the sink you disable dropping of frames that are late, so the videosink will show every frame that arrives. However, it will then still send QoS events to upstream telling the decoder/filter how late that buffer was, and if it's quite a lot late then the decoder will try and skip some frames in order to catch up. You've just moved the frame dropping from the sink (plus decoder) to just the decoder. (I'm ignoring any filters in the middle that might exist in other pipelines, although they might also drop frames if they'd be way too late according to the last QoS event).</div><div><br></div><div>If you just set <i>qos=false</i> no the sink, the decoder/filters will never skip frames in response to qos events, because no QoS events will be sent upstream. The sink will still drop frames that are "too late", because the max-lateness property is still set.</div></div></blockquote><div><br></div><div>I see. This makes a lot of sense, thank you for the explanation.</div><div>I was assuming that the sink decides which frames are "too late" based on max-lateness, so setting max-lateness=-1 would mean no frames are ever considered late, and thus no qos events would be sent upstream. I see that I was wrong.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>If you set both <i>qos=false</i> and <i>max-lateness=-1</i> then you disable all frame dropping, although then the decoder/sink will work slower than realtime. It's similar to just setting sync=false on the sink. so at some point there will be data before the decoder piling up that's not being processed in time, and at some point that will then cause other problems, e.g. if you receive via UDP the kernel-side UDP receive buffers will run full and you'll lose packets causing audio/video glitches. If you use TCP the sender might kick you out at some point if you're not reading data any more.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>If the performance is borderline you might get away with configuring the decoder to skip some things, e.g. <i>avdec_h264 skip-frame=1</i> would skip B-frames (assuming there are B-frames in the first place which might not be the case).</div><div><br></div><div>The only way to avoid the 'backpressure' problem is to make sure things get dropped before or at the decoder, otherwise the decoder has to process everything and won't keep up and will fall more and more behind no matter what's happening after it.</div></div></blockquote><div><br></div><div>Is there a way to tune the strategy for dropping frames at the decoder? Ideally I would like to see the following</div><div>- Initially do not drop any "late" frames (otherwise basically I get a frozen video which was my starting point)<br></div><div>- Only drop frames if the decoder itself cannot keep up, instead of based on downstream qos events</div><div class="gmail_quote"><br></div>?</div><div class="gmail_quote"><br></div><div class="gmail_quote">Thanks,</div><div><br></div><div dir="ltr" class="gmail_signature">Guillermo Rodriguez Garcia<br><a href="mailto:guille.rodriguez@gmail.com" target="_blank">guille.rodriguez@gmail.com</a></div></div>