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
Include the timestamp of the recorded log as in the 'stats' tracer.
This can be useful, for example, to plot a graph showing the latency
over time.
https://bugzilla.gnome.org/show_bug.cgi?id=781315
The goal of this tracer is to measure the processing latency between a
src and a sink. In push mode, the time was read after the chain function
have returned. As the amount of time we wait to get synched is reverse
to the amount of latency the source introduced, the result was quite
surprising.
This patch moves the latency calculation in the pre-push hook. When
there is no processing in a a pipeline (e.g. fakesrc ! fakesink), the
latency will now be 0 as it's supposed to. For pull mode, the code was
already correct. When GstBaseSink operate in pull mode, the processing
time is done durring the pull, so pull-post is the right hook. The
synchronization will happen after the pull has ended. Note that
GstBaseSink rarely operate in pull mode.
https://bugzilla.gnome.org/show_bug.cgi?id=788431
If the aggregated size is 0 and we create a pool, the pool would provide
buffers with no memory assigned. Handle that case and skip the pool.
This was the behaviour before cf803ea9f4.
Add a test for this scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=730758
When enabled, this property will make the allocation query fail. This is
the same as one could have done using a tee before the tee started
implementing the allocation query.
https://bugzilla.gnome.org/show_bug.cgi?id=730758
Otherwise we might try unscheduling a clock id (that does not exist
yet), then the streaming thread waits for id and the state change never
continues because the streaming thread is blocked.
Also shutting down and flushing and similar should return FLUSHING, not
EOS. The stream is not over, we're just not accepting any buffers
anymore.
After EOS, it is possible for a pad to be resetted by sending
either a STREAM_START or SEGMENT event
Mimic the same behaviour when receiving STREAM_START/SEGMENT events
in queue if we are EOS'd
https://bugzilla.gnome.org/show_bug.cgi?id=786056
After EOS, it is possible for a pad to be resetted by sending
either a STREAM_START or SEGMENT event
Mimic the same behaviour when receiving STREAM_START/SEGMENT events
in queue2 if we are EOS'd
https://bugzilla.gnome.org/show_bug.cgi?id=786056
When queue-like elements are in "EOS" situation (received GST_FLOW_EOS
from downstream or EOS was pushed), they drain buffers/events that
wouldn't be processed anyway and let through events that might
modify the EOS situation.
Previously only GST_EVENT_EOS and GST_EVENT_SEGMENT events were let
through, but we also need to allow GST_EVENT_STREAM_START to go
through since it resets the EOS state of pads since 1.6
https://bugzilla.gnome.org/show_bug.cgi?id=786034
When downstream returns NOT_LINKED, we return the buffering level
as being 100%.
Since the queue is no longer being consumed/used downstream, we
want applications to essentially "ignore" this queue for buffering
purposes.
If other streams are still being used, those stream buffering levels
will be used. If none are used, upstream will post an error message
on the bus indicating no streams are used.
https://bugzilla.gnome.org/show_bug.cgi?id=785799
... and use the biggest interleave value among streaming threads.
This is to optimize multiqueue size adaptation on adaptive streaming
use case with "use-interleave" property.
https://bugzilla.gnome.org/show_bug.cgi?id=784448
Return the correct flow return instead of returning always flushing.
This would cause queue to convert not-linked to flushing and making
upstream elements stop.
Based on the previous patch for queue2.
https://bugzilla.gnome.org/show_bug.cgi?id=776999
Return the correct flow return instead of returning always flushing.
This would cause queue2 to convert not-linked to flushing and making
upstream elements stop.
https://bugzilla.gnome.org/show_bug.cgi?id=776999
active-pad switch causes reconfigure event with lock taken,
and upstream element might query the current position or duration
before returning the reconfigure event.
Meanwhile, gst_input_selector_get_linked_pad() is used to get srcpad
inside of default query handle, and it takes also lock.
Since inputselector is still locked by active-pad switch, and so the query
cannot be handled further.
https://bugzilla.gnome.org/show_bug.cgi?id=775445
This is what Autoconf already does for us, so just do this. Avoids
people making typos while adding header or function checks. Because we
use a config.h.meson, such typos won't even be noticed.
Also, starting from Meson 0.36.0, the XCode 8 workaround that we use for
clock_gettime is no longer needed.
Before emitting have-type, switch to NORMAL
mode, as part of the have-type processing sends
the caps event downstream, which might trigger
actions like downstream autoplugging or
flushing seeks - and the latter are only
passed upstream if we've set typefind to NORMAL
mode.
It might happen that the srcpad task function is never called at all, in
which case unlocking everything from there will never happen.
Make sure to unlock everything another time after the task function is
definitely stopped.
https://bugzilla.gnome.org/show_bug.cgi?id=776039
This is an API break but that API has not been released yet.
We are passing a flag rather than a simple boolean as we can imagine
to implement more features in the future for example to retrieve a
stack trace for all the threads, etc..
Retrieving source file and line numbers is pretty
expensive while getting a stack trace, this new argument
allows the user to decide to retrieve a backtrace
without those infos instead which is much faster.
For example running $ GST_LEAKS_TRACER_STACK_TRACE=1 GST_DEBUG=GST_TRACER:7 \
GST_TRACERS=leaks time gst-launch-1.0 videotestsrc num-buffers=1 ! fakesink:
* With simple stack traces:
0.04s user 0.02s system 99% cpu 0.060 total
* With full stack traces:
0.66s user 0.23s system 96% cpu 0.926 total
https://bugzilla.gnome.org/show_bug.cgi?id=775423
