shout2send: accept audio/webm, audio/ogg and video/ogg as well

Those are advertised in the template caps, but the
setcaps handler didn't handle them. But then oggmux
and oggparse at least for now still always output
application/ogg anyway, so that wasn't a real problem.
shout2send: error out if no caps were received

Instead of assuming that input is ogg.
rtprtxsend: run a new GstTask on the src pad

The reason behind this is to minimize the retransmission delay.
Previously, when a NACK was received, rtprtxsend would put a
retransmission packet in a queue and it would send it from chain(),
i.e. only after a new buffer would arrive.

This unfortunately was causing big delays, in the order of 60-100 ms,
which can be critical for the receiver side.

By having a separate GstTask for pushing buffers out of rtxsend,
we can push buffers out right after receiving the event, without
waiting for chain() to get called.
rtprtxsend: ensure that no rtx buffers are sent after EOS

To do that, enqueue the EOS event to be sent from the srcpad task
thread and flush the queue right afterwards, so that no more rtx
buffers can be sent, even if there are more requests coming in.

Fixes https://bugzilla.gnome.org/show_bug.cgi?id=722370
tests: rtprtx::test_push_forward_seq: fix buffer refcounting
tests: rtprtx::test_push_forward_seq: fix race condition

Now with rtprtxsend pushing rtx buffers from a different thread,
this is necessary to ensure that the result of the test is deterministic.

This code makes use of GstCheck's global GMutex and GCond that are
being used inside GstCheck's sink pad chain() function in order
to synchronize with it.
tests: rtprtx::test_rtxsender_packet_retention: fix race condition

Now with rtprtxsend pushing rtx buffers from a different thread,
this is necessary to ensure that the result of the test is deterministic.

This code makes use of GstCheck's global GMutex and GCond that are
being used inside GstCheck's sink pad chain() function in order
to synchronize with it.
tests: rtprtx::test_rtxreceive_data_reconstruction: fix race condition

Now with rtprtxsend pushing rtx buffers from a different thread,
this is necessary to ensure that the result of the test is deterministic.

This code makes use of GstCheck's global GMutex and GCond that are
being used inside GstCheck's sink pad chain() function in order
to synchronize with it.
tests: rtprtx::test_rtxreceive_data_reconstruction: remove useless code for triggering retransmission

There is no need anymore to push yet another buffer in rtxsend
in order to trigger the previously requested retransmissions
to actually happen.
matroskaparse: better default caps when none set

Uses information gathered during EBML parsing to
forge a more suitable set of caps instead of blindly
assuming everything is video/x-matroska.

For consistency, stream type reset was added to
matroska-demux too.

https://bugzilla.gnome.org/show_bug.cgi?id=722311
rtpjitterbuffer: ignore invalid timestamps in rtt calculation

When the input buffer does not have a valid timestamp, don't try to
calculate the round-trip-time.
rtxreceive: copy flags and timestamps from original buffer
rtpbin: add a caps accumulator for the request-pt-map signal

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.
rtpjitterbuffer: handle expected packet being an RTX packet

If the expected packet (do_next_seqnum is TRUE) is the one we requested
for retranmission earlier, do the logic to update the retransmission
statistics as well before setting up the timers for the next expected
packet.
Also reset the retransmission counter if the timer is reused for another
seqnum.