NetTimeProvider/NetClientClock issue

[Carlos Rafael Giani]

What I do is to check the SSRC values in the RTP packets. I do that in a 
pad probe. If I notice a change in the SSRC, I set the pipeline back to 
READY, unref the existing netclientclock, create a new netclientclock, 
and switch back to PLAYING. This has worked well for me.

It seems you have most of this in place already. I suppose you also 
switch back to READY/NULL before creating the new netclientclock? And 
what do you do with the old one?

On 2017-03-30 11:56, danny.smith wrote:
> Hi,
>
> I am using the NetClock mechanism to synchronize several receivers which
> plays streaming audio (over RTP) from one sender. The sender also acts as a
> time provider. I am now facing an issue where the sender reboots and
> subsequently creates a new time provider.
>
> The receivers notice that the sender has rebooted and creates a new
> netclientclock and a new pipeline slaved to this clock. Here however a
> problem arises, I cannot seem to get the new netclientclock to understand it
> must resynchronize against the new time provider on the sender. This causes
> the pipeline to never enter playing state, all the "received timestamps" in
> the jitter buffer reports 0 and i get differing base-times on my receivers.
> The new time provider starts on the same ip-address and port as before.
>   
> How should I correctly handle the scenario where the sender reboots and
> creates a new timeprovider in order to get the receivers synchronized again?
>
> Best Regards,
> Danny
>
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/NetTimeProvider-NetClientClock-issue-tp4682456.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel