Handling mouse navigation events in glvideomixer element, if no
pixel-aspect-ratio info in the caps, an assertion error is produced
inside gst_util_fraction_multiply because default denominator is zero.
Error fixed:
```
(gst-launch-1.0:102654): GStreamer-CRITICAL **: 00:47:51.598: gst_util_fraction_multiply: assertion 'b_d != 0' failed
```
Simple pipeline to reproduce the issue:
```
gst-launch-1.0 -v glvideomixer name=mix ! glimagesinkelement gltestsrc ! mix.sink_0
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3766>
We create a new context in `gst_gl_context_create_thread()` and then
activate it on the current thread. Thereafter we assume that the
current thread continues to be the active thread for that context and
call `gst_gl_context_fill_info()` which asserts that the current
thread is the active thread.
However, if at the same time a different thread calls
`send_message_async()`, it will call into
`gst_gl_window_cocoa_send_message_async()` which will schedule the
message to be invoked using GCD. That anonymous function will also
call `gst_gl_context_activate()`, which creates a race, which can lead
to:
```
gst_gl_context_fill_info: assertion 'context->priv->active_thread == g_thread_self ()' failed
```
Fix it by using `gst_gl_context_thread_add()` to invoke `fill_info()`
on the context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3732>
The goal of the "global" group-id is to fix new inputs that do not come from the
same "source" as others. In order to ensure all "current" streams have the same
group-id we distribute the first valid group-id to all streams.
This commit fixes two issues with that:
* When inputs are unlinked they weren't always properly resetted (it would only
work if parsebin is used, which is no longer the default in
uridecodebin3/playbin3).
* When computing the global group-id, take into account unset
group-id (i.e. GST_GROUP_ID_INVALID).
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1698
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3712>
As the path to the gir file is passed to hotdoc.generate_doc() and
not the build target itself, meson doesn't know about the dependency.
In turn, as the CI doesn't build everything before building the
documentation target, some gir files might not exist, for instance
in the case of gst-rtsp-server, causing the output documentation to
be empty.
The error occurred silently because hotdoc accepts wildcards for
*-sources arguments, thus it won't warn about a missing gir file as
it is legitimate for glob matching to resolve to nothing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3686>
It might be possible to fulfill those but not with the first caps
structure. Instead of just fixating the first caps structure, check if
the preference can be fulfilled by any of the structures as the first
step.
Without this the following pipeline negotiates to mono after the
decoder because opusenc only has a single channel in its first caps
structure.
gst-launch-1.0 audiotestsrc ! audio/x-raw,channels=2 ! opusenc \
! queue ! opusdec ! queue ! opusenc ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3689>
This should fix pipelines such as this one to work as expected
... ! opusenc ! capsfilter caps='audio/x-opus,
channels=1; audio/x-opus, channels=2' ! ...
The expectation is that the encoder will propose the first structure
before the second one to the source.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3673>
The number of expected pads was:
* Defaulting to 1
* Or being overriden by GST_MESSAGE_STREAMS_SELECTED
This fails if upstream isn't a selectable source and has multiple streams, and
would therefore cause failures with multi-stream gapless playback
Fixes#1672
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3658>
It is quite possible to have the blocking probe called from different streaming
threads when all expected pads are present.
* Notify all waiters by using g_cond_broadcast instead of g_cond_signal
* Properly remove the probe after waiting
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3658>
Using the "GstBin" flags to check if an adaptive demuxer is streams-aware isn't
a good idea since it prevents using elements which aren't bins.
Instead we see if a collection was posted by the demuxer by the time a pad is
added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3601>
We want to make it so that we prefer a higher, not lower, number of
channels. Otherwise, this pipeline would convert from 2 to 1 channels:
gst-launch-1.0 audiotestsrc ! audio/x-raw,channels=2 ! opusenc ! queue ! opusdec ! queue ! opusenc ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3494>
Whenever the surface is resized before the stream is negotiated, we endup
with an assertion in libgstvideo.
gst_video_center_rect: assertion 'src->h != 0' failed
This fixes it, by following the style aready in place, which is to ensure
surfaces have a minimum size of 1x1.
Fixes#1139
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3467>
gst-launch-1.0 audiotestsrc ! udpsink host=127.0.0.1
gst-launch-1.0 udpsrc ! audioconvert ! autoaudiosink
would crash with a floating point exception when clipping the input
buffer owing to a division by zero because no caps event was received.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3469>
Make sure that group-id of a given play item are made consistent from the
start (sources) and all the way through the output.
This ensures that we can reliably detect that we have switched to the next play
item on the output of decodebin3 (and we can therefore properly free/release it)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3457>
When shutting down, we want to remove the urisourcebin blocking probes ... but
we also want to propagate a GST_FLOW_FLUSHING upstream (and not
GST_FLOW_NOT_LINKED) to make the upstream task gracefully stop instead of
posting an error message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3457>
When `is_selection_done` is called, it checks that all the requested streams are
present in the active stream list ...
... except there could very well be a (about to be removed) stream from the
previous selection present.
Therefore filter the list of streams we add to the message by the streams which
are actually requested.
Fixes issues when switching between different stream types (ex: video-only to
audio-only).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3457>
Currently, when rtspsrc property add-reference-timestamp-metadata=true,
a downstream rtph264depay element will attach multiple copies of the
same GstReferenceTimestampMeta to the depayloaded media buffers. This
can have signficant performance impacts further downstream in a pipeline
like the following:
rtspsrc add-reference-timestamp-metadata=true ! rtph264depay ! h264parse ! ... ! rtph264pay ! ...
For example, if there are 10 packet buffers for a frame of RTP H.264
video, each of those packet buffers will contain the same reference
timestamp meta. The rtph264depay element will then attach all 10
metadata to the depayloaded frame. And then later when we payload the
frame buffer again for proxying, we now have 10 more buffers each with
10 instance of the same metadata. Allocating/deallocating 100+ instances
of metadata @ 30fps for multiple streams has a pretty large performance
impact.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1578
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3431>
The tile width in pixel is not always available. Notably for
8L128 10bit format, the tile is 8x128 bytes, and the pixel
format is fully packed. That means that the tile contains at
least 6 pixels per line, but it also hold some bits of the
pixel from the same line on the previous or next tile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3424>
In current tile representation, only tiles with power of two
width and height in bytes are supported. This limitation
prevents adding more complex tiles formats.
In this patch, we deprecate tile_ws and tile_hs from GstVideoFormatInfo and
replace if with an array of GstVideoTileInfo. Each plane tiles are then
described with their pixels width/height, line stride and total size.
The helper gst_video_format_info_get_tile_sizes() that depends on the
deprecated API is also being removed. This can simply be removed as it wasn't
in any stable release yet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3424>
Setting force_live lets aggregator behave as if it had at least one of
its sinks connected to a live source, which should let us get rid of the
fake live test source hack that is probably present in dozens of
applications by now.
+ Expose API for subclasses to set and get force_live
+ Expose force-live properties in GstVideoAggregator and GstAudioAggregator
+ Adds a simple test
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3008>
This was the intention from the start, just took me a few years *cough* to
actually implement it properly.
Gapless is handled by re-using as much as possible the same decoders and sinks
if present, and only pre-rolling switching at the sources level (with buffering
if/when needed).
In order to enable "gapless" playback, the "next" uri should be set at any time
between the moment the `about-to-finish` signal is emitted and the moment the
current play item is done. Previously this could only be done with the signal
emission.
This new implementation also allows "Instantaneous URI switching". This allows a
much faster way of switching playback entries while re-using as many elements as
possible. To enable this set `instant-uri` property to TRUE, the default being
FALSE.
API: instant-uri properties
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784>
DecodebinInput (and their backing parsebin or identity) are no longer released
when the corresponding sinkpad is unlinked, but when it's released.
The parsebin element will be resetted:
* If incoming caps are incompatible (was the case before)
* Or when unlinking and it was previously pull-based
This opens the way to use decodebin3 with changing inputs (i.e. gapless)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784>
Introduce the option to have the streams be parsed with `parsebin` for
compatible sources (i.e. which are eligible for buffering in the same way as
before this commit).
By parsing the inputs directly, this allows more accurate buffering control:
* Instead of relying on potential bitrate information coming from somewhere
* and *without* being linked downstream
If `parse-streams` is activated and the stream is eligible for buffering, then a
`multiqueue` will be used on the output of `parsebin` in order to handle the
buffering.
API: `parse-streams`
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784>
If the incoming streams are already parsed, there is no need to add yet-another
parsebin to process it *IF* that stream is compatible with a decoder or the
decodebin3 output caps.
This only applies if all the following conditions are met:
* The incoming stream can *NOT* do pull-based scheduling
* The incoming stream provides a `GstStream` and `GstStreamCollection`
* The caps are compatible with either the decodebin3 output caps or a decoder
input
If all those conditions are met, a identity element is used instead of a
parsebin element and the same code paths are taken.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784>
* Instead of creating temporary `PendingPad` structures, always create a
DecodebinInputStream for every pad of parsebin
* Remove never used `pending_stream` field from DecodebinInputStream
* When unblocking a given DecodebinInput (i.e. wrapping a parsebin), also make
sure that other parsebins from the same GstStreamCollection are unblocked
since they come from the same source
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784>
Make an explicit topology/tree of structures:
* ChildSrcPadInfo is created for each source element source pad
* ChildSrcPadInfo contains the chain of optional elements specific to that
pad (ex: typefind)
* A ChildSrcPadInfo links to one or more OutputSlot, which contain what is
specific to the output (i.e. optional buffering and ghostpad)
* No longer use GObject {set|get}_data() functions to store those structures and
instead make them explicit
* Pass those structures around explicitely in each function/callback
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784>
The following problem could happen:
* Thread 1 : urisourcebin gets activated from READY->PAUSED
* Thread 2 : some element causes a pad to be added to urisourcebin , which gets
linked downstream, which decides to activate upstream to pull-based.
* That requires "activating" the pads from PUSH to NONE, and then from NONE to PULL
* Thread 1 : the base class state change handlers checks if all pads are
activated
The issue is that since going form PUSH to PULL requires going through NONE,
there is a window during which:
* Thread 1 : The pad was set to NONE (before being set to PULL)
* Thread 2 : The base class activates that pad (to PUSH)
* Thread 1 : The attempt to "activate" to PULL fails (silently or not)
This is very racy, so in order to avoid that, we make sure that we only add pads
once the transition from READY->PAUSED in the parent classes is done.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784>
When a tile format is padded and imported as DMABuf, the stride
contains the information about the actual width and height in
number of tiles. This information is needed by the detiling shader
in order accuratly calculate the location of pixels. To fix that,
we also copy the offset and strides into the otuput format and
the converter will ensure that the shader is recompiled whenever
the stride changes.
This fixes video corruptions observed when decoding on MT8195
with videos that aren't not aligned to 64bytes in width.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3365>
GST_TRACERS="leaks" GST_DEBUG="GST_TRACER:7,leaks:6" gst-play-1.0 --use-playbin3 test.mkv
When running a pipeline like above, leaks are observed.
0:00:56.882419132 240637 0x5562c528ccc0 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7efd7c0d20a0, description=(string)<'':sink_0>, ref-count=(uint)1, trace=(string);
0:00:56.882429131 240637 0x5562c528ccc0 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7efd7c0d2be0, description=(string)<'':sink_0>, ref-count=(uint)1, trace=(string);
0:00:56.882437056 240637 0x5562c528ccc0 TRACE GST_TRACER :0:: object-alive, type-name=(string)GstConcatPad, address=(gpointer)0x7efd7c0d3720, description=(string)<'':sink_0>, ref-count=(uint)1, trace=(string);
gst_element_release_request_pad does not unref the pad. It needs to
be followed by gst_object_unref. Doing that fixes the above leaks.
Use g_ptr_array_new_with_free_func with gst_object_unref as the free
function to unref the pad after release.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3177>
Posting latency messages causes a full and potentially expensive latency
recalculation of the pipeline. While subclasses should check whether the latency
really changed or not before calling this function, we ensure that we do not
post such messages if it didn't change.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3282>
duplicate symbol '__invoke_on_main' in:
/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgstvulkan-1.0.a(cocoa_gstvkwindow_cocoa.m.o)
/Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgstgl-1.0.a(cocoa_gstglwindow_cocoa.m.o)
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Also make the same change in iOS for consistency.
Continuation of https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/1132
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3242>
When trying to build the plugin, GCC starts complaining about issues
with one of the cdparanoia headers and it block us from being able
to build the plugin with Werror.
The current warning in the header look like this:
```
[1/2] Compiling C object subprojects/gst-plugins-base/ext/cdparanoia/libgstcdparanoia.so.p/gstcdparanoiasrc.c.o
In file included from ../subprojects/gst-plugins-base/ext/cdparanoia/gstcdparanoiasrc.h:37,
from ../subprojects/gst-plugins-base/ext/cdparanoia/gstcdparanoiasrc.c:31:
/usr/include/cdda/cdda_interface.h:164:3: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
164 | "Success",
| ^~~~~~~~~
...
/usr/include/cdda/cdda_interface.h:163:14: warning: ‘strerror_tr’ defined but not used [-Wunused-variable]
163 | static char *strerror_tr[]={
| ^~~~~~~~~~~
[2/2] Linking target subprojects/gst-plugins-base/ext/cdparanoia/libgstcdparanoia.so
```
Last release of cdparanoia was in 2008, so our best bet for the
time is to ignore the warnings.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2722>
This allows correct handling of wrapping around backwards during the
first wraparound period and avoids the infamous "Cannot unwrap, any
wrapping took place yet" error message.
It allows makes sure that for actual timestamp jumps a valid value is
returned instead of 0, which then allows the caller to handle it
properly. Not having this can have the caller see the same timestamp (0)
for a very long time, which for example can cause rtpjitterbuffer to
output the same timestamp for a very long time.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1500
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3202>
The scenario is what we try in the tests:
- we have a segment with .stop set
- some frame(s) flow
- we get a CAPS event
- we get an EOS (before getting buffers after the CAPS event)
in that case, without that patch, the segment is not properly closed
which is not correct. In this patch we keep track of previous caps until
a new buffer arrives, this way in that situation we set previous caps
again, and close the segment with the previous buffer.
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1352
in this specific case
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3059>
The implementation was inconsistent between create and destroy. EGLImage
creation and destruction is requires for EGL 1.5 and up, while
otherwise the KHR version is only available if EGL_KHR_image_base
feature is set. Not doing these check may lead to getting a function
pointer to a stub, which is notably the case when using apitrace.
Fixes#1389
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2925>
Always hold a reference to the soft volume element
provided by the playsinkaudioconvert bin helper, the
same as when volume is provided by a sink element,
or the soft volume element gets unreffed too soon.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3108>
We need to call this to register the MusixBrainz tags before we use
them in an XMP schema.
Fixes this critical when attempting to run jpegparse on a JPEG
containing MusicBrainz XMP tags:
GStreamer-CRITICAL **: 20:41:07.885: gst_tag_get_type: assertion 'info != NULL' failed
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3092>
The purpose of a deep buffer copy is to be able to release the source
buffer and all its dependencies. Attaching the parent buffer meta to
the newly created deep copy needlessly keeps holding a reference to the
parent buffer.
The issue this solves is the fact you need to allocate more
buffers, as you have free buffers being held for no reason. In the good
cases it will use more memory, in the bad case it will stall your
pipeline (since codecs often need a minimum number of buffers to
actually work).
Fixes#283
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2928>
