RTSP latency issues, effect of sync=false

[Guillermo Rodriguez Garcia]

El vie., 24 jul. 2020 a las 16:04, Nicolas Dufresne
(<nicolas at ndufresne.ca>) escribió:
>
> Le vendredi 24 juillet 2020 à 14:33 +0200, Guillermo Rodriguez Garcia a
> écrit :
> > > The sink element have no queues, so it does know if there is some late
> > > frame already there. So I believe the answer is no.
> >
> > Uhm.. but then for the same reason, I would expect the "speedup
> > effect" to be rather limited.
> > I mean, since the sink has no queues (and in fact I am not using
> > queues anywhere else in the pipeline) there shouldn't be that too many
> > "late" frames to play -- only the bunch of frames that were sent "more
> > or less together" due to the network bursts you mentioned.
> >
> > Anyway my problem seems to be that when the frames arrive, the sink
> > discards them because of the timestamp (i.e. this is not a performance
> > problem, but a latency problem). Using sync=false helps because the
> > sink will not discard frames, but is subject to the speedup problems
> > you describe.
> >
> > Is there any way to configure the sink so that it does not drop late
> > frames (or at least to be a bit more lenient) without using sync=false
> > ?
>
> Sinks have a max-lateness property, if you set it to -1, then it will
> behave like udpsink, which is it will send the data on sync, or late
> and won't drop. If you PC is too slow, it will never catch up.

I have tried to set max-lateness to -1 and it doesn't help; I still
see stuttering video.
So I guess this means my hypothesis was wrong -- the sink is not
discarding frames because they are late.

I am a bit lost now.
If neither max-lateness=-1 nor qos=0 help, but sync=false does, then
what might be the problem?

Guillermo