And handle the case of a NULL buffer being returned cleanly, which is
valid as long as a buffer list is returned instead. Previously this
would cause an assertion because of calling gst_buffer_unref() with
NULL.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6460>
The attempt to free the domain data is happeing twice during the ptp deinit.
Once while iterating through the list domain_data and second while iterating
through the list domain_clocks, so this is crashing the application
trying to gst_ptp_deinit
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6443>
On systems using UsrMerge (like openSUSE or Fedora), /lib64 is
a symlink to /usr/lib64. So dladdr is returning the path to
the gstreamer library in /lib64 in priv_gst_get_relocated_libgstreamer.
Later gst_plugin_loader_spawn tries to build the path to the
gst-plugin-scanner helper from /lib64 and ends up trying to use
/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner which doesn't exist.
By canonicalizing the path with a call to realpath, gst-plugin-scanner
is found correctly under
/usr/lib64/../libexec/gstreamer-1.0/gst-plugin-scanner
Similar change applied to gstreamer/libs/gst/net/gstptpclock.c
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6322>
If we drop all messages with the same clock id as ours we will also
drop all messages coming from a PTP clock on our host since both clock
ids are build from the same MAC address.
At least for Linux we do not see our own messages anyway since the
network stack can well distinguish between multicast send from our
socket or from another socket on the same machine. To make sure that
this works for all supported platforms just drop delay requests since
this is the only message that is sent from the GStreamer PTP clock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6172>
decodebin(3) runs a scheduling query before pads are activated which
ultimately triggers basesrc->start which will automatically call
`gst_base_src_start_complete` for any source that is not marked as
'async'. This calls will harmlessly bail out in `not_activated_yet`
so we should not warn in that case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/6011>
On fedora 38 (and it was the case in previous releases), the
quark_seq_id is optimized out so getting quarks from the
global variable always failed. This patch works around that by assuming
it is a valid quark whenever the quark_seq_id is not accessible.
This issue often manifested as Python Exception <class 'TypeError'>:
can only concatenate str (not "NoneType") to str when debugging as
other parts of the code assume that getting the quark for a GType name
will work.
Same as https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3559
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5986>
When we finish a frame, we pass a size which semantic can easily be confused.
Improve the documentation to clarify that the parameter size is the amount of
input data being consumed and, if set, the output_buffer size can differ.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5754>
Test included.
The problem appears when aggregator drops the query while
it's being proccessed by the klass->sink_query handler.
This can happen on FLUSH_START event. If the query is still
in the queue, it can be safely dropped, but if it's already
in the klass->sink_query() handler, then sink pad has no
choice and has to wait for the proccessing to complete.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5765>
When the subclass attempts to finish without an explicit `out_buffer`,
we take a buffer from our adapter. We need to make this buffer writable
before copying the metadata.
This led to data races such as in the following pipeline, which randomly
messed up the buffer PTS:
gst-launch-1.0 -e audiotestsrc timestamp-offset=5555 num-buffers=100 \
! opusenc ! tee name=t ! queue ! opusparse ! fakesink silent=0 \
t. ! queue ! opusparse ! fakesink silent=0 -v | grep '0000, dur'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5718>
This allows configuring the TTL that is used for multicast packets sent
out on the sockets, and is defaulting to 1 as before. The default might
change at some point.
In some networks multiple hops are needed to reach the PTP clock and
this allows to configure GStreamer in a way that works in such networks.
At a later time, per-domain or per-interface TTL configurations might be
added when needed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5649>
While the minimum timeout duration is 5s, checking only every 5s means
that we would notice this 4.9s too late in the worst case.
Checking once a second reduces this considerably while keeping the
number of wakeups still low.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5520>
Otherwise it can happen that we regularly switch back and forth between
clocks under certain circumstances for no good reason.
Also remove redundant comparison when comparing the steps removed between two
clocks.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5520>
When the property "start-time-selection" is set to "first", it
calculates the start time of the output from the buffer pts
(converting it to running time of the segment), but if the
rate is negative, the real start is not the pts, but the
pts + duration, because it plays from the end of the buffer
to it's start.
As a result of this bug, in the negative rate, when the
start-time-selection=first, the first frame is dropped
by the videoaggregator (reproduced on d3d11compositor).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5276>
unlock_stop() is expected to be run while the streaming thread is idle. To
guaranty this is the case, we should take the streamlock, but its not
possible to take this lock during state transitions from PAUSED to
PLAYING as the wait function that we want to terminate is holding it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
After a create() call, which may have returned FLUSHING or a filled buffer,
if it possible that we detect that we are now in pause. As live sourced
don't produce data in pause, drop the buffer is any and later retry creating
a buffer. This will ensure that we resume from pause while avoiding displaying
ancient frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
When the pipeline goes from Playing to Paused, this change will invoke
unlock in the derived class. When the pipeline goes from Paused to
Playing, this change will invoke unlock_stop in the derived class.
This feature was removed in commit 523de1a9 and is now being restored.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
Adds gst_queue_array_sort for sorting and gst_queue_array_push_sorted{,struct} for pushing in a sorted order.
All three functions accept a comparison GCompareDataFunc along with optional user_data to pass to it.
In gst_queue_array_sort a small workaround was needed to correctly sort non-struct arrays. Like what _find() already
does, we need to dereference our pointers first, to make sure we can use the same comparison functions everywhere.
This is done via a small wrapper around the provided comparison function.
The array can also wrap around (tail ends up 'before' the head), in which case we have to reorder the array (similar to
what do_expand() does) to then be able to use an existing sorting function, like g_qsort_with_data().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5112>
It's possible and normal to tear down a harness while the pipeline is
running. At the same time, it's desired for the
`gst_harness_pad_link_tear_down()` function to be synchronous.
This has created the conflict where the main thread may request a
harness to be torn down while it's in use or about to be used by a pad
in the streaming thread.
The previous implementation of `gst_harness_pad_link_tear_down()` tried
to handle this by taking the stream lock of the harnessed pad and
resetting all the pad functions while holding it. That approach was
however insufficient to handle the case where a non-serialized event
or query is being handled or about to be handled in a different thread.
This edge case was one race condition behind the flakes in the flvmux
check tests -- the rest being covered by https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2803.
This patch fixes the problem by adding an intermediate ref-counted
object, GstHarnessLink, which replaces the usage of the HARNESS_KEY
association. GstHarnessLink allows the pad functions such as event,
query and chain to borrow a reference to GstHarness and more
importantly, to lock the GstHarnessLink during their usage to block
(delay) its destruction until no users are left, and guarantee that any
future user will not receive an invalid GstHarness handle past its
destruction.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5017>
Race condition without this patch:
- srcpad task is being stopped in gst_aggregator_stop_srcpad_task()
- at that moment, in pre-queue event handler, gst_pad_get_task_state()
returned GST_TASK_PAUSED
- then in srcpad task got stopped in gst_aggregator_stop_srcpad_task()
- finally srcpad task got resumed in pre-queue event handler
To address it, checks "running" flag in pre-queue event handler.
Both pre-queue stream-start event handler and "running" flag
are protected by SRC_LOCK already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4847>
