GNOME Bugzilla – Bug 750574
netclientclock: Make the clock a wrapper clock around an internal clock
Last modified: 2015-06-09 08:13:02 UTC
See commit message for reasoning
Created attachment 304783 [details] [review] netclientclock: Make the clock a wrapper clock around an internal clock The internal clock is only used for slaving against the remote clock, while the user-facing GstClock can be additionally slaved to another clock if desired. By default, if no master clock is set, this has exactly the same behaviour as before. If a master clock is set (which was not allowed before), the user-facing clock is reporting the remote clock as internal time and slaves this to the master clock. This also removes the weirdness that the internal time of the netclientclock was always the system clock time, and not the remote clock time.
Created attachment 304785 [details] [review] netclientclock: Use the new GST_CLOCK_FLAG_NEEDS_STARTUP_SYNC flag
Review of attachment 304783 [details] [review]: Just changing all the references to priv->internal_clock makes the code a bit weird, but OK.
Review of attachment 304785 [details] [review]: cool
commit 59d916a071e445ece94b7971263f272d69da43e4 Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Jun 8 17:10:56 2015 +0200 netclientclock: Use the new GST_CLOCK_FLAG_NEEDS_STARTUP_SYNC flag https://bugzilla.gnome.org/show_bug.cgi?id=750574 commit 558c0b97fc8b9ffe5a39563da72d9e29a511aa14 Author: Sebastian Dröge <sebastian@centricular.com> Date: Mon Jun 8 17:04:55 2015 +0200 netclientclock: Make the clock a wrapper clock around an internal clock The internal clock is only used for slaving against the remote clock, while the user-facing GstClock can be additionally slaved to another clock if desired. By default, if no master clock is set, this has exactly the same behaviour as before. If a master clock is set (which was not allowed before), the user-facing clock is reporting the remote clock as internal time and slaves this to the master clock. This also removes the weirdness that the internal time of the netclientclock was always the system clock time, and not the remote clock time. https://bugzilla.gnome.org/show_bug.cgi?id=750574