GitLab

This will fix the compiler warning
"G_HAVE_ISO_VARARGS" is not defined, evaluates to 0 [-Wundef]

Tomasz Andrzejak authored Nov 13, 2018 and Sebastian Dröge committed Nov 21, 2018

This patch adds API in the audio decoder base class for setting the arbitrary
caps on the source pad.  Previously only caps converted from audio info were
possible.  This is particularly useful when subclass wants to set caps features
for audio decoder producing metadata.

The Y210 format was added in the middle of the formats enum and list,
introducing an ABI break.

This issue was detected thanks to the gstreamer-rs test harness.

Linus Svensson authored Oct 16, 2018 and Sebastian Dröge committed Nov 14, 2018

The current sequence number will be the one from the first RTP buffer
when a buffer list is pushed, but should be the last one.

Fixes #495

Sebastian Dröge authored Nov 07, 2018 and Edward Hervey committed Nov 12, 2018

This allows writing out data from caption meta and similar to VBI

Sebastian Dröge authored Nov 09, 2018 and Nicolas Dufresne committed Nov 12, 2018

We assume here the same data format for the user data as for the
DID/SDID: 10 bits with parity in the upper 2 bits. In theory some
standards could define this differently and even have full 10 bits of
user data but there does not seem to be a single such standard after
all these years.

Sebastian Dröge authored Nov 08, 2018 and Nicolas Dufresne committed Nov 12, 2018

And add the checksum to the data we test in the unit test.

Sebastian Dröge authored Nov 07, 2018 and Nicolas Dufresne committed Nov 12, 2018

It was giving type 2 for both variants.

Sebastian Dröge authored Nov 11, 2018 and Matthew Waters committed Nov 12, 2018

Currently in Python it would become a signed 64 bit value but should
actually be an unsigned 32 bit value with all bits set.

This is the same problem as with GST_MESSAGE_TYPE_ANY.

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

Sjoerd Simons authored Nov 09, 2018 and Nicolas Dufresne committed Nov 11, 2018

Rather then letting gst_gl_memory_setup_buffer guess the GL format used
for an eglimage after importing a dmabuf be explicit about it. This
fixes issues where dmabuf import may have used another format then
gst_gl_format_from_video_info would guess on the basis of the available
GL extensions.

In particular on etnaviv the gst_gl_format_from_video_info would
assuming a luminance + alpha GL format is used for YUY2, but the dmabuf
import will always use RG88. Which causes images to end up somewhat pink when
displayed on the screen.

Sjoerd Simons authored Nov 09, 2018 and Nicolas Dufresne committed Nov 11, 2018

When importing an egl image from dmabuf gst_gl_format_from_video_info
was used to work what the result GL format will be. Unfortunately that
will only work if the conventional format and the choosen DRM fourcc for
the format match up.

On etnaviv platforms there is no support for GL_EXT_texture_rg, so the
GL format chosen for YUY2 ends up being GST_GL_LUMINANCE_ALPHA. However
DRM does not do luminance + alpha as it's a legacy GL thing, so the
dmabuf import ends up using DRM_FORMAT_GR88.

To fix this, tie the DRM_FORMAT and the GL format together so they
always match up.

Sebastian Dröge authored Nov 04, 2018 and Sebastian Dröge committed Nov 05, 2018

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

We were reading more bytes than we allocated.

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

There is new code that ensures that we renegotiate after an
uploader transition if the negotiated caps have changed.

The problem is that the raw uploader will not really try and
fixate the input caps, but instead of return a subset with the
only the supported target texture.

This had two effect, raw uploads was always done renegotiated
once and the raw upload unit test was now failing as it didn't
expect a renegotiation.

As it's a valid check, simply relax the gst_caps_is_equal() check
and use a gst_caps_is_subset() instead.

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

The direct dmabuf upload does color conversion, so when it transforms
the caps, it replaces the format with all formats found through the
format query. When this uploader can't be used, it makes the upstream
source pick a unsupported format.

To fix this, we only append the caps with a list of format. So the
source will only pick one of these formats if the downstream preferred
format is not supported. A negotiation failure after this would be
normal.

