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

Avoid using soup_server_run_async and old get_port() APIs,
replace with me soup_server_listen and get the port through the
URIs list returned from the server.

It causes the entire pipeline to fail, it should be easier to find.

When switching fragments, hide the async-start/async-done
messages from the parent bin, as otherwise we sometimes (very rarely)
hang in PAUSED instead of returning / continuing to PLAYING
state.

Fixes criticals with e.g.
videotestsrc num-buffers=1 ! identity drop-probability=1.0 ! avimux ! fakesink

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

1. according to RFC, T bit is only set when either the RTP packet only contains the J2K main header, or the packet contains tile parts from multiple tiles. This is now being managed correctly in the code. The second scenario cannot happen with our payloader, since tile headers are always placed in their own RTP packet, and so a packet cannot contain tile parts from multiple tiles.
However, I have added code to track if multiple tile parts are included in a single RTP packet, in case in the future we want to put header and data in same packet.

2. Old code would set the tile id to zero for all J2K packets. This is now set correctly to the appropriate tile id.

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

J2K main header framentation across multiple RTP packets is now handled correctly

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

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

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

Make sure that src pad has caps before sending segment event.

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

The signal handlers might want to actually get the value of the stats
property, which would take the session lock again and deadlock.

This was introduced by 2e960e70.

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

Properly handle edts segments for push-based operation seeking.
We only support edts that a single segment that has media at the end,
being preceeded by any number of gap segments.

This also allows the qt segment rate to be respected after seeks

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

Also use the qt rate to identify the position within a qt segment
to properly translate playback time to qt media time

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

When a packet arrives that has already been considered lost as part of a
large gap the "lost timer" for this will be cancelled. If the remaining
packets of this large gap never arrives, there will be missing entries
in the queue and the loop function will keep waiting for these packets
to arrive and never push another packet, effectively stalling the
pipeline.

The proposed fix conciders parts of a large gap definitely lost (since
they are calculated from latency) and ignores the late arrivals.

In practice the issue is rare since large gaps are scheduled immediately,
and for the stall to happen the late arrival needs to be processed
before this times out.

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

The access to the session hash table must happen while the session lock is
taken, otherwise another thread might modify the hash table while we're
creating the stats.

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

Otherwise the old segment will have a shorter stop time and would
cause the stream to end too early.

One that updates and push a new segment, the other will move the
stream to the new segment starting position