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

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

Looks like it just uses the NAL enums and nothing else from
the codecparsers, and that's the only reason it had to be
moved from -good to -bad when it was originally added. We
can probably keep those NAL enums up to date enough, so let's
remove the codecparser dependency so it can be moved back into
-good.

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

Move RTP H.265 payloader/depayloader from -bad to -good.

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

Use gst_rtp_drop_meta() and the same function prototype for
gst_rtp_copy_meta() to keep consistency with the RTP elements in
gst-plugins-good

Only consider the access unit complete when the next-occurring VCL NAL unit
has the first bit after its NAL unit header equal to 1.

We create a sub-buffer just to copy over its metas and then throw it
away immediately, just use the original input buffer directly.

It's not enough to have timeout or event based VPS/SPS/PPS information
sent in RTP packets. There are some scenarios when key frames may appear
more frequently than once a second, in which case the minimum timeout
for "config-interval" of 1 second for sending VPS/SPS/PPS isn't enough.
It might also be desirable in general to make sure the VPS/SPS/PPS is
available with every keyframe (packet loss aside), so receivers can
actually pick up decoding immediately from the first keyframe if
VPS/SPS/PPS is not signaled out of band.

This commit adds the possibility to send VPS/SPS/PPS with every key frame.
This mode can be enabled by setting "config-interval" property to -1. In
this case the payloader will add VPS, SPS and PPS before every key (IDR)
frame.

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

This way we can use -1 as special value, which is nicer than MAXUINT.

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

Call handle_nal for each NAL in the STAP-A RTP packet. This makes sure
we correctly extract the SPS and PPS.

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

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

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

A race condition in the state change function may cause buffers to be
unreffed while they are still used by the streaming thread in
gst_rtp_h265_pay_send_vps_sps_pps() resulting in a crash. Chain up to the
parent class first in the state change function to make sure streaming
has stopped and only then free those buffers.

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

Fixes a buffer leak that would occur if the pipeline was shutdown while a
SPS/PPS header was being created.

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

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

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

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

h264parse and gstrtph264depay do the same, let's keep the behaviour
consistent. As we now include the codec_data inside the stream, this causes
less caps renegotiation.

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

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

rtph264depay 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 spect about the codec_data.

For more optimised RTP packet handling: means we don't need to map the
input buffer again but can just re-use the mapping the base class has
already done.

Based on: https://bugzilla.gnome.org/show_bug.cgi?id=750235

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

Switching to GST_BUFFER_TIMESTAMP() to be consistent with other rtp code.

This causes an assertion and would lead to getting a NULL instead
of a buffer. Without proper checking this would easily lead to a
segfault.

Related to rpth264depay: https://bugzilla.gnome.org/show_bug.cgi?id=737199

Value set to ret will be overwritten at least once at the end of the while
loop, removing assignment.

This were probably added to the enums due to cargo cult programming and are
unused.

donl_present is not implemented, yet the value is set and checked a few times.
Cleaning this.

CID #1249687

type is truncated to 0-31 with "& 0x1f", but right after that it is checks if
the value is equivalent to GST_H265_NAL_VPS, GST_H265_NAL_SPS, and
GST_H265_NAL_PPS (which are 32, 33, and 34 respectively). Obviously, this will
never be True if the value is maximum 31 after the truncation.
The intention of the code was to truncate to 0-63.

After further investigation the previous commit is wrong. The code intended to
check if the type is 39 or the ranges 41-44 and 48-55. Just like gsth265parse.c
does. Type 40 would not be complete.

nal_type is the index for a GstH265NalUnitType enum. There are two types of dead
code here:
First, after checking if nal_type is >= 39 there are two OR conditionals that
check if the value is in ranges higher than that number, so if nal_type >= 39
falls in the True branch those other conditions aren't checked and if it falls
in the False branch and they are checked, they will always also be False. They
are redundant.
Second, the enum has a range of 0 to 40. So the checks for ranges higher than 41
should never be True.
Removing this redundant checks.

CID 1249684

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

The running average was wrong and the resulting scaling factor was only held in
place using the CLAMP. In addtion we are now convering quickly to volume
changes.

FInally now with this change, we can change the resolution defines and
everythign adjusts.

Make all the drawing ops be based on the constants. This way we can change
the fixed size at least at compile time.

This at least establishes the relationship.

Replace all #defines with members and initialize the convolver with a parameter.

We can already create multiple instances.

Use constants more often. Cleanup comments and add more to explain how things
work.

Commit bd27a1f3 added a few error handling
memory management checks. These check srccaps to see if it needs to be
unreferenced before returning, in the case of invalid_caps this goto jump
always happens before srccaps is set, so it will always be NULL in this
error label.

CID #1352035

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

To match commit 7d7074ce. I love the idea
of aiming for the maximum number of consecutive vowels.

Didn't know which one to choose between queuing and queueing, so I picked
the one with the biggest amount of vowels in a row ;-P (both are
acceptable apparently)