The new property allows to select the time source that should be used for the
NTP time in RTCP packets. By default it will continue to calculate the NTP
timestamp (1900 epoch) based on the realtime clock. Alternatively it can use
the UNIX timestamp (1970 epoch), the pipeline's running time or the pipeline's
clock time. The latter is especially useful for synchronizing multiple
receivers if all of them share the same clock.
If use-pipeline-clock is set to TRUE, it will override the ntp-time-source
setting and continue to use the running time plus 70 years. This is only kept
for backwards compatibility.
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.
Add an accumulator that stops the signal emission as soon as a caps has
been retrieved. Otherwise the default handler would continue emitting
the signal and possibly overwrite the result with NULL again.
AUX elements are elements that can be inserted into the rtpbin
pipeline right before or after 1 or more session elements.
The AUX elements are essential for implementing functionality such
as error correction (FEC) and retransmission (RTX).
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711087
Keep track of elements that are added to multiple sessions and make sure
we only add them to the rtpbin once and that we clean them when no
session refers to them anymore.
* gst/rtpmanager/gstrtpbin.[ch]: four new action signals have been
added (request-rtp-encoder, request-rtp-decoder, request-rtcp-encoder
and request-rtcp-decoder). The user will be able to provide encoders
or decoders dynamically. The encoders must follow the srtpenc API and
the decoders the srtpdec API. Having separate signals for RTP and RTCP
allows the user to use different encoders/decoders or provide the same
one (e.g. that would be the case for srtpenc).
Also, rtpbin now allows application/x-srtp in its pads.
https://bugzilla.gnome.org/show_bug.cgi?id=719938
rtpbin can now send a custom in-band downstream event which informs
downstream that the bin has received an RTCP SR packet. This is useful
for applications which want to drop the initial unsynchronized received
RTP packets.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=703560
Signed-off-by: Carlos Rafael Giani <dv@pseudoterminal.org>
Move the work of cleaning up the client streams in the free_stream
function. This allows us to properly clean up the client streams when we
remove an RTP stream as well.
Based on patch by Sujay <sdatar@cisco.com>
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=660156
When use-pipeline-clock is set, use the running-time of the
pipeline to calculate the NTP timestamps. This method would previously
only work when the base-time is set to 0 but with this change it can
also work with different offsets and we can also implement pause/resume
of the sender and receiver now.
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We'll change these
over to the new API once we depend on glib >= 2.32.
... to at least having it trigger a/v synchronization, possibly without
using provided values which are still not considered sane
(as previously dropped).
... at least if not syncing to NPT time:
* either sync using RTCP SR data (as currently)
* only perform the above once using initial RTCP SR packets
* discard RTCP and sync by equating provided stream's clock-base rtptime,
as provided by jitterbuffer (typically obtained from RTP-Info in RTSP).
When using gstrtpbin with ignore-pt=true, the free_stream function tries to
call gst_element_set_locked_state and gst_element_set_state on a stream->demux
which is NULL.
fixes#642412
Holding internal locks while potentially calling out is a source
of deadlocks, and in this case the application might subscribe to the
pad-added signal.
Fixes#630449
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 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.
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.
Pass the current running time to the jitterbuffer when pausing or resuming so
that it calculate the right offsets.
Small cleanups and comments.
Set the default rtspsrc latency to 2 seconds.
Add signal to pause the jitterbuffer. This will be emitted from gstrtpbin when
one of the jitterbuffers is buffering.
Make rtpbin collect the buffering messages and post a new buffering message with
the min value.
Remove the stats callback from jitterbuffer but pass a percent integer to
functions that affect the buffering state of the jitterbuffer. This allows us
then to post buffering messages from outside of the jitterbuffer lock.
