What are implications of ntp-sync in rtspsrc?

Application Development
1

I have discoverd very strange issue with one particular IP camera module - after some time of running some stream might get very large latency, measured in SECONDS after running overnight, for example (see Some IP camera produces HUGE latency over time via RTSP)

So far workarounds are to use drop-on-latency=1 + queue with limit of max-size-time=1, but streams are not as stable as withot allowing to drop. Lot’s of difrerent IP modules works fine without drop-on-latency.

Another way seems might help (still testing, and testing this kind of “rare” issues is pure cancer, gotta wait overnight probably) is to set ntp-sync=1.

Now questions arises:

  1. Why ntp-sync is not enabled by default? I assume it might bring problems for other use cases?
  2. What are implications and use cases of additional parameter ntp-time-source (rtspsrc)? It has alternatives:

ntp (0) – NTP time based on realtime clock

unix (1) – UNIX time based on realtime clock

running-time (2) – Running time based on pipeline clock

clock-time (3) – Pipeline clock time

Thanks!

1 Like