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>
