RTSP stream, effect of max-lateness + qos

Guillermo Rodriguez Garcia guille.rodriguez at gmail.com
Fri May 12 11:31:19 UTC 2023


Hi all,

I have an embedded device showing RTSP / H.264 video streams from IP
cameras.

The pipeline is more or less like this:

gst-launch-1.0 rtspsrc XXX ! rtph264depay ! h264parse ! avdec_h264 !
waylandsink

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).

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.

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.

I am trying to undestand how this works and I have some questions;
hopefully someone can help.

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 ?

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".

Thank you,

Guillermo Rodriguez Garcia
guille.rodriguez at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230512/6cdd1287/attachment-0001.htm>


More information about the gstreamer-devel mailing list