Huge RTSP latency achieved over long time of streaming from specific IP camera

[VincasD]

I've discovered that RTSP video latency can grow over time when using some specific IP camera.

Command line used with ffplay.exe 6.1.1 on Windows to have low latency:

`
ffplay.exe -y 420 -fflags nobuffer -flags low_delay rtsp://someuser:somepass@192.168.3.111:554/AVStream1_1
`

I've launched two instances of ffplay for this "problematic" camera on the left, and two instances with other camera that seems to work fine on the right, and in the video attached you can see that problematic camera latency grown more than 10s over weekend.

[VincasD]

Demonstration of huge latency for IP camera

[MB SOFT]

because you forgot -vf setpts=0 in your commandline

[VincasD]

Thanks for suggestion!

I've launched couple of instances for testing, but what it actually means?

Also, it seems with this option playback is no longer smooth, looks like "jittering", i.e. is this really the solution..?

I've noticed that SOME instances of gst-launc-1.0 have this issue, rather randomly (not always/not all streams).

Onvif Device Manager and VLC (both using Live555) does not reproduce it.

mpv also seems not to reproduce it, lough it uses Lavf (i.e. ffmpeg?).

[VincasD]

is -vf setpts=0 same as sync=false in GStreamer?

Most of cameras can show video overnight without disabling sycn and without experiencing growing latency. It seems that specific camera behaves "differently", yet Live555 (ODM, VLC) looks like can handle it fine.

[VincasD]

I've left four instances of ffplay 4.3.6 on Linux with -vf setpts=0 added overnight, and they did not reproduce growing latency overnight (see ffplay_setpts_linux.mp4​)

Also left four instances of ffplay 6.1.1 on Windows with -vf setpts=0 added overnight too, and they DID still reproduce growing latency, and every instance resulted with different latency, see ffplay_setpts_windows.mp4​.

So not sure if it actually helps or it's just instance for "randomly works ok", as some GStreamer instances also seems to work fine.

[Marton Balint]

FFplay is not really developed to maintain a fixed latency for live sources, or to regenerate the clock of the input.

Typically the clock source for playback is the playback audio clock, which just depends on the internal clock of your sound card. This is likely slighly different from the local clock of your camera, so in time the latency will change.

You might try using the -sync ext mode, which does some playback clock adjustments to keep the buffered data (and therefore latency) constant, but it might cause some sudden audio pitch changes.

[VincasD]

I've attached default_vs_sync_ext.png - it seems that using -sync ext (on the right) is even worse in a sense that it shows about ~2s latency just from the start, without even waiting for hours for latency to grow.

Anyway, so hypothesis is that this IP camera module provides some sort of wrong timing information that potentially produces growing latency?

Again, this does not reproduce with other IP camera modules, nor with Live555 implementations (and mpv) with same "problematic" camera.