Intel drivers expose some colorbalance's maximum values much more
bigger than their minimum values, given their middle values (default
value). This means, in practice, that the real middle point between
the maximum and minimum values implies a major change in the color
balance, which is not expected by the GStreamer color balance logic.
This patch makes the given maximum value symmetrical to the minimum
value, given the middle one (default value).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1580>
Needed an update to the windows Dockerfile to:
1. Install the 'UniversalBuildTools' workload for Cerbero
2. Install ARM and ARM64 workloads for cross-uwp-universal in Cerbero
3. Install VS 2019 since we need that for ARM64 NEON support in Opus
We can't test UWP in gstreamer.git because glib needs custom patches
for that. It will be tested in Cerbero.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1570>
It was getting pulled in automatically via cairo, but the version
there is too old for us. We need the latest to fix Windows ARM64 NEON
support:
> ERROR: No specified compiler can handle file subprojects\libpng-1.6.37\arm/filter_neon.S
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1570>
As now, we warn if the decoder have no support src pixel format, but that
warning is called before the type (hence the debug category) is initialized.
Fix this by moving the debug category init out of the type initialization,
into the register funcitons.
This will fix an assertion that occures in the register function and allow
relevant log to be seen by the users.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1588>
Those will cause us to renegotiate at the next aggregate cycle,
and while at that point we may decide to reconfigure upstream
branches (in practice we don't as this is inherently racy,
and that's the reason why mixer subclasses perform conversion
internally), we certainly don't want to just forward the event
willy-nilly to all our sinkpads.
An actual issue this is fixing is when caps downstream of a
compositor are changed at every samples-selected signal emission,
for the purpose of interpolating the output geometry, and the
compositor has a non-zero latency, the reconfigure events were
forwarded to basesrc, which triggered an allocation query, which
in turn caused aggregator to have to drain (thus not being able
to queue <latency> frames), leading to disastrous effects
(choppy output as compositor couldn't consume frames fast enough,
the higher the latency the choppier the output)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1464>
The merge request workflow can be confusing to people unfamiliar with
it, so add screenshots.
Also add a new section on how to revise merge requests, since a lot of
people tend to open new merge requests to make any changes.
Eliminate the separate "How to Prepare a Merge Request for Submission"
section -- merge it with the main section.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1367>
This is usually necessary to allow gst-indent to treat it as
a statement, but we do not run gst-indent on headers and we do not
have extra semicolons in other places that this macro is used in the
header. Fixes warnings when using the header:
```
In file included from gstreamer/subprojects/gst-plugins-base/gst-libs/gst/video/video.h:185,
from XYZ:9001:
gstreamer/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideoaggregator.h:206:78: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
206 | G_DEFINE_AUTOPTR_CLEANUP_FUNC(GstVideoAggregatorConvertPad, gst_object_unref);
| ^
gstreamer/subprojects/gst-plugins-base/gst-libs/gst/video/gstvideoaggregator.h:214:181: warning: ISO C does not allow extra ‘;’ outside of a function [-Wpedantic]
214 | G_DECLARE_DERIVABLE_TYPE (GstVideoAggregatorParallelConvertPad, gst_video_aggregator_parallel_convert_pad, GST, VIDEO_AGGREGATOR_PARALLEL_CONVERT_PAD, GstVideoAggregatorConvertPad);
| ^
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1572>
When fixating color, there might be "other caps" with color spaces not
supported by the caps features exposed in the vapostproc's source pad
caps template (perhaps it's a bug somewhere else in GStreamer).
This solution checks if the proposed format exists in the filter
within the caps feature associated with the proposed format.
The check is done with the new filter's function
gst_va_filter_has_video_format().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1559>
In the need-data appsrc callback, a buffer is pulled from the
appsink. This buffer is then copied so that metadata is writable.
The copy is pushed to the appsrc but it doesn't take ownership
of the buffer so we need to manually unref it. The original buffer
is finally unreffed when the sample is freed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1548>
This is due to an unsafe usage of the pad task. We didn't ensure proper
ownership of the task. That race involved the task being released too early,
and was detected, luckily, by the glib mutex implementationt that
reported the mutex being disposed while being locked.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1478>
On Android (especially) and for static builds in general it is safer to link
against libsoup and have the dynamic custom loading disabled. For those cases we
can safely assume the application will use either libsoup2 or libsoup3 and not
both.
Fixes#939
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1536>
