Even if no new synchronization information is available.
This is necessary because the timestamp offset logic in rtpbin depends
on the base RTP time that is determined by the jitterbuffer, but this
changes all the time (especially in mode=slave) and the timestamp
offsets have to be updated accordingly. Doing so is especially important
if they're only determined by the RTP-Info, which never changes from the
very beginning.
The interval can be configured via the new min-sync-interval property.
Synchronization happens at least that often, but at most as often as the
old sync-interval property allows.
Both intervals are now based on the monotonic system clock.
Additionally, clean up synchronization code a bit, only emit either
inband NTP or RTCP SR synchronization at the same time, based on which
one has the more recent time information, and only emit RTP-Info
synchronization if it wasn't provided previously at the same time as the
NTP-based synchronization information.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6543>
There is generally no requirement to ignore RTCP SR if the RTP time of
the SR differs a lot from the last received RTP packet. The mapping
between RTP and NTP time stays valid until there was a stream reset, in
which case we wouldn't use that information anyway.
When using rtcp-sync-send-time=false the default of 1s difference can
easily be exceeded, e.g. if encoding of the stream after capture adds
more than 1s of latency.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6543>
It is compared to other extended RTP timestamps all over rtpjitterbuffer
and since 4df3da3bab the initial extended RTP timestamp is not equal
anymore to the plain RTP time.
Continue passing a non-extended RTP timestamp via the `sync` signal for
backwards compatibility. It will always be a timestamp inside the first
extended timestamp period anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6536>
If this property is enabled then the jitterbuffer will do the normal PTS
calculations according to the configured mode instead of making use of
the RFC7273 media clock.
The timestamp calculated from the RFC7273 media clock will only be
stored in the reference timestamp meta, if addition of that meta is enabled.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5512>
When this property is used, it is assumed that the system clock is
synced close enough to the media clock used by an RFC7273 stream.
As long as both clocks are at most a few seconds from each other this
will give the correct results and avoids having to create an actual
network clock that has to sync first.
If the system clock is actually synchronized to the media clock then
everything will behave exactly the same, otherwise the reference
timestamp meta will be correct but the buffer timestamps will be off by
the difference between the two clocks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5512>
The timestamp offset can be negative, and it can be a bigger negative
number than the latency introduced by the rtpjitterbuffer so the overall
timeout offset can be negative.
Using the negative offset for calculating how many packets can still
arrive in time when encountering a lost packet in an equidistant stream
would then overflow and instead of considering fewer packets lost a lot
more packets are considered lost.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5296>
Timers for RTX packets are dealt with later in update_rtx_timers(), and
timers for non-RTX packets would potentially also be unscheduled a
second time from there so avoid that.
Also don't shadow the timer variable from the outer scope but instead
make use of it directly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2973>
Mixing C loops with switch statements is a bad idea as break has a
different meaning in both. Breaking inside the switch statements wrongly
caused further loop iterations.
Instead use goto to get out of the loop and continue to do another loop
iteration, and never ever use break except for the end of a case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2336>
Previously, we only added it when actually performing synchronization
based on the NTP time.
The information can be useful downstream in other situations too, and
we can compute a NTP time as soon as we get a sender report with the
relevant information.
Co-authored-by: Mathieu Duponchelle <mathieu@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2252>
The RTCP SR packet might be without SDES in case of a reduced-size RTCP
packet. For syncing purposes the CNAME is needed but it might be known
already from an earlier RTCP packet or out of band, via the SDP for
example.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2132>
When syncing to an RFC7273 clock this will add the original
reconstructed reference clock timestamp to buffers in form
of a GstReferenceTimestampMeta.
This is useful when we want to process or analyse data based
on the original timestamps untainted by any local adjustments,
for example reconstruct AES67 audio streams with sample accuracy.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1964>
