The pads can be NULL when we're racing with pad removal, e.g. when the
pads get removed between `gst_pad_iterate_internal_links` acquiring the
parent element and `gst_multi_queue_iterate_internal_links` locking the
multiqueue.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/811>
When posting buffering messages there are no safe places or timing to avoid
deadlocks.
Previously the code was trying to be "smart" by only forwarding serialized
queries if the queue was empty ... but that could happen when queue2 hadn't yet
posted a 100% buffering message. Meaning the pipeline might be paused and
pushing a serialized query downstream might never complete.
Therefore let's completely disable forwarding of serialized queries when
`queue2` is used as a buffering element (meaning `ALLOCATION` and `DRAIN`
queries).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/797>
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>
Fixes the following build error and missing '-pthread' argument when
linking:
subprojects/gstreamer/plugins/tracers/libgstcoretracers.so.p/gstleaks.c.o: In function `gst_leaks_tracer_setup_signals':
/work/build32/../subprojects/gstreamer/plugins/tracers/gstleaks.c:919: undefined reference to `pthread_atfork'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/571>
Use thread-safe accesses to pad peers and parent objects. This
fixes some crashers and all the non-safe access patterns I could
spot. There's still some weirdness when using the latency
tracer on pipeline chains that aren't yet linked, but this
at least stops it segfaulting.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/269>
The signal handlers were performing mutex operations in the signal handlers
which is bad idea that may lead to deadlocks.
1. Implement a separate signal thread to handle the signals.
2. Use the glib provided signal GSource to avoid performing operations in
the signal handler.
Fix#186
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/487>
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>
When we want to perform a downstream bitrate query, just
set the reconfigure flag on the srcpad and get the streaming
thread to do it. That avoids emitting a downstream query
when receiving the upstream RECONFIGURE event - which can
lead to deadlocks if downstream is sending the event from
within a lock - e.g. input-selector.
If querying the downstream bitrate changes the cached
value, then make sure to update our buffering state
and potentially post a BUFFERING message to the application.
Fixes: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/566
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/501>
The deadlock was the following:
* One thread requests a new pad, the internal lock is kept while adding the pad
* Another thread (or the same one) requests the internal links of a pad (could
be that pad)... which also requires that lock.
That internal lock is not required when adding the pad to the element (which is
the last action when requesting a new pad). The fact it will be actually used
will be *after* the request pad function is released.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/512>
When posting a buffering message succesfully:
* Remember the *actual* percentage value that was posted
* Make sure we only reset the percent_changed variable if the value we just
posted is indeed different from the current value
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/511>
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>
Making it less random and fixing a race in a GES test where we have
as pipeline:
```
videotestsrc ! output-selector name=s ! input-selector name=i s. ! timecodestamper ! i.
```
which we seek, leading to the seek reaching the video testsrc
without going through the timecodestamper and generating a buffer
even before timecodestamper gets the seek which means that its internal
state is wrong compared to the datastream it gets and attaches wrong
timecode metas.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/485>
Identity was ignoring seek and flush events even when using
a single segment. In the end it means that we couldn't compute
buffers running-time and stream time after seeks.
This commits adds support for flushing seeks only as I have no idea
what to do for non flushing ones.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/450>
In reverse playback, buffers are played back from buffer.stop
(buffer.pts + buffer.duration) to buffer.pts running times which
mean that we need to use the buffer end running time as a buffer
timestsamp, not the buffer pts when using a single segment in reverse
playback.
This is now being tested in
`validate.test.identity.reverse_single_segment`
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/450>
downloadbuffer source pad pushes the first buffer before pushing
Stream Start and Segment event, when working in Push mode.
Fix:Pushing Stream Start and Segment after coming out of
wait for data, and before pushing the buffer to next element.
Fixes#534
The returned "stats" structure contains, for now, one array called
"queues" with one GstStructure per internal queue, containing said
queue's current level of bytes, buffers, and time.
It is not explicitly specified anywhere in the docs that 0% buffering is
at low-watermark and 100% buffering is at high-watermark. It was
specified only in the sources.
current_buf_mem_idx stands for the index of memory of the corresponding
buffer which is scheduled to be written in the next iteration.
If all memory objects were scheduled to be written in the current
iteration, reset the index to zero so that starting from the first
memory object of the next buffer.
Previously the default and full modes were the same. Now the default
mode is like before: it accumulates all buffers in a buffer list until
the threshold is reached and then writes them all out, potentially in
multiple writes.
The new full mode works by always copying memory to a single memory area
and writing everything out with a single write once the threshold is
reached.
