gdkpixbufoverlay: remove spurious @see_also
shout2send: docs, add a sample pipeline

And finish adding shout2send to the docs while at it

https://bugzilla.gnome.org/show_bug.cgi?id=721342
shout2send: clarify meaning of the URL prop

https://bugzilla.gnome.org/show_bug.cgi?id=721342
shout2send: change audio_format field to format

This element and the underlying libshout2 library
can handle video media files too. The code already
handles video/webm so the name gets confusing. Also
add and use DEFAULT_FORMAT macro Instead of hardwiring
SHOUT_FORMAT_VORBIS at init

https://bugzilla.gnome.org/show_bug.cgi?id=721342
souphttpsrc: use status code macro instead of 407

Rest of the code is using the _PROXY_AUTHENTICATION_REQUIRED
macro too. Easier to understand if you don't recall HTTP
error codes by heart.
doc: add design for rtp retransmission

Describe how rtprtxsend and rtprtxreceive generally work
but also how the association algorithm is implemented.
rtpmanager: add new rtprtxsend / rtprtxreceive elements

The purpose of the sender RTX object is to keep a history
of RTP packets up to a configurable limit (in time). It will
listen for custom retransmission events from downstream. When
it receives a request for retransmission, it will look up the
requested seqnum in its list of stored packets. If the packet
is available, it will create a RTX packet according to RFC 4588
and send this as an auxiliary stream.

The receiver will listen to the custom retransmission events
from the downstream jitterbuffer and will remember the SSRC1
of the stream and seqnum that was requested. When it sees a
packet with one of the stored seqnum, it associates the SSRC2
of the stream with the SSRC1 of the master stream. From then
on it knows that SSRC2 is the retransmission stream of SSRC1.
This algorithm is stated in RFC 4588. For this algorithm to
work, RFC4588 also states that no two pending retransmission
requests can exist for the same seqnum and different SSRCs or
else it would be impossible to associate the retransmission with
the original requester SSRC.
When the RTX receiver has associated the retransmission packets,
it can depayload and forward them to the source pad of the element.

RTX is SSRC-multiplexed

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=711084
tests/check: add rtprtx::test_push_forward_seq

add simple unit test that manually push buffers
in rtprtxsend connected to rtprtxreceive.
Drops some buffers and make sure they are retransmisted.
tests/check: add rtprtx::test_drop_one_sender unit test

Test for one sender / one receiver

Build the pipeline
videotestsrc ! rtpvrawpay ! rtprtxsend ! rtprtxreceive ! fakesink
and drop some buffers between rtprtxsend and rtprtxreceive
Then it checks that every dropped packet has been re-sent.
It also checks that not too much requests has been sent.
tests/check: add rtprtx::test_drop_multiple_sender unit test

Several senders / one receiver

Similar than test_drop_one_sender but with multiple senders
mixed through the funnel element.
It drops some packets and checks that they are retransmited
correctly.
tests/check: Add rtprtx::test_rtxsender_packet_retention

This unit test verifies that the rtxsend element correctly maintains
a buffer of already transmitted rtp packets and that it can
re-transmit all of them correctly on demand. It also verifies
that the limit of this buffer (max-size-packets property) is respected.
rtprtxsend: keep important buffer information in a private structure

This is to avoid mapping a buffer every time we need to read a seqnum
or a timestamp.
rtprtxsend: Handle the max_size_time property

This property allows you to specify the amount of buffers
to keep in the retransmission queue expressed as time (ms)
instead of buffer count (which is the max_size_buffers property).
tests/check: Add unit test for rtxsend's max_size_time property
rtprtxsend: retransmit packets in the same order as the rtx requests
rtprtxsend: use a GSequence to implement the buffer queue

This has the advantage that searching the queue to find the
buffer with the requested seqnum is done with binary search.
rtprtxsend: use a realistic limit for the value of max-size-packets

G_MAXINT16 is chosen because if the queue contains more than
G_MAXINT16 packets, seqnum comparison will not work properly.
tests/check: add rtprtx::test_rtxreceive_data_reconstruction

This unit test verifies that retransmitted rtp packets coming out
of rtprtxreceive are the same as the original ones.
tests/check: add rtpcollision::test_rtx_ssrc_collision unit test

check that rtxrtpsend changes its retransmission ssrc when
collision happens
tests/check: add rtpaux::test_simple_rtpbin_aux

It shows how to use "set-aux-receive" and "set-aux-send"
properties of rtpbin to set rtprtxsend and rtprtxreceive

Build 2 pipelines, one for rtpbin as a sender and one for
rtobin as a receive. Then transmit an audio stream.

It also drops some packets to activate restransmission and
check they are actually retransmited.