goom2k1: removing block of code that does nothing

The loop in zoomFilterSetResolution is meant to change the values in the
zf->firedec[] array. Each iteration writes the value of decc onto the arrya,
but no conditions that change the value of decc are ever met and the array is
filled with zero for each element. Which is the initial state of the
array before the loop begins.

The loop does nothing.

https://bugzilla.gnome.org/show_bug.cgi?id=728353
rtpmux: clock-base and seqnum-base -> timestamp-offset and seqnum-offset

These were renamed in GstRTPBasePayload in 1.0
rtpdtmfsrc: clock-base and seqnum-base -> timestamp-offset and seqnum-offset

These were renamed in GstRTPBasePayload in 1.0
rtpsource: Rename seqnum-base to seqnum-offset in caps

This was modified back in 1.0 in GstRtpBasePayload
equalizer: Don't call iirequalizer's transform_ip in passthrough mode

It tries to map the read-only buffer with GST_MAP_READWRITE and crashes.

https://bugzilla.gnome.org/show_bug.cgi?id=737886
wavenc: Support RF64 format

https://bugzilla.gnome.org/show_bug.cgi?id=725145
rtp: add h265 RTP payloader + depayloader
Revert "rtp: add h265 RTP payloader + depayloader"

This reverts commit d06ba9051f904a7eb482c07a97a1827169158663.

This breaks the build, as it depends on parser API in -bad.
videobox: critical error when element properties set as max/min

left, right, top, bottom can be set from range of -2147483648 to 2147483647
when i launch the videobox element with that values, it gives a critical error

(gst-check-1.0:29869): GStreamer-CRITICAL **: gst_value_set_int_range_step: assertion 'start < end' failed
This happens because min cannot be equal to max.

https://bugzilla.gnome.org/show_bug.cgi?id=738838
rtpmux: Don't set PROXY_CAPS flag on the src pad

rtpmux behaves like a funnel in that it forwards whatever upstream is
sending buffers. So setting proxy caps doesn't make sense as the
upstream don't have to have compatible caps, thus resulting in an empty
caps set as a result of a caps query. Instead set fixed caps just
as funnel does.

https://bugzilla.gnome.org/show_bug.cgi?id=738722
rtspsrc: set full stream caps on internal src TCP pads

Set the complete stream caps on the TCP internal src pads. Otherwise,
ptdemux will not properly detect the caps change.

https://bugzilla.gnome.org/show_bug.cgi?id=737868
jitterbuffer: rework resync handling

Add a need-resync state, this is when we need to try to lock on to a
time/RTPtime pair.
Always check the RTP timestamps and if they go backwards, mark ourselves
as need-resync.
Only resync when need-resync is TRUE and we have a valid time. Otherwise
we keep the old values. This avoids locking on to an invalid time and
causing us to timestamp everything with -1.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=730417
Automatic update of common submodule

From 36388a1 to a8c8939
rtpjitterbuffer: make debug line less confusing
Automatic update of common submodule

From a8c8939 to 84d06cd
rtpsession: fix Early Feedback Transmission

In early retransmission we are allowed to schedule 1 regular RTCP packet
at an earlier time. When we do that, we need to set allow_early to FALSE
and ignore/drop (or merge) all future requests for early transmission.
We now first check if we can schedule an early RTCP and if we can,
actually prepare the data for the next RTCP interval.

After we send the next regular RTCP after the early RTCP, we set
allow_early to TRUE again to allow more early requests.

Remove the condition for the immediate feedback for now.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=738319
jitterbuffer: Refactor code

Refactor some code dealing with calculating various timeouts.

See https://bugzilla.gnome.org/show_bug.cgi?id=735378
gstrtpjitterbuffer: add "rtx-min-delay" property

This property is useful to set a min time to wait before sending a
retransmission event.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=735378
rtpjitterbuffer: limit the retry frequency

When the RTT and jitter are very low (such as on a local network), the
calculated retransmission timeout is very small. Set some sensible lower
boundary to the timeout by adding a new property. We use the packet
spacing as a lower boundary by default.
pulsesink: Temporarily disable stream status posting

We need a mechanism in PulseAudio to allow running code outside the
mainloop lock. Then we'd be able to post to the bus (taking the
GST_OBJECT_LOCK), without worrying about locking order with the mainloop
lock, which is the current cause of deadlocks while trying to post the
stream status messages.

https://bugzilla.gnome.org/show_bug.cgi?id=736071