GitLab

And add missing #ifdef _WIN32 for MSVC build

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

In case the wasapi buffer levels got low in shared mode we would still wait until
more buffer is available until writing something in it, which means we could never
catch up and recover.

Instead only wait for a new buffer in case the existing one is full and always write
what we can. Also don't loop until all data is written since the base class can handle
that for us and under normal circumstances this doesn't happen anyway.

This only works in shared mode, as in exclusive mode we have to exactly
fill the buffer and always have to wait first.

This fixes noisy (buffer underrun) playback with the wasapisink under load.

https://bugzilla.gnome.org/show_bug.cgi?id=796354Signed-off-by: Nirbheek Chauhan <nirbheek@centricular.com>

Apply the commit ef71b617
See also https://bugzilla.gnome.org/show_bug.cgi?id=742212

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

Apply commits 0c04e004, bf0d9523 and a0876aa7 to h265parse.
See also https://bugzilla.gnome.org/show_bug.cgi?id=766803

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

Apply the commit 48a1f279

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

Apply the commit 69c09c38

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

Apply the commit 9b50a12b

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

Apply the commit 14f6fcdb

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

Apply the commit 7d44a51b
See also https://bugzilla.gnome.org/show_bug.cgi?id=732203

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

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

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

Direct applying the commit 7bb6443b. This could fix also unexpected
nal dropping when nonzero "config-interval" is set.
(e.g., gst-launch-1.0 videotestsrc ! x265enc key-int-max=30 !
 h265parse config-interval=30 ! avdec_h265 ! videoconvert ! autovideosink)

Similar to the h264parse, have_{vps,sps,pps} variables will be used
for deciding on when to submit updated caps or not, and rather mean
"have new SPS/PPS to be submitted?"
See also https://bugzilla.gnome.org/show_bug.cgi?id=732203

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

Adopt h264parse's _collect_nal() behavior.
See also commit 5601c875 and  https://bugzilla.gnome.org/show_bug.cgi?id=732154

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

Apply the commit 36a2acae

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

Apply the commit 10ffa089

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

Don't scan the entire APPDATA and COMMONPROGRAMFILES
path tree, just the LADSPA sub-directory inside them, if any.

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

When scanning paths for LADSPA plugins, don't try and load
every random file as a module, as g_module_open ends up throwing
errors on Windows.

Use a G_MODULE_SUFFIX and GST_EXTRA_MODULE_SUFFIX suffix check as
we do for GStreamer plugins.

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

This is now handled directly in gstaudiosrc/sink, and we were setting
it in the wrong thread anyway. prepare() is not the same thread as
sink_write() or src_read().

With the Windows 8.1 SDK, the v1 of the AUDCLNT_STREAMOPTIONS enum is
defined which only has NONE and RAW, so it's not only defined when
AudioClient3 is available.

Add a meson check for the symbol. This is not needed for Autotools
because there we build against the MinGW audioclient.h which is still
at v1 of the AudioClient interface.

Since both audio and video capture devices declare the KSCATEGORY_CAPTURE interface,
plugging a camera that supports both could result in an audio device being mistaken
for a video one.

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

cl : Command line error D8021 : invalid numeric argument '/Wno-missing-include-dirs'

When the position query fails the returned value shall remain -1 instead of 0 to
avoid confusion on application side between error and beginning of media.

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

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

If we drain after a discont, the discont time given by the stream
synchronizer is already the time after the discontinuity. But we need to
drain all pending data based on the previous discont time instead.

They might otherwise just change while we iterate.

Worst case it will be empty. This fixes a crash when the base class
calls data_received() when the stream is neither is_isobmff or
has_isoff_ondemand_profile.

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

Explicitly cast to void* because GCC 8 is (rightfully) upset that this is
"writing to an object of type ‘...’ with no trivial copy-assignment".

Caused by the new "class-memaccess" warning

This is a new warning introduced by gcc 8

We already check just before that we have enough space, just do a regular
memcpy with the full string size.

camswclient.c:87:3: error: ‘strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]

The `CV_RGB` macro is now in `imgproc.hpp`.

Fixes:

    ../subprojects/gst-plugins-bad/ext/opencv/gsthanddetect.cpp:497:40: error: ‘CV_RGB’ was not declared in this scope
            cvCircle (img, center, radius, CV_RGB (0, 0, 200), 1, 8, 0);
                                        ^~~~~~

Some SVG files created by inkscape use that, such as:
https://gitlab.gnome.org/GNOME/pitivi/uploads/8dd8d9d988b5eb6cc38f871196caac6f/Titel-Tafel3.2_anim.svg

This is a first patch for https://bugzilla.gnome.org/show_bug.cgi?id=796909
but it is not enough to support animated gifs.

`#ifdef` will, of course, evaluate to 1 in this case. We want `#if`.

In commit fd806628a8 (839cc392 in the stable branch) I changed the
segment size to match exactly the buffer size.  I missed that this is
only valid in exclusive mode and in shared mode the buffer size is
a multiple of the device period.

Revert the logic for the shared mode.

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

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

255 will easily become 0 in the blending function as they expect
the maximum value to be 255.

Can be reproduce with

gst-launch-1.0 videotestsrc pattern=ball ! c.sink_0 \
               videotestsrc pattern=snow ! c.sink_1 \
               compositor name=c \
                 sink_0::zorder=0 sink_1::zorder=1 sink_0::crossfade-ratio=0.5 \
                 background=black ! \
               videoconvert ! xvimagesink

crossfade-ratio +/- 0.001 makes it work correctly and the same happens
at e.g. 0.25, 0.75, N*0.0625

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

The mxsfb-drm driver has been added to the kernel long ago and will now
be the default display driver for NXP i.MX28, i.MX6SX and i.MX7D
processors so now is a good time to add it to kmssink.

Also, this is used in the upcoming i.MX8MQ and i.MX8MM processors.

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

This adds entry for new DRM driver from xilinx
called "xlnx" which supports atomic modesetting.

We have kept entry for older DRM driver "xilinx_drm"
for backward compatility with a note describing
deprecation.
Signed-off-by: Devarsh Thakkar <devarsht@xilinx.com>

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