This reverts commit f72c3cf71fde622067f41f31a53978ba4c94469d.

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

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

If there are RTCP buffers in the RTP stream, process them as
RTCP. This way, we want receive streams following RFC 5761

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

The extra caps entry in the template was making it sometimes
get plugged for any dynamically allocated payload type.

Avoid mapping the packet multiple times when sending RTP.

Store all info in the PacketInfo so that we can avoid mapping the packet
multiple times.

Rename a structure because we are also going to use this for the sender
bits.

Check for GST_SEEK_TYPE_NONE for stop poistion and only update
the stop time if it is requested. Otherwise just maintain whatever
was stored at the segment

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

In addition to a956a6ce

Thanks to iputinei for reporting this on IRC.

We keep the DTS and PTS in running-time inside the jitterbuffer. Make sure to
transform it back to a buffer timestamp before pushing out the buffer.

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

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

In the case the caps are actually NULL, we should just concider it the
same way as empty caps in that case.

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

After converting a seek from time to bytes, use the same seqnum
on the event that goes upstream

When the segment has a defined stop position, qtdemux should check
when streams reach this position and mark those as EOS. When all
streams are EOS it will return GST_FLOW_EOS to upstream to allow
the pipeline to finish instead of continuously consume buffers
from upstream that are not useful for the segment.

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

When handling seeks in push mode, qtdemux converts the seek to bytes
and pushes upstream. It needs to keep track of the seek and the
subsequent segment to be able to map them back to the requested
seek time and properly preserve the segment stop of the seek.

This is done by using the start offset in bytes of the seek,
that should be the same of the segment from upstream. And this
is also backwards compatible with what qtdemux already was using.

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

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

It is racy with multiple pads.

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

Ideally, this would be part of libgstvideo.
Prefixes videoconvert symbols with videomixer_.

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

Only wait for the STREAM_LOCK when we flushed something when sending
a command for PAUSED or PLAYING.

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

Make gst_rtspsrc_loop_send_cmd() return TRUE when the current
action has been flushed

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

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

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

gstudpsrc.c:855:15: error: #if with no expression

Handle streams that we can't seek in and ignore them in the
seek logic.

Or else we might deref a stream with a NULL strf.vids and segfault

Amendment 2 of ISO/IEC 14496-15 (AVC file format) is defining a new
structure for fragmented MP4 called "avc3". The principal difference
between AVC1 and AVC3 is the location of the codec initialisation
data (e.g. SPS, PPS). In AVC1 this data is placed in the initial
MOOV box (moov.trak.mdia.minf.stbl.stsd.avc1) but in AVC3 this data
goes in the first sample of every fragment (i.e. the first sample in
each mdat box).  The principal reason for avc3 is to make it easier
for client implementations, because it removes the requirement to
insert the SPS+PPS in to the decoder pipeline every time there is a
representation change.

This commit adds support for the "avc3" atom, which is almost identical
to the "avc1" atom, except it does not contain any SPS or PPS data.

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

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

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

On Windows it's not possible to bind to a multicast address
but the OS will make sure to filter out all packets that
arrive not for the multicast address the socket joined.

On Linux and others it is necessary to bind to a multicast
address to let the OS filter out all packets that are received
on the same port but for different addresses than the multicast
address

And deprecate the multicast-group property and replace it with the
address property.

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

And add some FIXMEs.