This fixes pipelines without a glcolorconvert element.

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

wangfei authored Oct 09, 2018 and Nicolas Dufresne committed Oct 31, 2018

This pixel format is packed format with 4:2:2 sample and 10
available bits of each channel.

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

Philipp Zabel authored Oct 17, 2018 and Michael Olbrich committed Oct 30, 2018

Report in the DEBUG log if the driver does not support importing a given
format with linear modifiers non-externally.

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

Philipp Zabel authored Oct 17, 2018 and Michael Olbrich committed Oct 30, 2018

The EXT_image_dma_buf_import_modifiers extension [1] states regarding
eglQueryDmaBufModifiersEXT:

    The format must be one of those returned by the
    eglQueryDmaBufFormatsEXT command.

To comply with this requirement eglQueryDmaBufFormatsEXT must be called
before eglQueryDmaBufModifiersEXT.

[1] https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt

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

Philipp Zabel authored Oct 17, 2018 and Michael Olbrich committed Oct 30, 2018

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

Philipp Zabel authored Oct 17, 2018 and Michael Olbrich committed Oct 30, 2018

Calculate DRM fourcc and report to the DEBUG log about it only once
instead of three times in gst_egl_image_from_dmabuf_direct().

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

The idea is that some GPUs (like the Vivante series) can actually
perform the YUV->RGB conversion internally, so no custom conversion
shaders are needed. To make use of this feature, we need an additional
uploader that can import DMABUF FDs and also directly pass the pixel
format, relying on the GPU to do the conversion.

Based on patches from Nicolas Dufresne <nicolas.dufresne@collabora.com> and
Carlos Rafael Giani <dv@pseudoterminal.org>.

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

If a upload method is selected then use it exclusively in transform_caps().
Also, reconfigure if the current caps don't match the current upload
method.

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

This should not be necessary, but currently not all plugins that provide
dmabuf memory announce this with caps features, e.g. v4l2.
The static caps already contain the system memory. It didn't break before
because other upload methods provide the necessary transformation.

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

Reconfigure will trigger a set_caps which clears the upload method.
Remember the method in this case and start with it.
Wrap around once to try all methods if necessary.

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

The colorspace conversion happens during the upload so the necessary hints
must be provided to ensure that the conversion works correctly.

At least the Mesa Intel driver will create a texture without error but
produces an incorrect result. Use eglQueryDmaBufModifiersEXT() to check if
non-external upload is supported for the given format.

Based on a patch from Carlos Rafael Giani <dv@pseudoterminal.org>.

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

Nicolas Dufresne authored Jun 07, 2017 and Michael Olbrich committed Oct 30, 2018

gst_gl_memory_setup_buffer() was not properly using the number
of pointers to wrapped. This also fixes the validation, as we
only support 1 wrapper per view, or num_planes * views wrapper.

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

Seungha Yang authored Sep 27, 2018 and Tim-Philipp Müller committed Oct 17, 2018

Use 'copy' keyword to avoid meson warning message.
Note that 'copy' keyword in configure_file() is available
since meson 0.47.0

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

Otherwise it's very easy to miss them when gst_video_frame_map() fails

rtsp_connection_send takes care of adding those already,
and some reverse proxies such as nginx will reject the request
altogether if the Authorization header is present twice,
even with the same value.

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

Stian Selnes authored Oct 10, 2018 and Olivier Crête committed Oct 10, 2018

Add a source-info property that will read/write meta to the buffers
about RTP source information. The GstRTPSourceMeta can be used to
transport information about the origin of a buffer, e.g. the sources
that is included in a mixed audio buffer.

A new function gst_rtp_base_payload_allocate_output_buffer() is added
for payloaders to use to allocate the output RTP buffer with the correct
number of CSRCs according to the meta and fill it.

RTPSourceMeta does not make sense on RTP buffers since the information
is in the RTP header. So the payloader will strip the meta from the
output buffer.

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

Remove testing code from 23159365

Using the correct blend modes for each case or converting to
premultipled in the very unlikely case that separate blend modes are
unavailable on ancient opengl hardware.

It's proper new name is gst_gl_stereo_downmix_get_type().