GitLab

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

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

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

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

Add code to copy tiled planes.

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

Move the tile helper functions to their own file. Make it possible to
make other tiling modes later.

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

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

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

Adds a test that simulates a scenario where the first buffers after
a segment can't be decoded and the decoder asks for those frames
to be released. The videodecoder base class should make sure that
the events attached to those first buffers are pushed even if the
buffers aren't going to be.

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

Events must be persisted after a frame is dropped to avoid
losing obligatory information for the stream.

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

Checks that buffers are pushed backwards in reverse playback

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

For reverse playback, the segment event will only be pushed when
the first buffer is actually pushed. But for decoding frames and storing
those into the list to be pushed the output_segment.rate value is used
to determine if it is forward or reverse playback.

In case a previous segment event (or none) is in use it will mistakenly
think it is doing forward playback and push the buffers immediatelly and
try to clip buffers based on an old segment (or an uninitialized one, leading
to an assertion)

This patch fixes this by copying the segment earlier if on reverse playback

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

The new switch caused breaks to not break of the main switch
anymore, causing fall through.

This fixes asserts in pipelines such as:

gst-launch-1.0 videotestsrc num-buffers=1000 ! x264enc ! h264parse ! \
   matroskamux name=mux ! filesink location=test.mkv

Rework the orc code to be around 10% faster and support arbitrary matrices.
Pass the matrix parameters to the YUV->RGB functions to make them work
for all matrices. This enables more and faster fastpath conversions.

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

Calculate alpha value differently so that we can avoid running out
of registers.

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

Tests that events are properly serialized with buffers, also checks
that the usual events are sent (stream start, caps, segment and eos).

Add a simple playback test that makes sure that video decoder pushes
buffers in the same order it receives and that it respects the
set timestamps and durations

Add an internal method to calculate the default lower transport whan it
is missing.

Add a method to make a media-type from the transport. Deprecate the old
method that only used the mode.

Based on patch from Aleix Conchillo Flaqué <aleix@oblong.com>

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

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

Detect and describe the RF64 Broadcast Wave Format.
Fixes #519220

This chunk is avi specific, no need to expose this as public api.

Nikon cameras store metadata in a custom format. Add parsing of the chunk and
extract some initial data.
API: gst_riff_parse_ncdt()
Fixes #636143

Port a change from audiobasesink from def07410, to ignore setcaps
when the caps don't actually change, and avoid a reconfiguration
and reset of the ringbuffer in that case.

The test verifies that the NEON C intrinsics work, but the rest of the
codebase uses lots of direct ARMv7 NEON assembly. The same intrinsics
work in A64, but the assembly is slightly different.

Prevent the check from passing so that we don't use this where it won't
work.

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

Add id3 tag for wavparse

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

This reverts commit 40fe5dcc.

Using an idle probe here is not ideal because we'll send an EOS event
from the application thread... which might block for quite some time.
Go back to a block probe.

Otherwise our caps will not be compatible with elements that require a
1/1 pixel-aspect-ratio or progressive video.

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