Fix following build error

gstv4l2object.h:197:17: error: unknown type name ‘off_t’
       gint fd,  off_t offset);
                 ^

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

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

Comes from gpac apparently. The codec_data uses the same packing
mechanism as matroska.

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

The value stored in cenc_aux_sample_count wasn't in sync with the
parsing code that followed which checks whether all entries are
valid and present.

Only write the actual sample count when we know for sure.

CID #1427087

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

This exposes a new property, mtu, which is used to determine the
initial size of buffers from the buffer pool. If received data
exceeds this, the element gracefully handles that in a manner similar
to what we had previously: a large memory gets filled and reallocated
at the next call to "fill".

The default size is set to 1500, which should cover most use cases.

With contributions from Mathieu Duponchelle <mathieu@centricular.com>

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

Optimize GstUdpSrc for cache performance.

Move the hot properties, which are used by the read function, to the top:
@used_socket, @addr, @cancellable, @skip_first_bytes, @timeout,
@retrieve_sender_address.

Remove the unused property @ttl.

Where needed reorder so that holes are avoided (the 64-bit @timeout)

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

The samples table is sorted by DTS, not PTS. As such we can only get the
correct result when using a binary search on it, if we search for the
DTS.
Also if we only ever search for the frame, where the following frame is
the first one with a PTS after the search position, we will generally
stop searching too early if frames are reordered.

In forwards playback this is not really a problem (after the decoder
reordered the frames, clipping is happening), in reverse playback
it means that we can output one or more frames too few as we stop too
early and the decoder would never receive it.

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

By moving variable declarations out of loop headers.

As on Ubuntu Trusty.

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

76e458a1 changed the conditions from
"queued > threshold" to "queued >= threshold", which broke hlssink2 and
resulting in too small fragments being created although keyframes would
be at *exactly* the configured threshold.

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

Fix compilation with MSVC. We still assume that attribute
is supported by all other relevant compilers, which seems
to be the case since we haven't had any complaints about
similar code in rtpsbcpay.

Use GLib macro instead, even if it's a bit unwieldy.

Fixes build with MSVC, and possibly other compilers too.

These were missed when they were added to Makefile.am

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

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

The muxed buffers will not carry the duration of the
incoming buffers.

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

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

This works around a bug in various ONVIF cameras that implement the
attributes the wrong way around. They still won't work with a
backchannel but at least normal playback will work for the time being.
It restores pre-1.14 behaviour where we would fail to preroll on any SDP
that lists a recvonly stream. For 1.16 a better solution should be
found.

The problem here is that the ONVIF spec has the meaning of the two
attributes the wrong way around in the examples, compared to RFC4566.

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

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

The aggregator segment is now exposed on the src pad

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

As stated in commit c2956036b8da4b8f22a63a4f5a254be03e870aa6 in -bad,
the wasapi elements are now better than directsound, and should be
preferred if they are available.

For a later release, once the elements have more testing, we can
consider moving them to -good.

matroskamux: Only mark new clusters as keyframe if they start on a keyframe or we're muxing only audio

Based on a patch by Nicola Murino <nicola.murino@gmail.com>

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

Only up to timescale * G_MAXINT16 is possible as cluster duration, which
is already higher than our default value. Using higher values would
cause overflows and broken files.

Based on the investigation by Nicola Murino <nicola.murino@gmail.com>

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

Matroska does not support changing the stream type and stream properties
after the headers were started to be written, and for example H264
codec_data changes can't be supported.

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

The default of the allow-no-red-blocks property was changed in a
previous commit, thus breaking the test assumptions

rtpulpfeccommon.c:432:27: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 10 has type ‘guint64 {aka long long unsigned int}’

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

The ulpfecenc "mux-seq" and "ssrc" properties were initially added
because the element did more than implement ULPFEC. As it was
decided that FLEXFEC would be implemented in a separate element,
both properties are now unneeded and confusing.

Change the default for the ulpfecenc multi-packet property,
as it is expected that most users of this element will be protecting video
streams.

Change the default property for the rtpredenc allow-no-red-blocks
property, as it should also be its default mode of operation.

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

It is expected that when connecting to a stream that has
already started, the caps will only arrive at the interval
specified on rtpgstpay, we shouldn't be warning as this is
a normal mode of operation.

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