Otherwise we're not guaranteed to read the very latest value that
another thread might've written in there when the pad was released, and
could instead work with an old value.
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
If the element before the sink needs $n buffers to produce one output
buffer, we were reffing $n events and unreffing only one.
Prevent this by using g_object_set_qdata_full() to handle the event
unreffing so we're sure no ref will be lost.
The records are static and so appear as false positives when using those
tracers with the leaks tracer as well.
The leaks tracer was already setting this flag on its record so let's
set it on the other ones as well.
In gst_download_buffer_wait_for_data(), when a seek is made with
perform_seek_to_offset() the `qlock` is released temporarily. Therefore,
the flushing condition can be set during this period and should be
checked.
This was not being checked before, causing occasional deadlocks when
GST_DOWNLOAD_BUFFER_WAIT_ADD_CHECK() was called.
GST_DOWNLOAD_BUFFER_WAIT_ADD_CHECK() assumes that the caller has already
checked that we're not flushing before, since this is done when
acquiring the lock; so if we release it temporarily somewhere, we need
to check for flush again.
Without that check, the function would keep waiting for the condition
variable to be notified before checking for flushing condition again,
and that may very well never happen. This was reproduced when during pad
deactivation when running WebKit in gdb.
sync=TRUE implementation changes the latency query of a non-live
upstream into live, though it wrongly set the upstream max latency to 0.
As non-live sources won't loose data if we wait longer, this should have
been reported as have no max latency limite (-1).
In the hotdoc inspector for example, pads are instantiated with
g_object_new, other code paths to get/set properties already make
that check.
And update doc cache
This feature was previously available only through the SIGUSR2 signal,
which meant it wasn't available on platforms that don't have UNIX
signals, such as Windows and with applications that already use
SIGUSR1 for something else.
Now we have action-signals for doing the same. These action signals
can also be used for fetching the checkpoint information
programmatically instead of printing to the debug log.
This allows programs to inspect the leaked objects directly, log them,
and so on. Unlike the existing mechanism to use SIGUSR1, this also
works on platforms that do not support UNIX signals, such as Windows
and with applications that already use SIGUSR1 for something else.
This will be useful in combination with the next commit when we add
API to get a list of active tracers so that consumers of the API can
easily distinguish tracer objects.
The code implicitly uses this value when the stack trace is not FULL.
Mostly useful for documenting the behaviour when each flag is passed
and for translating to/from strings.
There was a race where we could still get the pad event function
called when its private member were already unset, leading to
a segfault in the event handler:
```
0 gst_multi_queue_src_event (pad=<optimized out>, parent=<optimized out>, event=0x7f3ff0007600) at ../subprojects/gstreamer/plugins/elements/gstmultiqueue.c:2534
2534 ret = gst_pad_push_event (sq->sinkpad, event);
[Current thread is 1 (Thread 0x7f406c0258c0 (LWP 21925))]
(gdb) bt
0 0x00007f4062ec1399 in gst_multi_queue_src_event (pad=<optimized out>, parent=<optimized out>, event=0x7f3ff0007600 [GstEvent]) at ../subprojects/gstreamer/plugins/elements/gstmultiqueue.c:2534
1 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_check (handler=0x7f4062ec1360 <gst_multi_queue_src_event>, event=0x7f3ff0007600 [GstEvent], parent=0x7f3fcc01f090 [GstMultiQueue|multiqueue167], pad_monitor=0x7f3fe809e7c0 [GstValidatePadMonitor|validatepadmonitor2213]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2101
2 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_func (pad=<optimized out>, parent=0x7f3fcc01f090 [GstMultiQueue|multiqueue167], event=0x7f3ff0007600 [GstEvent]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2374
3 0x00007f406b904387 in gst_pad_send_event_unchecked (pad=pad@entry=0x7f3fdc027650 [GstPad|src_0], event=event@entry=0x7f3ff0007600 [GstEvent], type=<optimized out>, type@entry=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5772
4 0x00007f406b90481b in gst_pad_push_event_unchecked (pad=pad@entry=0x7f4058182fc0 [GstPad|sink], event=event@entry=0x7f3ff0007600 [GstEvent], type=type@entry=GST_PAD_PROBE_TYPE_EVENT_UPSTREAM) at ../subprojects/gstreamer/gst/gstpad.c:5417
5 0x00007f406b90f016 in gst_pad_push_event (pad=0x7f4058182fc0 [GstPad|sink], event=event@entry=0x7f3ff0007600 [GstEvent]) at ../subprojects/gstreamer/gst/gstpad.c:5554
6 0x00007f406a1c99ba in gst_video_decoder_src_event_default (decoder=0x7f3fe81c6060 [GstTheoraDec|theoradec46], event=<optimized out>) at ../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideodecoder.c:1532
7 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_check (handler=0x7f406a1ca270 <gst_video_decoder_src_event>, event=0x7f3ff0007600 [GstEvent], parent=0x7f3fe81c6060 [GstTheoraDec|theoradec46], pad_monitor=0x7f4028163aa0 [GstValidatePadMonitor|validatepadmonitor2216]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2101
8 0x00007f406b40f46d in gst_validate_pad_monitor_src_event_func (pad=<optimized out>, parent=0x7f3fe81c6060 [GstTheoraDec|theoradec46], event=0x7f3ff0007600 [GstEvent]) at ../subprojects/gst-devtools/validate/gst/validate/gst-validate-pad-monitor.c:2374
```
This make the GstSingleQueue a MiniObject, mainly so it is properly
refcounted.
This also make use of the GstMultiQueuePad class for srcpads which
is totally valid as srcpads and sinkpads share the same SingleQueue
object.
The `query` argument of gst_pad_query is "transfer none".
Query objects are "borrowed" by the pad query handlers and those
should never unref them.
This was leading to double freed queries in a very racy way with nested
GESTimelines.
Otherwise when seeking backwards we would keep the last_stop at the last
position we saw until playback passed the seek position again, and if
switching to the next pad happens in the meantime we would set the wrong
offset in the outgoing segment.
This URI is valid:
data:,;base64
(It encodes the literal string ";base64")
But would lead to a crash because the code assumed the semicolon would
be placed before the colon.
Quoting RFC 2396:
For resiliency, programs interpreting URI should treat upper case
letters as equivalent to lower case in scheme names (e.g., allow
"HTTP" as well as "http").
This seems to happen when another client is accessing the file at the
same time, and retrying after a short amount of time solves it.
Sometimes partial data is written at that point already but we have no
idea how much it is, or if what was written is correct (it sometimes
isn't) so we always first seek back to the current position and repeat
the whole failed write.
It happens at least on Linux and macOS on SMB/CIFS and NFS file systems.
Between write attempts that failed with EACCES we wait 10ms, and after
enough consecutive tries that failed with EACCES we simply time out.
In theory a valid EACCES for files to which we simply have no access
should've happened already during the call to open(), except for NFS
(see open(2)).
This can be enabled with the new max-transient-error-timeout property, and
a new o-sync boolean property was added to open the file in O_SYNC mode
as without that it's not guaranteed that we get EACCES for the actual
writev() call that failed but might only get it at a later time.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/305
The pad name sotred in the latency event has no longer the name of the element,
so we have to get the element Id, element name and pad name values from the data
structure and compare all 3 values.
First, the event would be leaved, but also when an element takes
several buffers before producing one, we want the reported latency to be
the aggregation, so the distance from the oldest buffer.
This sets back the default to trace only pipeline latency, and add flags
to enabled element tracing. It is now possible to only trace element
latency, only trace pipeline latency, trace both or none.
This removes the passing of pad inside of a GstEvent. While this is not
a bug, it may affect the live time of the pad, hense change the pipeline
behaviour.
I copied `error-after` to make the `eos-after` property, but it turned
out there were some problems with that one, so this patch: adds
separate counters (so setting to NULL and reusing the element will
still work); clarifies the properties' min values; and reports an
error when both are set.
Using `num-buffers` can be unpredictable as buffer sizes are often
arbitrary (filesrc, multifilesrc, etc.). The `error-after` property on
`identity` is better but obviously reports an error afterwards. This
adds `eos-after` which does exactly the same thing but reports EOS
instead.
By doing so GL source elements can successfully reuse the GL context and display
of downstream elements. This change fixes an issue in playbin when using
gltestsrc where the context query made by the source element would fail and the
source element would create a second (useless) GLDisplay.
Allows determining from downstream what the expected bitrate of a stream
may be which is useful in queue2 for setting time based limits when
upstream does not provide timing information.
Implement bitrate query handling in queue2
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/60
If upstream is pushing buffers larger than our limits, only 1 buffer
is ever in the queue at a time. Once that single buffer has left the
queue, a 0% buffering message would be posted followed immediately by a
100% buffering message when the next buffer was inserted into the queue
a very short time later. As per the recommendations, This would result
in the application pausing for a short while causing the appearance of
a short stutter.
The first step of a solution involves not posting a buffering message if
there is still data waiting on the sink pad for insertion into the queue.
This successfully drops the 0% messages from being posted however a
message is still posted on each transition to 100% when the new buffer
arrives resulting in a string of 100% buffering messages. We silence
these by storing the last posted buffering percentage and only posting a
new message when it is different from or last posted message.
The post tracer hooks have a GstQuery argument which was truncated from
the trace. As the post hook is the one that contains the useful data,
this bug was hiding the important information from that trace.
Since we use full signed running times, we no longer need to clamp
the buffer time.
This avoids having the position of single queues not advancing for
buffers that are out of segment and never waking up non-linked
streams (resulting in an apparent "deadlock").
If we ever get a GST_FLOW_EOS from downstream, we might retry
pushing new data. But if pushing that data doesn't return a
GstFlowReturn (such as pushing events), we would end up returning
the previous GstFlowReturn (i.e. EOS).
Not properly resetting it would cause cases where queue2 would
stop pushing on the first GstEvent stored (even if there is more
data contained within).
Otherwise we write out the SYNC_AFTER buffer immediately, and the
previously queued up buffers afterwards which then breaks the order of
data.
Also add various debug output.
fflush() has no effect because we use writev() directly, so fsync()
should be used instead which is actually flushing the kernel-side
buffers.
As a next step, a non-line-buffered buffering mode is to be added.
https://bugzilla.gnome.org/show_bug.cgi?id=794173
Otherwise downstream will consider the pipeline not live if the active
pad is live, even though some inactive pads might be live and might
require a non-zero latency configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=796901
And make use of it in the typefind element. It's useful to distinguish
between the different errors why typefinding can fail, and especially to
not consider GST_FLOW_FLUSHING as an actual error.
https://bugzilla.gnome.org/show_bug.cgi?id=796894
And make use of that in the typefind element to also be able to make use
of the extension in push mode. It previously only did that in pull mode
and this potentially speeds up typefinding and might also prevent false
positives.
https://bugzilla.gnome.org/show_bug.cgi?id=796865
When using queue2 as a queue it was using GQueue with
individually allocated queue items, so two allocs for
each item. With GstQueueArray we can avoid those.
https://bugzilla.gnome.org/show_bug.cgi?id=796483
Meson supports building both static and shared libraries in a single
library() call. It has the advantage of reusing the same .o objects and
thus avoid double compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=794627
Catch users wrongly setting foreign pads or wrong pads as
the selector's active pad, which leads to all kinds of
other issues. It's a programming error so handle it just
like we would if we had direct API.
https://bugzilla.gnome.org/show_bug.cgi?id=795309
The queue gets filled by the tail, so a query will always be the tail
object, not the head object. Also add a _peek_tail_struct() method to the
GstQueueArray to enable looking at the tail.
With unit test to prevent future regression.
https://bugzilla.gnome.org/show_bug.cgi?id=762875
Start task on new source pads added at runtime after they
have been added to the element, not during activation.
This ensures the pads can post their CREATE stream-status
messages and the application can set thread priorities.
https://bugzilla.gnome.org/show_bug.cgi?id=756867
`./configure --disable-gst-tracer-hooks` didn't do anything, hooks were
always enabled regardless of the option. It works correctly in the
Meson build though.
When EOS reaches concat, it will switch to the next candidate as its
activate pad.
The problem arises when there is only one sinkpad, the "active" pad
becomes NULL. This results in concat becoming unusable after it receives
a *single* EOS on its single sinkpad.
If we detect there is a single sinkpad and there is no current active pad:
* If we are waiting (from selected sink event/buffer), become the current
active pad.
* If there is a seek request, send it upstream. We don't switch the
active_sinkpad property at that point in time, since the seek could
fail. If the seek succeeds, the following SEGMENT (or STREAM_START)
will cause the pad_wait() to elect that pad as the new active one.
* Flush events get forwarded
https://bugzilla.gnome.org/show_bug.cgi?id=790167
