GitLab

Based on the expected output from the already existing usage by androidmedia
and the opengl plugins.

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

Attempt to reproduce leak.

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

It internally uses gst_check_chain_func() so we
should call gst_check_drop_buffers() when tearing down tests to free
the buffers which have been exchanged through the pipeline.

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

It internally uses gst_check_chain_func() so we
should call gst_check_drop_buffers() when tearing down tests to free
the buffers which have been exchanged through the pipeline.

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

It internally uses gst_check_chain_func() so we
should call gst_check_drop_buffers() when tearing down tests to free
the buffers which have been exchanged through the pipeline.

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

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

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

They are currently not used, but would result in a compiler error due to wrong
variable name usage.

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

Instead of silently returning GST_STATE_CHANGE_FAILURE.

When we initialize an element in decodebin, we 1) set it to PAUSED and
push sticky events on its sinkpad to trigger negotiation 2) block its
src pad(s) to detect CAPS events. We can't block before 1) as that
would lead to a deadlock.

It's possible (and common) tho that an element configures its srcpad
during 1) and before 2). Therefore before this change we would
typically block and expose an element's pad only once the element
output its first buffer, triggering sticky events to be resent. One
consequence of this behaviour is that it sometimes broke
renegotiation.

With this change now we consider a pad ready to be exposed when it's
->blocked or has fixed caps (which were set before we could block it).

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

So upstream gets a smaller set to decide upon as it is what it requested
with the filter

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

The library is capable of converting to different rates.

Includes tests.

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

Remove restrictions when rate is 48000, the underlying lib supports
converting any of the input to any of the output rates.

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

Easier to read and maintain

If we e.g. have AVI with DV container with video/audio inside the DV
container, we can't handle this at this point with an encoding profile.
Instead of erroring out, flatten the container hierarchy.

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

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

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

This tag match the EXIF_TAG_FOCAL_LENGTH_IN_35_MM_FILM exif tag and is
stored on a short. Hence there is a precision loss compared to the
GstTag which is a double value.

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

It is the 35 mm equivalent focal length of the lens, mainly used in
photography. Tag value is stored in a double value to be consistent with
GST_TAG_CAPTURING_FOCAL_LENGTH.

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

The caps returned by gst_pad_get_allowed_caps() was leaked.

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

e.g., allows this to be used with the reference retrieved by
gst_event_parse_segment().

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

When ximagesink is given a new window handle, it should check
its geometry and if the size of the new window differs from
the previous one, create reconfigure event in order to get
a chance to negotiate a more suitable image resolution with
the upstream elements.

We can't rely on receiving Expose or ConfigureNotify from
the X server for the newly assigned window, which would also
generate reconfigure.

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

... and don't try to push pending data without ever having received a SEGMENT
event before EOS

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

Don't put level=0 into the caps, it confuses other elements.

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

Don't put level=0 into the caps, it confuses other elements.

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

When converting discoverer output to an encoding profile, it makes sense to
omit these. It's very very unlikely that our encoder is going to produce bit
by bit the same codec_data or streamheader.

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

It should only be around our own declarations.

Use the I420->BGRA and a new I420->ARGB to speed up any I420 to RGB
operation.

As we decided to backport some fixes we update the since markers.

If we are configured to use buffering and there is no demuxer in the chain, we
still want a multiqueue, otherwise we will ignore the use-buffering property.
In that case, we will insert a multiqueue after the parser or decoder - not
elsewhere, otherwise we won't have timestamps.

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

So we can use gst-play to track memory leaks.

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

This reverts commit 13ee94ef.

Causes audio glitches at startup by starting to output segments
from the ringbuffer before it has been filled / fully prerolled.

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

We add a couple of new functions gst_sdp_media_parse_keymgmt and
gst_sdp_media_parse_keymgmt. We also implement
gst_sdp_message_attributes_to_caps and gst_sdp_media_attributes_to_caps
in terms of these new functions and also gst_mikey_message_to_caps.