gstcheck is declaring its own buffers glist which ends up
overwritten, loks like the code meant to use that already
gcc 10 is also complaining about this, but only on static
builds for some reason
```
FAILED: subprojects/gst-plugins-ugly/tests/check/elements_amrnbenc
/usr/bin/ld: subprojects/gstreamer/libs/gst/check/libgstcheck-1.0.a(gstcheck.c.o):(.bss+0x38): multiple definition of `buffers'; subprojects/gst-plugins-ugly/tests/check/708af1f@@elements_amrnbenc@exe/elements_amrnbenc.c.o:(.bss+0x18): first defined here
collect2: error: ld returned 1 exit status
```
also remove unused var `current_buf`
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/merge_requests/62>
If downstream is constrained to an 8-bit profile, caps queries would
still allow I420_10LE as input. If upstream actually sends such a caps
event, downstream would fail to accept the high-10 profile.
The following pipeline now fails earlier, during the negotiation phase
instead of the stream start:
gst-launch-1.0 videotestsrc ! video/x-raw,format=I420_10LE \
! x264enc ! video/x-h264,profile=constrained-baseline \
! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/merge_requests/59>
If core is built as a subproject (e.g. as in gst-build), make sure to use
the gst-plugin-scanner from the built subproject. Without this, gstreamer
might accidentally use the gst-plugin-scanner from the install prefix if
that exists, which in turn might drag in gst library versions we didn't
mean to drag in. Those gst library versions might then be older than
what our current build needs, and might cause our newly-built plugins
to get blacklisted in the test registry because they rely on a symbol
that the wrongly-pulled in gst lib doesn't have.
This should fix running of unit tests in gst-build when invoking
meson test or ninja test from outside the devenv for the case where
there is an older or different-version gst-plugin-scanner installed
in the install prefix.
In case no gst-plugin-scanner is installed in the install prefix, this
will fix "GStreamer-WARNING: External plugin loader failed. This most
likely means that the plugin loader helper binary was not found or
could not be run. You might need to set the GST_PLUGIN_SCANNER
environment variable if your setup is unusual." warnings when running
the unit tests.
In the case where we find GStreamer core via pkg-config we use
a newly-added pkg-config var "pluginscannerdir" to get the right
directory. This has the benefit of working transparently for both
installed and uninstalled pkg-config files/setups.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/merge_requests/53>
This is needed for cross-compiling without a build machine compiler
available. The option was added in 0.54, but we only need this in
Cerbero and it doesn't affect older versions so it should be ok.
Will just cause a spurious warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly/-/merge_requests/50>
When transitioning from the PAUSED state, to the READY state, and back,
metadata and global_metadata are left uninitialized, unlike when the
demxuer transitions from NULL to READY, then to PAUSED. I have found
this to cause a segmentation fault when fields in these structures are
set.
The --ref option indicate the size of the DPB, hence should be in the range of
0 to 16. This patch also fix the default to match x264enc default 3. This
change isn't a behaviour change since we don't enforce the reported default.
... with removal of pointless unistd.h dependency.
Note that full dependency listing is required to run unit test
executable binary on Windows uninstalled environment.
This means we can use some newer features and get rid of some
boilerplate code using the G_DECLARE_* macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
