While the default implementation will spawn a thread per new
pushed task, this new implementation instead spawns a maximum
number of threads, then queues new tasks on existing threads.
The thread that the new task will be queued on is picked in
a pretty naive fashion, by simply popping the first thread
from a queue and pushing it back to the tail, but this is
an implementation detail and can always be sophisticated
in the future if the need arises.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/692>
If a device provider fails to start (for instance the pulseaudio provider unable
to connect to the PulseAudio daemon) then the monitor should not keep track of
it in its `started` providers list. Otherwise a false positive critical warning
would be raised.
This patch also switches the started_count type from bool to int, for
consistency. This is a counter, after all.
API: gst_device_provider_is_started
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/679>
Typing hints can only be passed to gst_value_deserialize()
through the type of the passed-in value. This means deserialization
can only target the desired type for the top-level elements,
making it for example impossible to deserialize an array of
flags to the expected type.
This commit exposes a new function, gst_value_deserialize_full(),
that takes an optional pspec as the extra parameter, and updates
the deserialization code to pass around that pspec, or the
element_spec when recursively parsing the elements of a list-type
value.
This allows for example passing arrays of flags through the
command line or gst_util_set_object_arg, eg:
foo="<bar,bar+baz>"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/629>
Custom meta is backed by a GstStructure, and does not require
that users of the API expose their GstMeta implementation as
public API for other components to make use of it.
In addition, it provides a simpler interface by ignoring the
impl vs. api distinction that the regular API exposes.
This new API is meant to be the meta counterpart to custom events
and messages, and to be more convenient than the lower-level API
when the absolute best performance isn't a requirement.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/609>
e.g. h264parse ! video/x-h264,stream-format=avc receives the following:
- caps: video/x-raw,stream-format=byte-stream
- gap event: baseparse tries to choose some default caps but would
override the downstream chosen caps field with upstreams value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/581>
It's been around for more than 4 years and people have built
lots of stuff on top of it, doesn't really make sense to keep
it marked as unstable. We're unlikely to change it now, and
we can always deprecate it and make a new one if needed.
This stabilises the following API:
- gst_tracer_register()
- gst_tracing_get_active_tracers()
- gst_tracing_register_hook()
- gst_tracer_record_new()
- gst_tracer_record_log()
Might also help a bit with #424
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/576>
It was zero and in some condition it means that the control binding
values where ignored (as shown in the test). Setting it to MAXDOUBLE
so that the first time we sync the values from a a timestamp in the
right range the proper value is computed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/564>
For providers that don't support dynamic probing, just fall back to doing
a static one on start() to make the UI developers life easier.
This also means that the monitor doesn't need to call _can_monitor() before
calling start.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/353>
There is a race-condition that can trigger the assertion in
gst_bus_add_signal_watch_full():
If gst_bus_add_signal_watch_full() is called immediately after
gst_bus_remove_signal_watch() then bus->priv->signal_watch may still be set
because gst_bus_source_dispose() or gst_bus_source_finalize() was not yet
called.
This happens if the corresponding GMainContext has the source queued for
dispatch. In this case, the following dispatch will only unref and delete
the signal_watch because it was already destroyed. Any pending messages
will remain until a new watch is installed.
So bus->priv->signal_watch can be cleared immediately when the watch is
removed. This avoid the race condition.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/543>
These can be passed to gst_type_mark_as_plugin_api, to inform
plugin cache generation.
For now a single flag is specified, "IGNORE_ENUM_MEMBERS", it
can be used for dynamically generated enums to avoid documenting
environment-specific enumeration members. An example is
GstX265EncTune.
Since those are using the clock for sync, they need to also
provide a clock for good measure. The reason is that even if
downstream elements provide a clock, we don't want to have
that clock selected because it might not be running yet.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/509>
This test takes 39 seconds on my machine even though it just runs
a couple of fakesrc num-buffers=2 ! fakesink pipelines. Most of
the cpu seems to be spent in libz, related to stack trace management.
Use stack-traces-flags=none instead of stack-traces-flags=full
until a better solution can be found. Might warrant more
investigation in any case..
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/503>
This is a follow up to review comments in !297
+ The posting of the buffering message in READY_TO_PAUSED isn't
needed, removing it made the test fail, but the correct fix
was simply to link elements together
+ Move code to relock the queue and set last_posted_buffering_percent
and percent_changed inside the buffering_post_lock in create_write().
This makes locking consistent with post_buffering()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/297>
This fixes a bug that occurs when an attempt is made to post a buffering
message before the queue2 was assigned a bus. One common situation where
this happens is when the use-buffering property is set to TRUE before the
queue2 was added to a bin.
If the result of gst_element_post_message() is not checked, and the
aforementioned situation occurs, then last_posted_buffering_percent and
percent_changed will still be updated, as if posting the message succeeded.
Later attempts to post again will not do anything because the code then
assumes that a message with the same percentage was previously posted
successfully and posting again is redundant.
Updating these variables only if posting succeed and explicitely
posting a buffering message in the READY->PAUSED state change ensure that
a buffering message is posted as early as possible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/297>
This is needed for cross-compiling without a build machine compiler
available. The option was added in 0.54, but we only need this in
Cerbero and it doesn't affect older versions so it should be ok.
Will just cause a spurious warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/477>
To allow the refcounting tracer to work better. In childproxy/iterator
these might be plain GObjects but gst_object_unref() also works on them.
In other places where it is never GstObject, g_object_unref() is kept.
Even when pulling a new 64KB buffer from upstream, don't return
more data than was asked for in the pull_range() method and then
return less later, as that confused subclasses like h264parse.
Add a unit test that when a subclass asks for more data, it always
receives a larger buffer on the next iteration, never less.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/530
This new API allow resuming a task if it was paused, while leaving it to
stopped stated if it was stopped or not started yet. This new API can be
useful for callback driver workflow, where you basically want to pause and
resume the task when buffers are notified while avoiding the race with a
gst_task_stop() coming from another thread.
When running in pull mode (for e.g. mp3 reading),
baseparse currently reads 64KB from upstream, then mp3parse
consumes typically around 417/418 bytes of it. Then
on the next loop, it will read a full fresh 64KB again,
which is a big waste.
Fix the read loop to use the available cache buffer first
before going for more data, until the cache drops to < 1KB.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/518
What may happen is that during the course of processing a buffer,
all of the pads in a flow combiner may disappear. In this case, we
would return NOT_LINKED. Instead return whatever the input flow return
was.
In case the buffer is not writable, the parent (the BufferList) is not
removed before calling func. So if it is changed, the parent (the BufferList)
of the previous buffer should be removed after calling func.
