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>
Protect clearing probes against concurrent modification which might happen
due to dispose does NOT guarantee that the object is not used anymore, as
it could be referenced again and so being continued used.
So, as in the rest of places where probes hook list is used, on dispose
it should be accessed holding the mutex "GST_OBJECT_LOCK (pad);" as
GHookList is not thread-safe.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/800>
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>
There is no guarantee that the clock is currently advancing, therefore if we
re-schedule (because of timeouts) a clock wait, we need to re-acquire the
current monotonic clock value against which we will wait.
Avoids spinning the cpu like mad (due to constant timeout) when clocks are
PAUSED.
Fixes#673
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/794>
The peeked buffer was always reset after calling ::aggregate() but under
no other circumstances. If a pad was removed after peeking and before
::aggregate() returned then the peeked buffer would be leaked.
This can easily happen if pads are removed from the aggregator from a
pad probe downstream of the source pad but still in the source pad's
streaming thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/785>
When compiling for 32bit architectures with 64bit time_t e.g. riscv32,
the static assert that the GstClockEntryImpl smaller or
equal to the struct _GstClockEntryImpl triggered.
(they were 12bytes off).
To fix this, the padding is increased by 8 bytes (on 32bit).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/695>
While we can fixe the upstream latency using the min-upstream-latency, we
are now forced to use queues (hence more thread) in order to store the pending
data whenever we have an upstream source that has lower latency.
This fixes the issue by allowing to buffer the fixed upstream latency. This is
particularly handy on single core systems were having too many threads can
cause serious performance issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/684>
Subsequent lookups in the hashtable are probably better done
on memory we're confident is allocated to us :)
It was easy to trigger invalid reads by calling gst_meta_register
with dynamically allocated memory, freeing that memory, then
calling gst_meta_get_info()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/657>
... and update meson file so that enable it only using required headers.
"dependency(...)" is unlikely successful for Windows SDK libraries
since it doesn't ship pkg-config file. So it needs to be changed
to "find_library()" to link corresponding .lib file. That would
result to most MSVC build system will link dbghelp.dll. However,
one drawback of the change is that gstreamer-1.0.dll will mandate
dbghelp.dll although it should be optional. So g_module_open() way
can be the most safe way in this case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/659>
When going to PLAYING we will now have a clock and can stop waiting on
the condition variable and instead start waiting on the clock if
necessary for the current configuration.
In the other direction when going to PAUSED the clock might have
disappeared and we might need to wait on the condition variable again
instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/653>
