GitLab

The payloader didn't copy anything so far, the depayloader copied every
possible meta. Let's make it consistent and just copy all metas without
tags or with only the video tag.

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

The doc generator isn't happy when we have class name clash. Simply
use it's own namespace.

unused local variable 'delay' is removed.

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

This commit adds support for ISOBMFF Common Encryption (cenc), as
defined in ISO/IEC 23001-7. It uses a GstProtection event to
pass the contents of PSSH boxes to downstream decryptor elements
and attached GstProtectionMeta to each sample.

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

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

The default behaviour was changed in the 0.10 -> 1.x
transition, but the comment was not updated.

rtptheorapay: Extract pixel format from the ident header to put it into the sampling field of the caps

We always put 4:2:0 into the caps before, which obviously is wrong for 4:2:2
and 4:4:4 formats.

GstRTSPMedia uses this classification to detect the real payloader
inside a dynpay bin and asserts if it doesn't find it, therefore
it is required

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

1) Tests that using dynamic PT instead of the default ones work
2) If we ever decide to change the codec here we don't need to
   worry about change the PT for the default one of the new codec
   in the test

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

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

Initialize the PT to the default value of the codec and check if
it is still the default before declaring the pt to be dynamic or
not when setting the caps.

Also use the PT constants from the rtp lib when possible

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

It will be used in some cases for getting the correct offsets
from trun atoms.

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

Handle the flag from the tfhd that signals the base offset to
start from the moof atom

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

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

The RTP PT for alaw is 8.
Less than 50 packets are received in the length of this test so it
would never drop a buffer or would drop only the last buffer and
it would fail sometimes when the received wouldn't receive the
retransmission packet in time.

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

We need a proper caps event from upstream with the full RTP caps as we can't
create caps ourselves from thin air. Fixes usage of rtpstreamdepay after e.g.
a filesrc or any other element that supports pull mode.

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

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

h264parse does the same, let's keep the behaviour consistent. As we now
include the codec_data inside the stream too here, this causes less caps
renegotiation.

The spec says:

When a picture parameter set NAL unit with a particular value of
pic_parameter_set_id is received, its content replaces the content of the
previous picture parameter set NAL unit, in decoding order, with the same
value of pic_parameter_set_id (when a previous picture parameter set NAL unit
with the same value of pic_parameter_set_id was present in the bitstream).

If the GOP is completed, pads have to start gathering for the
next one but it is possible that the the state might go to
COLLECTING_GOP_START and back to WAITING_GOP_COMPLETE before the
thread has a chance to wake up and proceed, leaving it trapped in
the check_completed_gop loop and deadlocking the other threads
waiting for it to advance.

To solve it, this patch also checks that tha input running time
hasn't changed to prevent this scenario.

h264parse does the same and this fixes decoding of some streams with 32 SPS
(or 256 PPS). It is allowed to have SPS ID 0 to 31 (or PPS ID 0 to 255), but
the field in the codec_data for the number of SPS or PPS is only 5 (or 8) bit.
As such, 32 SPS (or 256 PPS) are interpreted as 0 everywhere.

This looks like a mistake in the part of the spec about the codec_data.

1) If the system http_proxy environment variable is not set
or set to an empty string, we must not set proxy to avoid
http connection error.

2) In case of proxy property setting, if user want to clear
the proxy setting, they should be able to set it to NULL or
an empty string again, so this is fixed too.

3) Check if the proxy string was parsed correctly.

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

Remove unused variable 'framecount' from dvdemux

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

In media to caps function, reserved_keys array is being used for variable i,
leading to GLib-CRITICAL **: g_ascii_strcasecmp: assertion 's1 != NULL' failed
changed it to variable j

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

process_rtp_packet doesn't transfer the rtp buffer to mp4v_process_depay
the refernce should not be removed here

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

Skip keys from the fmtp, which we already use ourselves for the
caps. Some software is adding random things like clock-rate into
the fmtp, and we would otherwise here set a string-typed clock-rate
in the caps... and thus fail to create valid RTP caps

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

As a fallback, look for a pad template sink_%d on
the muxer when requesting pads, to support mpegtsmux

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

Don't hold the main splitmux part lock over
the parent state change function, as it prevents
posting error messages that happen. Since the purpose
is to prevent typefinding from proceeding, use a
separate mutex just for that.

After adding to tag list, key_val is not being free'd
resulting in memory leak

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

'NONE' and 'raw ' fourcc don't always contain U8 audio, it can
be more bits as well, in which case it's just like 'twos'.

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

This limit was arbitrary. We still fixate near 100pfs for compatibility.

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

This could just be a normal pipeline shutdown.