Previous patch would try to unref a buffer that was pushed downstream.

Instead only unref when/if needed and keep usage of the cleanup: goto
block

The previous patch added a check for a substream header after
gst_buffer_unmap(), which is incorrect.

If one requests the send_rtcp_src_%u pad before a recv_rtcp_sink_%u pad,
the session/pad would never be created and NULL was returned.
Switching the request order would work.

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

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

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

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

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

Fixing build error:

/run/build/gst-plugins-good/_flatpak_build/../tests/check/elements/mpg123audiodec.c:150: undefined reference to `gst_fft_s32_new'
/run/build/gst-plugins-good/_flatpak_build/../tests/check/elements/mpg123audiodec.c:151: undefined reference to `gst_fft_s32_window'
/run/build/gst-plugins-good/_flatpak_build/../tests/check/elements/mpg123audiodec.c:151: undefined reference to `gst_fft_s32_fft'
/run/build/gst-plugins-good/_flatpak_build/../tests/check/elements/mpg123audiodec.c:147: undefined reference to `gst_fft_s32_free'

Also fix temp file creation a bit.

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

From 48a5d85 to 3f4aa96

Fix chain function not handling not-linked from baseparse.

When an input data is separated into 2 buffers, the second buffer
would not be pushed into the adapter if baseparse returns not-linked
for first buffer.

This caused glitches when switching streams and selecting
a stream that was previously unselected.

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

Causes problems with the new gtk-doc 1.26 otherwise,
but is a good idea in any case.

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

With some fixes by me.

The plugin queued buffer data if not all buffer data fit
into a single RTP packet. Now RTP packets are pushed as long
as enough data is available.

This fixes a memory leak. When dropframe-threshold has been set,
libvpx may output less frames than the input ones, which causes
some GstVideoCodecFrames to queue up in GstVideoEncoder's internal
frame queue with no chance of ever being all released. And because
the frames keep references to the input buffers, the input buffer
pool keeps allocating new buffers and memory usage grows very fast.
For example the following pipeline's memory usage grows at a rate
of about 1GB per minute!

videotestsrc ! capsfilter caps=video/x-raw,width=1920,height=1080,framerate=30/1,format=I420 ! \
  vp8enc target-bitrate=1000000 end-usage=cbr dropframe-threshold=95 ! fakesink

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

Callers of the API (rtpsource, rtpjitterbuffer) pass clock_rate
as a signed integer, and the comparison "<= 0" is used against
it, leading me to think the intention was to have the field
be typed as gint32, not guint32.

This led to situations where we could call scale_int with
a MAX_UINT32 (-1) guint32 as the denom, thus raising an
assertion.

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

Also pass args as cpp_args.

For really long files such as contiguous recordings of a whole day, the
50MB limit is not sufficient.

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

We were reading at the completely wrong positions, 16 bytes later in the
data.

Also add support for high-aligned samples.

Only plugin entry points should be exported.

Currently plugins might export more symbols with
the meson build, as we don't have the exports
regexp there that we pass to libtool.

Fixing of leaking the text field of the GstWavParseNote and
GstWavParseLabl structure.

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

Cyril Lashkevich authored Aug 08, 2017 and Nicolas Dufresne committed Aug 08, 2017

JPEG formats are encoded, but they never have keyframe flag. But in
fact they are keyframes

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

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

This function no longer take ownership of the buffer.

CID 1414800

This was missing, preventing the encoder and decoder to work
properly. This also adds support for camera that would produce
VP9 (if that exists).

These have been copy pasted all over the place and are not used anymore.
All object have it's own category now. This fixes build warning since
the VP9 decoder had vp8 category declared.

This removes duplicated code across different codec.

This reduces the amount of code needed in each codec class.