Since 547570cd79 we do not always build
PyGObject and our development environment is broken when trying to use
GStreamer python when built against system PyGObject with the following
error importing Gst in there:
```
12345678** (gst-plugin-scanner:710617): CRITICAL **: 11:45:02.343: can't find gi.repository.Gst
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/gi/repository/__init__.py", line 23, in <module>
from ..importer import DynamicImporter
File "/usr/lib64/python3.9/site-packages/gi/importer.py", line 33, in <module>
from .overrides import load_overrides
ImportError: cannot import name 'load_overrides' from 'gi.overrides' (/var/home/thiblahute/devel/gstreamer/gstreamer/subprojects/gst-editing-services/bindings/python/gi/overrides/__init__.py)
Factory Details:
```
The approach to fixing it is to implement override `gi` in
`gst-python/gi/` which we add to `PYTHONPATH`) and in there reset the
`gi` module to the right place and we get overrides from paths from
`_GI_OVERRIDES_PATH` we set in `gst-env.py` which points to all the
overrides that will be installed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1155>
If pygobject is available on the system, its version is new enough,
don't build the older pygobject and rely on that system one.
This fixes totem not being able to use libpeas' Python support.
** (totem:544972): WARNING **: 12:04:05.407: Error initializing Python Plugin Loader: PyGObject initialization failed
ImportError: could not import gobject (version mismatch, 3.40.1 is required, found 3.38.1)
Closes: #806
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1135>
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>
These get added to *all* subprojects, including ones we do not
maintain such as ffmpeg which then emits thousands of warnings that
completely overwhelm the compile output.
We will add these in each gstreamer subproject separately.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/223>
In a fully static link where an app link with gstreamer-full
the gst_init_static_plugins can be discarded because
no one references it.
Indeed the symbol is looked up by gst_init to call if it exists
and so it is not clearly referenced.
In order to avoid this issue, we use the linker flag
--undefined=gst_init_static_plugins to keep
the symbol.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/207>
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>
That header is not needed any more because gst_init() now calls
gst_init_static_plugins() automatically when available.
This is an API break compared to 1.18, but release notes made it clear
it was an experimental feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/191>
If a static build is requested and x264 plugin has been enabled
the full link fails with:
/usr/bin/ld: subprojects/x264/libx264.a(cabac-a.o): relocation
R_X86_64_PC32 against symbol `x264_cabac_range_lps' can not be used when
making a shared object; recompile with -fPIC
Fixes#108
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/169>
Latest libnice requires 0.52, so it probably makes sense to
update the meson requirement in gst-build for that, so we
have good out-of-the-box developer experience for people,
with webrtc working out of the box.
Might also make it easier to backport things later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-build/-/merge_requests/164>
