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).
GCC 4.6.x spits warnings about variables that are unused but set. Such
variables have been removed where trivial but with comments left behind
for informational purposes in some cases.
gst_rtp_session_chain_recv_rtcp () was changed in commit 490113d4
to always return GST_FLOW_OK instead of the return value of
rtp_session_process_rtcp (), so we'll keep it that way.
1) We need to lock and get a strong ref to the parent, if still there.
2) If it has gone away, we need to handle that gracefully.
This is necessary in order to safely modify a running pipeline. Has been
observed when a streaming thread is doing a buffer_alloc() while an
application thread sends an event on a pad further downstream, and from
within a pad probe (holding STREAM_LOCK) carries out the pipeline plumbing
while the streaming thread has its buffer_alloc() in progress.
since we are using the clock for sync, we need to also provide a clock for good
measure. The reason is that even if downstream elements provide a clock, we
don't want to have that clock selected because it might not be running yet.
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.
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.
