There are a bunch of plugins that you need for webrtc support, and
it's not obvious at all to users which those are.
With this commit, srtp, sctp and dtls options will be auto-enabled if
the webrtc option is enabled.
Requires meson 1.1
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5505>
To offer the possibility to get information at plugin
level and get it from the registry, all the
full features are now registered in 'fullstaticfeatures'
meta plugin instead of NULL plugin.
In the case of gst-inspect, the features were not displayed
at plugin level because it was a NULL plugin.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5421>
Some options got enabled by default since that commit:
40371ff9c6
While the commit message example makes perfect sense to enable `bad` by
default, I don't think the same reasoning applies to libav, devtools,
ges and rtsp_server.
I think it is important to keep a build with `-Dauto_features=disabled`
minimal, especially not pulling external dependencies. For example, with
libav being enabled by default, Meson builds FFmpeg subproject even
when disabling auto features.
It is fine to keep `bad` enabled by default because itself has auto
features for every plugins, when auto features are disabled it only
build libraries that does not have external deps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5337>
Allow a project to use gstreamer-full as a static library
and link to create a binary without dependencies.
Introduce the option 'gst-full-target-type' to
select the build type, dynamic(default) or static.
In gstreamer-full/static build configuration gstreamer (gst.c)
needs the symbol gst_init_static_plugins which is defined
in gstreamer-full.
All the tests and examples are linking with gstreamer but the
symbol gst_init_static_plugins is only defined in the gstreamer-full
library. gstreamer-full can not be built first as it needs to know what plugins
will be built.
One option would be to build all the examples and tests after
gstreamer-full as the tools.
Disable tools build in subprojects too as it will be built at the end of
build process.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4128>
Enable core gstreamer subprojects bad, ugly, libav, ges, devtools by
default. Otherwise if, say, you do, -Dgst-plugins-bad:dtls=enabled and
openssl is not found, meson will disable the entire subproject. You
have to pass -Dbad=enabled -Dgst-plugins-bad:dtls=enabled to get the
expected behaviour.
Also move options that are not for selection subprojects out of the
section, add a qt6 option, and improve the description for some
options.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3708>
These options allow to select a set of features from a given
plugin with the following syntax:
-Dgst-full-plugins=plugin1;plugin10
-Dgst-full-elements=plugin2:element1,element2
-Dgst-full-typefind-functions=plugins3:func
-Dgst-full-device-providers=plugin4,dp1
-Dgst-full-dynamic-types=plugin5:dt1
By default all the enabled plugin are registered and
gst-full-plugins will allow to include only a set of plugin
If a feature(element, typefind etc.) is selected from a plugin,
the plugin is removed from the plugins list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/199>
Can be used to control the exact symbols exported, or not, in
libgstreamer-full.
This is useful when building a tailored libgstreamer-full aimed
to be run with some specific binaries. By using such version script
one can reduce the size of the generated lib by letting the linker
garbage collect all the unused APIs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/195>
When building with -Ddefault_library=static, also build a single library
containing all built plugins. Any external dependencies are still
dynamically linked.
A monolithic library is easier to distribute, and in some envs like
Android is required.
Having vaapi decoders/encoders accidentally available by default often
causes strange test failures or weird behaviour since the plugins are
sometimes buggy or have different behaviour.
The only requirement for the rust plugins is that a rust toolchain be
present on the system. This is problematic:
1. This means gst-build on Windows is broken by default if you have
a Rust toolchain, since glib can't be used uninstalled
2. No output is printed on Windows at all while the rust plugins are
being built. `custom_target()`'s `console:` keyword argument seems
to be broken on some Windows shells.
3. Even on Linux/macOS having this enabled by default is problematic
since it more than doubles the total build time.
4. The biggest issue with having it enabled by default is that it does
not dependency tracking, so we always run `cargo`, which might
update crates. This increases friction when you're working on
unrelated code.
When relying on a system-wide libnice, we end up not building
the nice elements, which means we can't use them, and by extension
webrtcbin, in the uninstalled environment.
This also introduces a way to avoid checking the version of
a given subproject, and makes use of it for libnice and pygobject,
which only passed the version check by chance, as its current
major version is 3.
Can be re-enabled again if we check for all direct and
indirect hard deps before including it.
subprojects\gtk-sharp\Source\meson.build:40:0: ERROR: Program(s) ['gacutil'] not found or not executable
