Add an ntp-sync property that will sync the received streams to the server
NTP time. This requires synchronized NTP times between the sender and receivers,
like with ntpd.
Based on patch from Thijs Vermeir.
Fixes#627796
When using RTP_JITTER_BUFFER_MODE_BUFFER, make sure that the ringbuffer doesn't
get stuck buffering forever when there isn't enough data left to fill the
buffer.
Set ->active to TRUE in _init so it can be set to FALSE after creating the
jitterbuffer and it won't be mistakenly reset to TRUE in the change_state
function.
This is needed to start the jitterbuffer as inactive when rtpbin is buffering.
This just replaces every "$ERROR_CFLAGS" usage with a usage of
"$WARNING_CFLAGS $ERROR_CFLAGS" to get the same functionality as
previously.
Actually using that separation will happen later.
Add a "favor-new" property that tells the session to favor new sources when
there is a SSRC conflict. This is useful for SIP calls and other such cases
where a remote loop is extremely unlikely.
Fixes#607615
Use the length of the payload for estimating the receiver bitrate so that it
matches the calculations done on the sender side. Together with the number of
packets one can scale the bitrate with the header overhead of the lower
transport.
Don't reuse the same variable we need for stats for the bitrate estimation
because we're updating it.
Refactor the bitrate estimation code so that both sender and receivers use the
same code path.
Remove some code where we pass ntpnstime around, we can do most things with the
running_time just fine.
Rename a variable in the ArrivalStats struct so that it's clear that this is the
current system time.
Don't calculate the NTP time based on the running_time of the pipeline but from
the systemclock. This allows us to generate more accurate NTP timestamps in case
the systemclock is synchronized with NTP or similar.
If we detect backward timestamps on the server, don't try to resync when we
don't have an input timestamp (such as when using RTSP over TCP) instead, do
nothing but assume the timestamp was ok, it will correct itself when time goes
forwards.
There is no need to set the latency in the jittebuffer in _init, we will set
that later when going to PAUSED.
Set the jitterbuffer active and not buffering when starting.
When deactivating jitterbuffers when the buffering starts, keep the current
percent of the jitterbuffer and also set the jitterbuffer in the buffering state
so that we know when it's filled again.
Add property to get the buffering percentage of the jitterbuffer.
When we are in buffer mode, adjust the buffering low/high thresholds based on
the total configured latency. If we don't and there is a huge queue or element
with a big latency downstream we might drain the complete queue immediately and
start buffering again.
Return the next timestamp in the jitterbuffer.
Use the min-timestamp of the jitterbuffers to calculate an offset so that the
next timestamp is pushed with a timestamp equal to running_time.
Start producing timestamps from 0 in the buffering case too.
Keep track of the time we spend pausing the jitterbuffers when they were
buffering and distribute this elapsed time to the jitterbuffers.
Also keep the latency in nanosecond precision.
