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

- use GST_CHECK_MAIN() to reduce boilerplate
- unref the input caps using a teardown function to prevent leaks

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

The output of deinterlace at startup, or when receiving a new DISCONT
buffer, should have the DISCONT flag set on the first buffer.

Discard buffers that doesn't contain enough data when dealing
with raw video inputs.

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

Upstream might have told us something about the to be expected segment, so
let's use that information instead of coming up with a [0,-1] segment.

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

But in that case also remove the pending newsegment event, otherwise we would
later send a possibly outdated event.

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

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

The point of d8fb7a9c was to not have any
spurious segments stored for later if we do BYTES->TIME conversion, but
overriding any TIME segments from upstream does not make any sense.

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

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

query position in GST_FORMAT_BUFFER returns
offset from start-index rather than index.

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

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

Input buffer memory was not unmapped

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

Guillaume Desmottes authored May 18, 2016 and Nicolas Dufresne committed May 25, 2016

gst_v4l2_object_probe_caps() was taking an extra ref on the returned
caps for no reason.

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

When early returning in gst_soup_http_src_read_buffer() because the
element is FLUSHING, we need to unmap and unref the buffer which was just created.

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

Some were forgotten.

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

avidemux: Pass through seek event seqnums in all SEGMENT/EOS events and SEGMENT_DONE messages/events

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

Also actually store the seqnum in pull mode seeks.

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

The caps returned by gst_pad_get_current_caps() was never unreffed when
not early returning.

Fix a leak with the elements/deinterlace test.

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

Some endpoints (like Tandberg E20) can send BYE packet containing our
internal SSRC. I this case we would detect SSRC collision and get rid
of the source at some point. But because we are still sending packets
with that SSRC the source will be recreated immediately.
This brand new internal source will not have some variables incorrectly
set in its state. For example 'seqnum-base` and `clock-rate` values will be
-1.
The fix is not to act on BYE RTCP if it contains internal or unknown
SSRC.

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

Keeping the lock while emitting the stats signal introduces potential
deadlock in those situations when the signal callback wants the access
to rtpsession's properties which also requre the lock.

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

matroskademux would take the GST_OBJECT_LOCK in
- gst_matroska_demux_push_codec_data_all()
- gst_matroska_demux_query()

Some parse element such as FLAC checks upstream seekability, and
there is some use cases that matroska-demux is linked to a parse element
(e.g.,FLAC format) without intermediate elements (e.g., queue).
In this case, matroska-demux never returns from _push_codec_data_all()
because the parser can return only after it receives the response to
the upstream query, but that's not going to happen because it's
deadlocked.

Elements must not hold the object lock whilst pushing out events
or data.

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

Otherwise we might use an already freed list later and crash or worse.

gst_system_clock_obtain() returns a new ref.

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

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

Fix a race in splitmuxsrc by properly connecting to the
demuxer signals we're interested in *before* setting it running.

The GST_BUFFER_OFFSET of output buffers returned to GstRtpBasePayload
should reflect the number of "samples" in the unit of the RTP clock in this
buffer. If this is not true, then it shouldn't be set.

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

Just use g_strcmp0 which can handle NULL entries

Directly setting audio/x-raw caps leads to problems when the delivered
data blocks do not align properly at sample boundaries (for example, a
data block with 391 bytes). So, instead, set audio/x-unaligned-raw to
let a parser be autoplugged.

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

segment_duration and media_time should be parsed based on version
of elst box. Specification defines that an elst box with version 1
has uint64 and int64 values for segment_duration and media_time,
respectively.

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

It might be that the request was aborted by the application and
we can return immediatelly

Remove from the session creation parameters

We already depend on 2.48

Non-blocking read will return the amount of data available without
blocking to wait for the full requested size.

The downside is that now it souphttpsrc needs to have a waiting
mechanism in case there is no data available yet to avoid busy
looping arond the inputstream.

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

Set the async-handling property on GstBin to let it manage
async-handling instead of the local handling from the previous
commit. Works because of #174a5e in core

Replace the async API with the sync API to remove all the extra mainloop
and context handling. Currently it blocks reading until 'blocksize'
bytes are available but that can be improved by using:

https://developer.gnome.org/gio/unstable/GPollableInputStream.html#g-pollable-input-stream-read-nonblocking

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