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>
