If multiple net/NTP clocks are created for the same server, reuse the same
internal clock for all of them. This makes sure that we don't flood the server
with too many requests and also possibly allows faster synchronization if
there already was an earlier synchronized clock when creating a new one.
* Fix function name in sections.txt
* Add few missing or fix miss-named
* Workaround gtk-doc being confused with non typedef
types (loose track of public/private
gstbasetransform.h:196: Warning: GstBase: "@submit_input_buffer" parameter unexpected at this location:
* @submit_input_buffer: Function which accepts a new input buffer and pre-processes it.
gstnetcontrolmessagemeta.c:103: Warning: GstNet: gst_buffer_add_net_control_message_meta: unknown parameter 'message' in documentation comment, should be 'addr'
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
This uses all of the netclientclock code, except for the generation and
parsing of packets. Unfortunately some code duplication was necessary
because GstNetTimePacket is public API and couldn't be extended easily
to support NTPv4 packets without breaking API/ABI.
We extend our calculations to work with local send time, remote receive time,
remote send time and local receive time. For the netclientclock protocol,
remote receive and send time are assumed to be the same value.
For the results, this modified calculation makes absolutely no difference
unless the two remote times are different.
This improves accuracy on wifi or similar networks, where the RTT can go very
high up for a single observation every now and then. Without filtering them
away completely, they would still still modify the average RTT, and thus all
clock estimations.
They don't necessarily use the same underlying clocks (e.g. on Windows), or
might be configured to a different clock type (monotonic vs. real time clock).
We need the values a clean system clock returns, as those are the values used
by the internal clocks.
If the delay measurement is too far away from the median of the window of last
delay measurements, we discard it. This increases accuracy on wifi a lot.
https://bugzilla.gnome.org/show_bug.cgi?id=749391
We should do some more measurements with all these and check how much sense
they make for PTP. Also enabling them means not following IEEE1588-2008 by the
letter anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=749391
GstPtpClock implements a PTP (IEEE1588:2008) ordinary clock in
slave-only mode, that allows a GStreamer pipeline to synchronize
to a PTP network clock in some specific domain.
The PTP subsystem can be initialized with gst_ptp_init(), which then
starts a helper process to do the actual communication via the PTP
ports. This is required as PTP listens on ports < 1024 and thus
requires special privileges. Once this helper process is started, the
main process will synchronize to all PTP domains that are detected on
the selected interfaces.
gst_ptp_clock_new() then allows to create a GstClock that provides the
PTP time from a master clock inside a specific PTP domain. This clock
will only return valid timestamps once the timestamps in the PTP domain
are known. To check this, the GstPtpClock::internal-clock property and
the related notify::clock signal can be used. Once the internal clock
is not NULL, the PTP domain's time is known. Alternatively you can wait
for this with gst_ptp_clock_wait_ready().
To gather statistics about the PTP clock synchronization,
gst_ptp_statistics_callback_add() can be used. This gives the
application the possibility to collect all kinds of statistics
from the clock synchronization.
https://bugzilla.gnome.org/show_bug.cgi?id=749391
Just create the cancellable fd once and keep it around instead
of creating/closing it for every single packet. Since we spend
most time waiting for packets, an fd is alloced and in use pretty
much all the time anyway.
GstNetAddress can be used to store ancillary data which was received with
or is to be sent alongside the buffer data. When used with socket sinks
and sources which understand this meta it allows sending and receiving
ancillary data such as unix credentials (See `GUnixCredentialsMessage`)
and Unix file descriptions (See `GUnixFDMessage`).
This will be useful for implementing protocols which use file-descriptor
passing in payloaders/depayloaders without having to re-implement all the
socket handling code already present in elements such as multisocketsink,
etc. This, in turn, will be useful for implementing zero-copy video IPC.
This meta uses the platform independent `GSocketControlMessage` API
provided by GLib as a part of GIO. As a result this new meta does not
require any new dependencies or any conditional compliation for
portablility, although it is unlikely to do anything useful on non-UNIX
platforms.
Add a hold off when the clock calibration suddenly loses synch,
as it may be a glitch, but also make sure we update if it stays
desynched for more than a few seconds
Add the minimum-update-interval property to the clock, with a default
of 50ms and don't send polling requests faster than that. That helps to
ensure we spread the initial observations out a little - startup takes
a little longer, but tracking is more stable.
Move the discont skew limiting code inside an if statement, so that
it's only done when the linear regression succeeds and the clock
parameters might actually change.
Allow setting a GstBus on the network clock client
via a new 'bus' object property. If a bus is set, the
clock will output an element message containing statistics
about new clock observations and the clock correlation.
When the local clock is synchronised with the remote, limit the
maximum jump in the clock at any point to be one average RTT to
the server. Also, publish in the bus message whether we are
synched with the remote or not.
* GstGlobalDeviceMonitor was renamed to GstDeviceMonitor
* Expand GST_MESSAGE_DEVICE to the full enum value names
* Correct the incorrect references to the GstDeviceProvider interfaces
* Describe caps arguments for gstcheck interface
* Add missing docs for GstNetAddressMeta and its add function
* Add docs for toc helper macros
* Avoid refering to GstValueList type as done elsewhere
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=732786
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
Fix a typo in a doc string - the property is round-trip-limit, not
roundtrip-limit.
Remove a bogus GST_WARNING that can print an uninitialised variable
and is redundant anyway.
Sometimes, packets might take a very long time to return. Such packets
usually are way too late and destabilize the regression with their
obsolete data. On Wi-Fi, round-trips of over 7 seconds have been observed.
If the limit is set to a nonzero value, packets with a round-trip period
larger than the limit are ignored.
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
https://bugzilla.gnome.org/show_bug.cgi?id=712385
Keep a rolling average of the round trip time for network clock
observations, favouring shorter round trips as being more accurate.
Don't pass any clock observation to the clock slaving if it has a
round-trip time greater than 2 times the average.
Actual shifts in the network topology will be noticed after some
time, as the rolling average incorporates the new round trip times.
Even though this parameter is not used, it should be const to fit in with the
coding standards for other similar parameters. Client code already passes in
const strings under the expectation that they won’t be modified.
https://bugzilla.gnome.org/show_bug.cgi?id=710442
The _1_0 suffixed environment variables override the
non-suffixed ones, so if we're in an environment that
sets the _1_0 suffixed ones, such as jhbuild, we need
to set those to make sure ours actually always get
used.
Using multiple libraries causes problems for the C# bindings and
will for similiar languages such as Java when there are bindings
for them.
Also change --library=libgstfoo-X.la to --library=gstfoo-X as
the man page suggests it should be done.
https://bugzilla.gnome.org/show_bug.cgi?id=679315
No need to use a custom main context and custom timeout sources,
just use g_socket_condition_timed_wait() instead, which was added
for exactly this case.
Also seems to help with the unit test deadlocking with glib 2.33.x
https://bugzilla.gnome.org/show_bug.cgi?id=681575
Remove GST_MAJORMINOR and replace it by GST_API_VERSION
Also set GST_VERSION_{MAJOR,MINOR,MICRO,NANO} explicitely
now.
All versions are at 1.0.0 now for the release soon but
API/ABI can still change until the 1.0.0 release.
Next release versions until 1.0.0 will be 0.10.9X and
these will be release candidates. GST_VERSION_* will
nonetheless stay at 1.0.0.0.
Split out the registration of the metadata API and its implementation. Make a
GType for each metadata API. This allows us to store extra information with the
API type such as the tags.
Change the buffer API so that we can get the metadata using the API GType.
Change the query API so that we use the metadata API GType in the allocation
query instead of a string.
Update netaddress and unit tests
Add support for adding tags to the metadata. with some standard keys, this
should make it possible to describe what the metadata refers to. We should be
able to use this information to decide if a transformation destroys the metadata
or not.
Flesh out the transform method. Add a type and extra info to the transform
function so that implementation can transform the metadata.
Remove the copy function and replace with the more generic transform.
