GitLab

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

Move Opus RTP depayloader/payloader from -bad to -good.

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

This is already supported for PUSH mode but was failing in PULL mode.
The aux info is sometimes stored in the mdat before the first sample,
so the loop task needs to pull data stored at that location and
perform the aux info cenc parsing.

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

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

In some cases the stream configuration can fail, for instance if the
stream is protected and no decryptor was found. For those situations
the demuxer shouldn't emit any data on the corresponding source pad of
the stream and bail out.

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

When the cenc metadata is stored outside of the moof box and the
stream is exposed it is possible that the cenc metadata hasn't been
processed yet while the first buffer is being pushed. When this
happens the buffer can't possibly be decrypted downstream so don't
push it.

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

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

Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.

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

Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.

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

This can happen when the pipeline is currently shutting down.

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

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

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

If we have an error during fwrite call, file stays open and thus next
incoming buffer will trigger an assert when trying to opening a new
file.
This happens if we do not restart element, file is closed at stop, and
if application handles the returned GST_FLOW_ERROR to keep bin alive.

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

Such files will not play on Android, because of bug in libwebm matroska parsing, which is still present in 6.0.1

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

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

This block is needed in the Matroska file, but data coming from
RTP may not have one.

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

... as streams are so ordered by id by e.g. decodebin
(and as typically already honoured by other demuxers).

VP9_PAY_PICTURE_ID_7BITS and VP9_PAY_PICTURE_ID_15BITS are mutually
exclusive options of the picture-id-mode. We can break after the
first case.

1 or 2 bytes need to be added to the header length depending on the
PictureID size.
https://tools.ietf.org/html/draft-uberti-payload-vp9-00#section-4.2

CID 1353479

buffer being mapped is not being unmapped in some cases

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

This is a normal scenario and should not be a warning.

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

This hasn't been touched for generations, doesn't work,
and is just causing confusion. We also don't want to
maintain these files manually.

Instead of erroring out, just use the default color table.

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

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

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

Probably found a bug as well, in that there are some timestamps in
there that are looking very wrong. (marked with FIXME)

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

Use fail_unless and friends instead of g_assert
Factor seq-num checking out to separate function
Check more return-values from push and crank and others

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

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

Set GSETTINGS_BACKEND=memory, apparently there's something
about fork() and the dconf backend (or whatever else that
drags in or activates) that messes up locking and causes
timeouts due to deadlocks in g_mutex_lock(), since
everything works fine with CK_FORK=no as well.

Otherwise it will be mapped writable all the time and we can't read from it
anywhere.

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

Make sure that the packets queued when detecting a big gap are pushed
after reset (5 consective seqnums) and not dropped.

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