This patch adds documentation to the 'log' tracer and amends the design
document of Tracers to replace a misleading example of the 'log' tracer
with a different example that uses tracer arguments with tracers that do
actually handle said arguments.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4153>
This fixes simplification of caps with GstFractionRange structures,
for example, this caps:
video/x-raw, framerate=(fraction)5/1; video/x-raw, framerate=(fraction)[ 5/1, 30/1 ]
can now be simplified to:
video/x-raw, framerate=(fraction)[ 5/1, 30/1 ]
instead of:
video/x-raw, framerate=(fraction){ 5/1, [ 5/1, 30/1 ] }
And this:
video/x-raw, framerate=(fraction)[ 2/1, 5/1 ]; video/x-raw, framerate=(fraction)[ 5/1, 30/1 ]
can be simplified to:
video/x-raw, framerate=(fraction)[ 2/1, 30/1 ]
instead of
video/x-raw, framerate=(fraction){ [ 2/1, 5/1 ], [ 5/1, 30/1 ] }
This fixes overly-complicated GL caps set by avfvideosrc on macOS and
iOS when capturing from a webcam.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4132>
When we run Cheese 41.1 on our imx platform, Cheese preview freeze
at first frame.
During pipeline state changing from NULL to PLAYING, if there are
both elements that state change asynchronously and state change
with no preroll in the bin, the element inside may send ASYNC_DONE
message to it, while the bin's pending state is VOID_PENDING.
In this case, the bin will not post ASYNC_DONE message to parent
bin, which makes parent bin thinks that there are still elements
in it that haven't completed state changing, causing the pipeline
freeze in an intermediate state.
This commit modifies the bin_handle_async_done() function. When the
bin, whose pending state is VOIDING_PENDING, receives the ASYNC_DONE
message, it will also post this message to its parent bin.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3490>
A flush is resetting or not depending on the reset_time argument in the
FLUSH_STOP event is set.
Resetting flushes reset the running time to zero and clear any existing
segment. These are the kind of flushes used by flushing seeks, and by far the
most common. Non-resetting flushes are much more niche, used for instance for
quality changes in adaptivedemux2 and MediaSource Extensions in WebKit.
A key difference between the seek use case and the quality change use case is
that the latter is much more removed from the player. Seeks generally occur
because an user request it, whereas quality changes can be automatic.
Currently, there are three notable cases where position queries fail:
(a) before pre-roll, as there is no segment yet. This is one is understandable,
as for at least some time before pre-roll, we cannot know if a media stream
would start at 0 or any other position, or the duration of the stream for that
matter.
(b) after a resetting flush caused by a seek. This kind of flush resets the
segment, so it's not surprising position queries fail. This is inconvenient for
applications, as it means they always need to handle position reporting (e.g.
in UI) separately every time they request a seek, e.g. by caching the seek
target and using it when the position query fail. I'm not fond of this
behavior, as it's unintuitive and makes GStreamer harder to use, but at this
point could be difficult to change and it's not within the scope of this
proposal.
(c) after a non-resetting flush, e.g. caused by a quality change. The segment
is not reset in this case. Position queries work until a FLUSH_STOP is sent.
Querying position after a FLUSH_START but before a FLUSH_STOP works, and
returns the position the sink was at the moment the FLUSH_START was received.
**This in fact the only reliable way (short of adding probes to the sink
element) to get this position**, as FLUSH_START receival is asynchronous with
playback.
In the case (c), as of currently, position queries fail once the FLUSH_STOP is
received. But unlike in (b), the application has no position to fall back to,
as the FLUSH_START was initiated by elements inside the pipeline that are in a
lower layer of abstraction. Specific applications that have control of both the
player and the internal element doing the flushing -- such as WebKit -- can
still work around this problem through layer violations (lucky!), but this
still puts in question this behavior in GStreamer.
This patch fixes this case by amending the position query handler of basesink,
which was previously erroneously returning early with "wrong state", even
though the flush occurs in PAUSED or PLAYING.
A unit test checking this behavior has also been added.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3471>
The previous implementation was a bit primitive, assuming the subclass
had registered a template name starting with sink_ . Instead make
the effort of parsing the actual template name, and use that to generate
the final pad name.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4032>
Fixes the following valgrind error:
==616== Conditional jump or move depends on uninitialised value(s)
==616== at 0x4900E34: gst_debug_print_object (gstinfo.c:1143)
==616== by 0x49010B6: gst_info_printf_pointer_extension_func (gstinfo.c:1215)
==616== by 0x4959FDB: __gst_printf_pointer_extension_serialize (printf-extension.c:47)
==616== by 0x495A487: printf_postprocess_args (vasnprintf.c:258)
==616== by 0x495A52C: __gst_vasnprintf (vasnprintf.c:290)
==616== by 0x4959F8F: __gst_vasprintf (printf.c:154)
==616== by 0x4901C1F: gst_debug_message_get (gstinfo.c:791)
==616== by 0x4901C75: _gst_debug_log_preamble (gstinfo.c:1431)
==616== by 0x4903208: gst_debug_log_default (gstinfo.c:1575)
==616== by 0x49020BA: gst_debug_log_full_valist (gstinfo.c:624)
==616== by 0x490211D: gst_debug_log_valist (gstinfo.c:656)
==616== by 0x49021AD: gst_debug_log (gstinfo.c:533)
==616== by 0x48DDC11: gst_buffer_copy_into (gstbuffer.c:693)
==616== by 0x48DF5F1: gst_buffer_copy_with_flags (gstbuffer.c:727)
==616== by 0x48DF640: gst_buffer_copy_deep (gstbuffer.c:756)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4034>
When the task already exists, we forgot to free the passed `user_data`.
This wasn't an issue for most C code, which doesn't pass a
`GDestroyNotify`, but bindings such as gstreamer-rs do!
That said, allocating a trampoline in gstreamer-rs just for it to get
thrown away again is awkward. Maybe we need a `gst_pad_resume_task`?
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3920>
Since b76d336549
pads are deactivated when going to READY but in `uridecodebin(3)`, the
sources source pads are activated while in NULL state (when PULL mode is
supported), meaning that we are ending up deactivating those pads in
NULL_TO_READY, breaking the pipeline.
The intent of the commit mentioned above is to ensure that the pads are
deactivated either in PAUSED_TO_READY or READY_TO_READY, so it should
be safe to avoid deactivating in NULL_TO_READY.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3849>
Usually gst-plugin-scanner.exe will be located under libexec/gstreamer-1.0
or even somewhere user specified location via GST_PLUGIN_SCANNER
environment. So, in order for child process to be able to load
GStreamer DLLs, parent process will need to update PATH env
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3886>
We already have functions to generate a stream-id from pads but in the
end those pads are not even used in most cases. This adds functions to
generate a stream-id even before creating the source pads for the
element that is going to use it. For example a demuxer that is properly
implements the GstStream/GstStreamCollection API will not have a Pad but
already needs to generate a stream-id.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3160>
It's not possible to annotate a in-parameter for a return value array as
the array length. Both are assumed to have the same direction and the
current annotation causes the size parameter to be considered an out
parameter.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3787>
Due to the dynamic nature of multiqueue, when `use-interleave` is used we can't
report a maximum tolerated latency (when queried) since it is calculated
dynamically.
When in such live pipelines, we need to make sure multiqueue can handle the
lowest global latency (provided by this event). Failure to do that would
result in not providing enough buffering for a realtime pipeline.
Fixes#1732
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3772>
Pads are activated automatically when they are added if the element
state is >=PAUSED, so it's not necessary to activate them manually
anymore.
This patch removes manual pad activation from gstaggregator, gstconcat,
gstfunnel, and gstinputselector.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3636>
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>
gst_element_add_pad() is supposed to activate the pad if the element
state is >= PAUSED and the pad is not already active.
Unfortunately, before this patch, the activation was performed while the
element lock was still taken, which ended causing a deadlock in
gst_pad_start_task() as it attempted to post `stream-status` message in
the element, which also requires the element lock.
Elements could work around this bug by activating the pad manually
before adding it to the element.
This patch fixes the problem by performing pad activation only after the
element lock has been released.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3635>
Commit d3a66f9851 introduced a potential deadlock with two parallel release_pad
calls, where one could release the main multiqueue lock (qlock) while still
holding the reconf_lock and then calling other routines which in some conditions
may try to acquire qlock again. The second release_pad could already acquire the
qlock and then start waiting on reconf_lock, which may never be possible because
because the first one isn't releasing it until it can acquire qlock.
Fix it by holding reconf_lock for the whole durationg of qlock, making this
particular deadlock impossible.
Fixes#1642
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3571>
On macOS, a Cocoa event loop is needed in the main thread to ensure
things like opening a GL window work correctly. In the past, this was
patched into glib via Cerbero, but that prevented us from updating it.
This workaround simply runs an NSApplication and then calls the
main function on a secondary thread, allowing GStreamer to correctly
display windows and/or system permission prompts, for example.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3532>
gst_plugin_load_by_name() assumed a plugin has a filename,
which isn't true for static plugins, leading to criticals.
If a plugin is already loaded, just return the loaded plugin,
which makes it work for static plugins as well as saving a
moment for already-loaded dynamic plugins.
Add locking in gst_plugin_is_loaded(), as a plugin may be
still being loaded in another thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3552>
This adds "id" variants to most debugging functions, and allows providing a
string identifier instead of a GObject.
This allows providing unified and clearer debug logs for all the
non-gobject-based items, and opens the way for more unified logging.
As an extension, copying the object name is avoided as much as possible, by
using it directly instead of going through another copy.
* API : gst_debug_message_get_object_id
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3483>
When coloring is in use, those escape codes are going to be created many times
for almost all debug lines.
Don't create plenty of temporary allocations, and instead build the escape code
ourselves statically
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3498>
The event type for instant-rate-change events was poorly chosen,
leading to them being re-sent too late and even after EOS.
Add a mechanism in GstPad for the sticky event order to be
different to the value of the event type to fix that up.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3387>
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>
When dealing with gapless input (i.e. streams with changing group-id in
GST_EVENT_STREAM_START), we need to take into account the elapsed
running-time (if applicable) in order to properly calculate levels and output
time. Without doing this all incoming data from future groups would be
considered as being "late" and would be consumed immediately.
This does **NOT** modify the actual segment and buffer times, and is only used
internally.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2784>
Introduce a new API that can return a GstTypeFind * with helper functions
and data set around buffer data.
While at it, drop factory field from GstTypeFindBufHelper. While it was
useful for logging, it was not passed through function arguments and keeping
it for logging would require an additional API increasing the API surface
and making it harder to use.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3296>
Use gst_debug_set_threshold_from_string's new reset behavior to undo
GST_DEBUG and ensure the logging tests have a known configuration.
`gst_debug_set_threshold_from_string ("LOG", TRUE)` has the same effect
as `gst_debug_set_threshold_from_string ("", TRUE)` followed by
`gst_debug_set_default_threshold (GST_LEVEL_LOG)`.
Don't bother remembering the default log level set when the test
started. It will get reset by the next test, anyway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/605>
TLDR: Make `gst_set_threshold_from_string ("", TRUE)` reset *all*
threshold settings, including those set by previous invocations of
`gst_debug_set_threshold_from_string`.
The docs say:
@reset: %TRUE to clear all previously-set debug levels before setting
new thresholds
What actually happens is it sets the default threshold to `ERROR`,
leaves the patterns in place and calls
`gst_debug_category_reset_threshold` on each category.
In effect, any category that is matched by a pattern gets reset to that
threshold if the app changed it by directly invoking
`gst_debug_category_set_threshold`. All other categories are reset to
`ERROR`.
In my opinion this parameter currently has little value, as the same
effect can be achieved by including `ERROR` (without a pattern) in the
string, as in `"foo*:WARNING,*bar:INFO,ERROR"`.
What I actually expect it to do is reset *all* threshold settings,
including those set by previous invocations of
`gst_debug_set_threshold_from_string`, starting off with a clean slate
for the patterns provided with the call.
Otherwise there is no API to do this, besides:
- Painfully removing patterns one-by-one via
`gst_debug_unset_threshold_for_name` *if* you know what the patterns
are.
- Adding a `*:FOO` pattern to affect all categories, which makes the
default threshold useless and practically leaks all the old
patterns.
In my opinion this also makes it fit better into the layers of threshold
config, which is:
1. Temporary:
- `gst_debug_category_set_threshold`
- `gst_debug_category_reset_threshold`
2. Patterns:
- `gst_debug_set_threshold_for_name`
- `gst_debug_unset_threshold_for_name`
- `gst_debug_set_threshold_from_string`
- `GST_DEBUG`
3. Default:
- `gst_debug_set_default_threshold`
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/605>
The scenario is the following:
* Thread 1 is pushing an EOS event on a sinkpad
* Thread 2 is pushing a STREAM_START event on the same sinkpad before Thread 1
returns. Note : It starts pushing the event after Thread 1 took the object lock.
There is a potential race between:
* The moment Thread 1 sets the EOS flag once it has finished sending the
event (via store_sticky_event). When it does that it has both the STREAM and
OBJECT lock
* The moment Thread 2 sends the STREAM_START event (Which should release that
EOS status), but removing the EOS flag is only done while holding the OBJECT
lock and not the STREAM_LOCK, which means it could be re-set by Thread 1 before
it then checks again the EOS flag (without the STREAM lock taken).
The EOS flag unsetting by STREAM_START should be done with the STREAM lock
taken, otherwise it will be racy.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1452
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3320>
With non-serialized sticky events, such as GST_EVENT_INSTANT_RATE, we both want
to store the event (for later re-linking) *AND* push the event in a non-blocking
way.
We therefore must *not* propagate pending sticky events if the event is "sticky
or serialized" but only if it's "serialized"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3254>
When using the child proxy notation (child::property=value) it may
happen that the target child does not exist at the time of parsing
(i.e: decodebin creates the encoder according to the contents of the
stream). On this cases, we want to delay the setting of the property
to later, when new elements are added. Previous logic performed a
delayed set even if the target child was found but the property
was not found in it. This should be treated as a failure because,
unlike missing elements, properties should not appear dynamically.
By not failing, typos in property names may go unnoticed to the end
user.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2908>
These tests relied on setting the name of an element twice to verify
that the last one set took precedence, however name is a CONSTRUCT property
and the parser now errors out when such properties are set twice, in
g_object_new_with_properties .
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3026>
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>
Starting with Meson 0.62, meson automatically populates the variables
list in the pkgconfig file if you reference builtin directories in the
pkgconfig file (whether via a custom pkgconfig variable or elsewhere).
We need this, because ${prefix}/libexec is a hard-coded value which is
incorrect on, for example, Debian.
Bump requirement to 0.62, and remove version compares that retained
support for older Meson versions.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1245
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3061>
- Update the docker image we use, starting using the standard one adding
`gtk4-doc` as required by rust plugins
- Update the plugins_doc_caches as required, some more plugins are built
with the new image
- Install ninja from pip as the version from F31 is too old
- Avoid buildings all GSreamer plugins when building the doc as it takes
time and resources for no good reason
- Stop linking to `GInstanceInitFunc` as it is not present in latest GLib
documentation, leading to warnings in hotdoc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2954>
We are always building our printf implementation, even when
GST_DEBUG is disabled, since we are exposing api (gst_print*)
that's dependant on our printf behavior.
We don't need to keep __gst_info_fallback_vasprintf around anymore.
Close#640
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/739>
GLib made the unfortunate decision to prevent libgobject from ever being
unloaded, which means that now any library which registers a static type
can't ever be unloaded either (and any library that depends on those,
ad nauseam).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/778>
If read_one or write_one was called but the stream closed before it could
read/write a whole packet, read_one/write_one would hang indefinitely,
consuming 100% CPU. This commit fixes that by treating a short read/write
as an error.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2964>
Theoretically having elements in locked state should not have any effect
at all when the surrounding bin is doing state changes. However
previously a state change error of a locked element would cause the
bin's state change to also fail, which is clearly not intended.
State change failures of locked elements are to be handled by whoever
set the element to locked state. By always returning them here it is
impossible for the owner of the element to handle state change failures
gracefully without potentially affecting the whole pipeline's state
changes.
Non-failure returns are still returned as-is as the distinction between
ASYNC/NO_PREROLL/SUCCESS has big consequences on the state changes of
the bin and overall pipeline. Theoretically SUCCESS should also be
returned in all cases but I can't estimate the effects this would have
on the overall pipeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2932>
The parent refcount is of the *transformed* buffer, not the input
buffer.
Also update the docs to clarify that @transbuf is the transformed
buffer, and not the buffer on which a transformation is being
performed.
Due to this bug, modifying the structure of a meta that has been
copied to another buffer fails with:
gst_structure_set: assertion 'IS_MUTABLE (structure) || field == NULL' failed
Add a test for the same.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2890>
The is_gst_mini_object_check would sometimes detect a proper GObject
as a mini object, and then bad things happen.
We know whether a pointer is a proper GObject or a MiniObject here
though, so just pass that information to the right code paths and
avoid the heuristics altogether.
Eliminates all remaining uses of object_is_gst_mini_object().
Fixes#1334
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2832>
The is_gst_mini_object_check would sometimes detect a proper GObject
as a mini object, and then bad things happen.
We know whether a pointer is a proper GObject or a MiniObject here
though, so just pass that information to the right code paths and
avoid the heuristics altogether.
There are probably more cases where the check should be eliminated.
Fixes#1334, maybe
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2832>
1.21.0.1 should not satisfy a check for 1.22.0.
If someone needs more control they should do a feature check for
the symbol in the headers or lib.
Based on a similar patch by Tim-Philipp Müller for libnice.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2501>
And also don't assert that there are no buffers queued up when handling
an EOS event. The pad's streaming thread might've already received a new
stream-start event and queued up a buffer in the meantime.
This still leaves a race condition where the srcpad task sees all pads
in EOS state and finishes the stream, while shortly afterwards a pad
might receive a stream-start event again, but this doesn't seem to be
solveable with the current aggregator design.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2769>
If compiled with -Dgstreamer:gst_debug=false and we have
GST_REMOVE_DISABLED defined we will get the following compiler error:
```
[...]/libgstreamer-1.0.so.0.2100.0.p/gst.c.o: in function `gst_deinit':
[...]/gst/gst.c:1258: undefined reference to `_priv_gst_debug_cleanup'
[...] hidden symbol `_priv_gst_debug_cleanup' isn't defined
```
Add the missing define guard to avoid this.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2648>
The latency messages are non-deterministic and can arrive before/after
async-done or during state-changes as they are posted by e.g. sinks from
their streaming thread but bins are finishing asynchronous state changes
from a secondary helper thread.
To solve this, expect latency messages at any time and assert that we
receive one at some point during the test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2643>
Previously it was only possible to request them with the exact template
name, e.g. 'src_%s', but not with "instantiated" names that would match
this template, e.g.'src_foo_bar'.
This is now possible and a test was added for this, in addition to
fixing a previously invalid test.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2635>
The mq we get out of the weak ref might be NULL if we're
shutting down, which could cause assertion failures or
crashes.
It might also cause miscompilations where the compiler just
optimises away the NULL check because it jumps to a code path
that then dereferences the pointer which clearly isn't going
to work. Seems like something like this happens with gcc 11.
Fixes#1262
Co-authored-by: Doug Nazar <nazard@nazar.ca>
Co-authored-by: Sebastian Dröge <sebastian@centricular.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2599>
Fixes:
../plugins/elements/gstmultiqueue.c: In function ‘gst_multi_queue_loop’:
../plugins/elements/gstmultiqueue.c:2394:19: warning: ‘is_query’ may be used uninitialized in this function [-Wmaybe-uninitialized]
2394 | if (object && !is_query)
| ^~~~~~~~~
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2593>
the licence in gstreamer/subprojects/gstreamer/gst/gstplugin.c
currently is defined to be one of:
LGPL GPL QPL GPL/QPL MPL BSD MIT/X11 0BSD Proprietary
The open source project for the kinesis plugin is using an
Apache 2.0 license. Because "Apache 2.0" is not one of the
supported licenses it automatically falls back to Proprietary.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2514>
While current and future LoongArch machines that are supposed to run
GStreamer all support unaligned accesses, there might be future
lower-end cores (e.g. the embedded product line) without such support,
and we may not want to penalize these use cases.
So, mark LoongArch as not supporting unaligned accesses for now, and
hope the compilers do a good job optimizing them. We can always flip
switch later.
Suggested-by: CHEN Tao <redeast_cn@outlook.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2443>
Various elements are assuming that the pointer matches a pad template
they know about, and also randomly created pad templates might be
missing some important information that is necessary to create a valid
pad.
For example, creating a new pad template for audiomixer's sinkpad
without providing the correct GType would cause audiomixer to create a
GstAggregatorPad. That will then later fail spectacularly because it
assumes that it got a GstAudioAggregatorPad.
Passing a pad template that does not belong to the element class in here
will easily lead to undefined behaviour.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2410>
Otherwise setting the srcpad caps based on the sinkpad caps event will
already push a segment event downstream before the upstream segment is
known.
If the upstream segments are just forwarded when the upstream segment
event arrives this would result in two segment events being sent
downstream, of which the first one will usually be simply wrong.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2372>
In the case where not all streams have received any data, growing the interleave
by only 100ms is too restrictive and would cause some (valid) mpeg-ts streams to
hang.
Bump up the interleave growth rate for those use-cases to 500ms per input (still
up to the limit of 5s).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2370>
When the GAP event was flagged with MISSING_DATA, subclasses
may want to adopt a different behaviour, for example by repeating
the last buffer.
As we turn these gap events into gap buffers, we need to flag
those, we do so with a new custom meta.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/708>
Meson generates a gdbinit file that will automatically load gstreamer
script. However that script uses a helper python module that needs
PYTHONPATH to be pointing into the right location in the source
tree to be able to find gst_gdb.py.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1796>
GLib guarantees libintl is always present, using proxy-libintl as
last resort. There is no need to mock gettex API any more.
This fix static build on Windows because G_INTL_STATIC_COMPILATION must
be defined before including libintl.h, and glib does it for us as part
as including glib.h.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2028>
If a file includes a new version of a plugin that exits in the
registry, the output of gst-inspect is incorrect. The output has the
correct version but incorrect filename, and element description.
This seems to have also fixed some documentation issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1344>
