RTSP stream, effect of max-lateness + qos
Guillermo Rodriguez Garcia
guille.rodriguez at gmail.com
Mon May 15 09:18:43 UTC 2023
El lun, 15 may 2023 a las 11:10, Tim-Philipp Müller (<t.i.m at zen.co.uk>)
escribió:
> Hi,
>
> What would be the differences between qos=false + max-lateness=-1 and
> setting sync=false ?
>
>
> I don't think there'd be a difference if all your frames are late, but
> there'd be a difference if some of your frames are early.
>
> With sync=true the sink will wait for the right time to output those early
> frames. With sync=false it will just output the frame immediately and not
> even look at the timestamps or the clock or anything.
>
> So in a normal live playback scenario where the decoder can keep up
> sync=false will make the output jittery (because in practice the decoder
> will decode some frames faster than others, and some frames might also come
> faster out of the jitterbuffer than others, e.g. when there was packet
> loss, or because the network delay is not constant).
>
OK so it seems that in my use case, qos=false + max-lateness=-1 is better
than sync=false (for the reasons you stated above) and probably also better
than nothing, as otherwise I get no video when the resolution is too high.
So I guess the only question left is: can I set qos=false + max-lateness=-1
and then have the decoder dynamically drop frames only if it cannot keep up
(instead of "based on downstream qos events") ?
Is this feasible?
Thanks,
Guillermo Rodriguez Garcia
guille.rodriguez at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20230515/362ed134/attachment.htm>
More information about the gstreamer-devel
mailing list