In the encoded streams we might not have all the information about the
raw video stream, but when reencoding they end up being specified, even
if those are default values.
As vp8 decoders always output frames in some YUV color space we can
ensure that when upstream doesn't specify any value in its caps we
use the default one which is what we end up doing when decoding/reencoding
anyway, so this way downstream (matroskamux in that case) doesn't need
to be able to renegotiate (which it doesn't).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1062>
We should also take into account whether data is currently pending when checking
for gap on streams. It could very well be that some streams have very low
bitrate (and spread out) data. For those we don't want to push out a gap event.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1179>
This is only enabled in push time mode. Furthermore it's only enabled for now if
PCR is to be ignored.
The problem is dealing with streams where the initial PTS/DTS observation might
be greater than following ones (from other PID for example). Before this patch,
this would result in sending buffers without any timestamp which would cause a
wide variety of issues.
Instead, pad segment and buffer timestamps with an extra
value (packetizer->extra_shift, default to 2s), to ensure that we can get valid
timestamps on outgoing buffers (even if that means they are before the segment
start).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1179>
Due to a bug, meson ignores ${lang}_std settings in default_options
for subprojects: https://github.com/mesonbuild/meson/issues/1889
This causes build failures when a subproject requires c++11 or c++14,
etc. Compilers that support those cpp_stds are very common, and all
the toolchains that we support include c++ compilers, so we can
add cpp_std=c++14 to the top-level.
This fixes the webrtc-audio-processing build on Linux, and harfbuzz on
macOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1133>
Introduces a `libraries` variable that contains all libraries in a
list with the following format:
``` meson
libraries = [
[pkg_name, {
'lib': library_object
'gir': [ {full gir definition in a dict } ]
],
....
]
```
It therefore refactors the way we build the gir so that we can reuse the
same information to build them against 'gstreamer-full' in gst-build
when linking statically
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1093>
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>
Making a null check in gst_va_decode_picture_free () indicates pic->buffers or pic->slices
can be null, then in _destroy_buffers () the pointers are dereferenced, which is detected
as dereference after null check by Coverity. Thus, modify the code to do null check in
_detroy_buffers ().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1143>
