Detected while reading the code, cccombiner must set
self->current_video_buffer to NULL *after* emitting selected-samples
in order for the application to get a useful return when peeking
the next video sample.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1252>
When schedule is true (as is the case by default), we insert padding
when no caption data is present in the schedule queue, and previously
weren't checking whether the caption pad had gone EOS, leading to
infinite scheduling of padding after EOS on the caption pad.
Rectify that by adding a "drain" parameter to dequeue_caption()
In addition, update the captions_and_eos test to push valid cc_data
in: without this cccombiner was attaching padding buffers it had
generated itself, and with that patch would now stop attaching
said padding to the second buffer. By pushing valid, non-padding
cc_data we ensure a caption buffer is indeed attached to the first
and second video buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1252>
Also refactor various internals of the monitor code:
- Don't allow starting twice but just return directly when starting a
second time.
- Don't end up in an inconsistent state if call start() a second time
while the monitor is starting up.
- Remove complicated cookie code: it was not possible to add/remove
filters while the monitor was started anyway so this was only useful
in the very small time-window while starting the monitor or while
getting the devices. Instead disallow adding/removing filters while
the monitor is starting, and when getting devices work on a snapshot
of providers/filters.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/667
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1189>
At gst_va_dmabuf_allocator_setup_buffer_full, static code analysis tool
does not know number of objects in descriptor is always larger than 0 if
export_surface_to_dmabuf succeeds. Thus, the tool will assume buf is
allocated with mem but not released when desc.num_objects equals to 0
and raise a mem leak issue.
For gst_va_dambuf_memories_setup, we should also inform the tool that
n_planes will be larger than 0 by checking the value at very beginning.
Then, the defect similar to above will not be raised during static analysis.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1241>
gst_base_parse_reset() does not reset data_bytecount to 0, so
gst_base_parse_update_bitrates() uses a wrong value to calculate
the average bitrate on subsequent pipeline starts. This leads to an
excessive amount of "tag" events being pushed. These events include
very high "bitrate" values that diminish over time, and are produced
until the average bitrate is back to sane values.
Fixes#840
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1228>
This will only affect individual/tarball module builds, as the
options yield to the parent project which was set to gpl=disabled
by default already. We kept it as auto in the original commit
to accommodate the need to update cerbero as well, which had to
be done separately after the initial commit.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1217>
Previously gst_structure_has_name was used to get a string to compare with supported mimetypes.
This is incorrect as above function returns a user defined structure name which is
not the structure mimetype value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1206>
Trying to reset before the pads have been deactivated races with the
streaming thread. There was also a buggy buffer clear leaving a dangling
`stored_frame` pointer around. Use `gst_interlace_reset` so this happens
properly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1039>
We don't support D3D11 interop for UWP because some APIs
(specifically MFTEnum2) are desktop application only.
However, the code for symbol loading is commonly used by both UWP and WIN32.
Just link GModule unconditionally which is UWP compatible, and simply don't
try to load any library/symbol dynamically when D3D11 interop is unavailable.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1216>
... in favour of dep.get_variable('foo', ..) which in some
cases allows for further cleanups in future since we can
extract variables from pkg-config dependencies as well as
internal dependencies using this mechanism.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1183>
When ass hinting value is set to anything other than NONE,
subtitles cannot use smooth scaling, thus all animations will jitter.
The libass author warns about possibility of breaking some scripts when it is enabled,
so lets do what is recommended and disable it to get the smooth scaling working.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1201>
WebVTT in ISO MP4 is specified in ISO 14496-30,
and needed for DASH support. It's stored in an
mp4 specific format. To handle it compatibly,
the wvtt boxes are converted back into WebVTT text
and pushed as application/x-subtitle-vtt
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1182>
Swap the `need_process` boolean check on qtdemux streams
for a direct function pointer to the splitting function,
so we can stop adding extra cases to the single growing
`gst_qtdemux_process_buffer()` function.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1182>
Currently the extension data length specified in the RTP header would
say it was shorter then the data serialised to a packet. When
combining the resulting buffer, the underlying memory would still
contain the extra (now 0-filled) padding data.
This would mean that parsing the resulting RTP packet would potentially
start with a number of 0-filled bytes which many RTP formats are not
expecting.
Such usage is found by e.g. RTP header extension when allocating the
maximum buffer (which may be larger than the written size) and shrinking
to the required size the data once all the rtp header extension data has
been written.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1146>
The code in the aes elements assumes OpenSSL >= 1.1.0:
- implicit library initialization;
- version retrieved with OpenSSL_version(OPENSSL_VERSION);
and it fails to build with older versions.
Specify the required OpenSSL version explicitly in meson.build so that
the elements are excluded on older systems (e.g. Ubuntu 16.04) and the
rest of GStreamer can still build.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1067>
An inactive pad is a pad which, in live mode, hasn't yet received
a first buffer, but has been waited on at least once.
Exposing API to support this behaviour allows users of aggregator
subclasses to request pads, and not start pushing data on those
immediately, while avoiding systematic timeouts.
Subclasses must check in explicitly to this behavior, most likely
by exposing a user-facing property, and must check whether a pad
needs ignoring when aggregating. That is because by design,
aggregator subclasses don't get a list of "ready" pads, but instead
directly iterate element->sinkpads.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/867>
Since commit a55dafe341, stream-scoped tags no
longer appeared as top-level tags, introducing a behaviour regression, specially
for MP3 files.
The `gst_discoverer_info_get_tags()` API now returns all tags detected for the
given media, as documented.
A new API is introduced to get container-specific tags,
`gst_discoverer_container_info_get_tags()`. The discoverer tool was adapted to
use it. `gst_discoverer_info_get_tags()` is now deprecated in favor of
`gst_discoverer_container_info_get_tags()` and
`gst_discoverer_stream_info_get_tags()`.
Fixes#759
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1107>
gst_va_vpp_complete_caps_features() now receives the @feature_name to
add and return if @caps doesn't provide it.
So, instead of two nested loops, now the function is a single loop,
traversing @caps to find if each structure already contains the requested
@features_name.
It's important to add missing caps features with @caps, in order to
not lost information.
The function caller does the external loop by calling per each
available caps feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1024>
In order to make more readable the caps transformation, the operation
was split in two phases:
1. Rangify the supported caps structures.
2. Add the missing (and supported) caps features.
Step 1 modified its logic, by copying any unrecognized structure.
It's a previous step required for allowing ANY caps feature as
passthrough.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1024>
For monorepo build and ugly/bad, for advanced feature
option API like get_option('xyz').required(..) which
we use in combination with the 'gpl' option.
For rest of modules for consistency (people will likely
use newer features based on the top-level requirement).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1084>
There are streams in the wild that have to add a SCTE-35 trigger in
another e.g. GA94 stream. Most encoders would replace the GA94
descriptor ID with the CUEI one temporarily, but there are some that
will add two registration ID descriptors, one with GA94 and one with
CUEI.
Failing to parse the CUEI registration ID in that case would return
FALSE in _stream_is_private_section , therefore setting it as known PES
and pushing packets downstream instead of calling handle_psi.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/979>
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>
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>
