NetTimeProvider/NetClientClock issue

danny.smith danny.smith at axis.com
Fri Mar 31 10:29:02 UTC 2017


Managed to solve the issue by lowering the timeout used for the internal
clock caching in gstnetclientclock.c. It is currently set to 60s before
unrefing the internal clock. By lowering it to a very short value the
synch-mechanisms works as expected for our usecase. That is if the
sender/time-provider reboots and starts up a new time-provider, the newly
spawned receiver netclientclock will start from a clean slate and
synchronize as expected as it will dispose of its internal-clock directly
instead of after 60s. Using this fix our receiver pipeline works again.

Regards,
Danny



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/NetTimeProvider-NetClientClock-issue-tp4682456p4682476.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.


More information about the gstreamer-devel mailing list