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
The correct behaviour of anything stuck in the ->render() function
between ->unlock() and ->unlock_stop() is to call
gst_base_sink_wait_preroll() and only return an error if this returns an
error, otherwise, it must continue where it left off!
https://bugzilla.gnome.org/show_bug.cgi?id=773912
When running in sync-by-running-time mode, pad groups
that have exactly 1 pad and it's not-linked might never
wake up after computing a high time, as the per-pad-group
high time was only recomputed when a pad in the group
advances.
Wake those up using the global multiqueue high-time across
all other groups instead.
https://bugzilla.gnome.org/show_bug.cgi?id=774322
When subtracting queued data sizes from upstream queries
in queue, queue2, downloadbuffer and typefind, clamp the
result to not go negative, in case upstream returned
a nonsense value that's too small (as could happen if
upstream is estimating, or just broken)
Implement handling in basesink to not unconditionally discard
out-of-segment buffers and expose it as a new property on fakesink
(not unconditionally in all basesink based sinks).
The property defaults to FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=765734
Otherwise downstream will have an inconsistent set of sticky events at this
point, e.g. when a TAG event is pushed and downstream wants to relate it to
the stream by looking at the current STREAM_START event.
https://bugzilla.gnome.org/show_bug.cgi?id=768526
On the first buffer, it's possible that sink_segment is set but
src_segment has not been set yet. If this is the case, we should not
calculate cur_level.time since sink_segment.position may be large and
src_segment.position default is 0, with the resulting diff being larger
than max-size-time, causing the queue to start leaking (if
leaky=downstream).
One potential consequence of this is that the segment event may be
stored on the srcpad before the caps event is pushed downstream, causing
a g_warning ("Sticky event misordering, got 'segment' before 'caps'").
https://bugzilla.gnome.org/show_bug.cgi?id=773096
low/high-watermark are of type double, and given in range 0.0-1.0. This
makes it possible to set low/high watermarks with greater resolution,
which is useful with large multiqueue max sizes and watermarks like 0.5%.
Also adding a test to check the fill and watermark level behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=770628
To make the code clearer, and to facilitate future improvements, introduce
a distinction between the buffering level and the buffering percentage.
Buffering level: the queue's current fill level. The low/high watermarks
are in this range.
Buffering percentage: percentage relative to the low/high watermarks
(0% = low watermark, 100% = high watermark).
To that end, get_percentage() is renamed to get_buffering_level(). Also,
low/high_percent are renamed to low/high_watermark to avoid confusion.
mq->buffering_percent values are now normalized in the 0..100 range for
buffering messages inside update_buffering(), and not just before sending
the buffering message. Finally the buffering level range is parameterized
by adding a new constant called MAX_BUFFERING_LEVEL.
https://bugzilla.gnome.org/show_bug.cgi?id=770628
When calculating the high_time, cache the group value in each singlequeue.
This fixes the issue by which wake_up_next_non_linked() would use the global
high-time to decide whether to wake-up a waiting thread, instead of the group
one, resulting in those threads constantly spinning.
Tidy up a bit the waiting logic while we're at it.
With this patch, we go from 212% playing a 8 audio / 8 video file down to less
than 10% (most of it being the video decoding).
https://bugzilla.gnome.org/show_bug.cgi?id=770225
low/high-watermark are of type double, and given in range 0.0-1.0. This
makes it possible to set low/high watermarks with greater resolution,
which is useful with large queue2 max sizes and watermarks like 0.5%.
Also adding a test to check the fill and watermark level behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=769449
To make the code clearer, and to facilitate future improvements, introduce
a distinction between the buffering level and the buffering percentage.
Buffering level: the queue's current fill level. The low/high watermarks
are in this range.
Buffering percentage: percentage relative to the low/high watermarks
(0% = low watermark, 100% = high watermark).
To that end, get_buffering_percent() is renamed to get_buffering_level(),
and the code at the end that transforms to the buffering percentage is
factored out into a new convert_to_buffering_percent() function. Also,
the buffering level range is parameterized by adding a new constant called
MAX_BUFFERING_LEVEL.
https://bugzilla.gnome.org/show_bug.cgi?id=769449
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Mathieu Duponchelle <mathieu.duponchelle@opencreed.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
In ringbuffer mode we need to make sure we post buffering messages *before*
blocking to wait for data to be drained.
Without this, we would end up in situations like this:
* pipeline is pre-rolling
* Downstream demuxer/decoder has pushed data to all sinks, and demuxer thread
is blocking downstream (i.e. not pulling from upstream/queue2).
* Therefore pipeline has pre-rolled ...
* ... but queue2 hasn't filled up yet, therefore the application waits for
the buffering 100% messages before setting the pipeline to PLAYING
* But queue2 can't post that message, since the 100% message will be posted
*after* there is room available for that last buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=769802
Other pads that are waiting for the stream on the selected
pad to advance before they finish waiting themselves
should be given the chance to do so when the selected pad
goes EOS. Fixes problems where input streams can end up
waiting forever if the active stream goes EOS earlier than
their own end time.
When dealing with small-ish input data coming into queue2, such as
adaptivedemux fragments, we would never take into account the last
<200ms of data coming in.
The problem is that usually on TCP connection the download rate
gradually increases (i.e. the rate is lower at the beginning of a
download than it is later on). Combined with small download time (less
than a second) we would end up with a computed average input rate
which was sometimes up to 30-50% off from the *actual* average input
rate for that fragment.
In order to fix this, force the average input rate calculation when
we receive an EOS so that we take into account that final window
of data.
https://bugzilla.gnome.org/show_bug.cgi?id=768649
This is an update on c9b6848885
multiqueue: Fix not-linked pad handling at EOS
While that commit did fix the behaviour if upstream sent a GST_EVENT_EOS,
it would break the same issue when *downstream* returns GST_FLOW_EOS
(which can happen for example when downstream decoders receive data
from after the segment stop).
GST_PAD_IS_EOS() is only TRUE when a GST_EVENT_EOS has flown through it
and not when a GST_EVENT_EOS has gone through it.
In order to handle both cases, also take into account the last flow
return.
https://bugzilla.gnome.org/show_bug.cgi?id=763770
When syncing by running time, multiqueue will throttle unlinked streams
based on a global "high-time" and the pending "next_time" of a stream.
The idea is that we don't want unlinked streams to be "behind" the global
running time of linked streams, so that if/when they get linked (like when
switching tracks) decoding/playback can resume from the same position as
the other streams.
The problem is that it assumes elements downstream will have a more or less
equal buffering/latency ... which isn't the case for streams of different
type. Video decoders tend to have higher latency (and therefore consume more
from upstream to output a given decoded frame) compared to audio ones, resulting
in the computed "high_time" being at the position of the video stream,
much further than the audio streams.
This means the unlinked audio streams end up being quite a bit after the linked
audio streams, resulting in gaps when switching streams.
In order to mitigate this issue, this patch adds a new "group-id" pad property
which allows users to "group" streams together. Calculating the high-time will
now be done not only globally, but also per group. This ensures that within
a given group unlinked streams will be throttled by that group's high-time
instead.
This fixes gaps when switching downstream elements (like switching audio tracks).
Ensure we do not attempt to destroy the current range. Doing so
causes the current one to be left dangling, and it may be dereferenced
later, leading to a crash.
This can happen with a very small queue2 ring buffer (10000 bytes)
and 4 kB buffers.
repro case:
gst-launch-1.0 fakesrc sizetype=2 sizemax=4096 ! \
queue2 ring-buffer-max-size=1000 ! fakesink sync=true
https://bugzilla.gnome.org/show_bug.cgi?id=767688
This patch handle the case when you have 1 pad (so the fast path is
being used) but this pad is removed. If we are in allow-not-linked, we
should return GST_FLOW_OK, otherwise, we should return GST_FLOW_UNLINKED
and ignore the meaningless return value obtained from pushing.
https://bugzilla.gnome.org/show_bug.cgi?id=767413
- we know number of filter items is not going to change,
but compiler doesn't
- only do GST_IS_TRACER check for GObjects, not mini objects
- use non-type check cast macros in performance critical paths
... when flushing and deactivating pads. Otherwise downstream might have a
query that was already unreffed by upstream, causing crashes or other
interesting effects.
https://bugzilla.gnome.org/show_bug.cgi?id=763496
The other signal handlers of the type-found signal might have reactivated
typefind in PULL mode already, pushing a CAPS event at that point would cause
deadlocks and is in general unexpected by elements that are in PULL mode.
https://bugzilla.gnome.org/show_bug.cgi?id=765906
Basically, sq->max_size.visible is never increased for sparse streams in
overruncb when empty queue has been found;
If the queue is sparse it just skip the entire logic determining whether
max_size.visible should be increased, deadlocking the demuxer.
What should be done instead is that when determining if limits have been
reached, to ignore time for sparse streams, as the buffer may be far in the
future.
https://bugzilla.gnome.org/show_bug.cgi?id=765736
This ensures the following special case is handled properly:
1. Queue is empty
2. Data is pushed, fill level is below the current high-threshold
3. high-threshold is set to a level that is below the current fill level
Since mq->percent wasn't being recalculated in step #3 properly, this
caused the multiqueue to switch off its buffering state when new data is
pushed in, and never post a 100% buffering message. The application will
have received a <100% buffering message from step #2, but will never see
100%.
Fix this by recalculating the current fill level percentage during
high-threshold property changes in the same manner as it is done when
use-buffering is modified.
https://bugzilla.gnome.org/show_bug.cgi?id=763757
Ensure that not-linked pads will drain out at EOS by
correctly detecting the EOS condition based on the EOS
pad flag (which indicates we actually pushed an EOS),
and make sure that not-linked pads are woken when doing
EOS processing on linked pads.
https://bugzilla.gnome.org/show_bug.cgi?id=763770
If an application calls gst_pad_query_caps from its "have-type" signal handler,
then the query fails because typefind->caps has not been set yet.
This patch sets typefind->caps in the object method handler, before the signal
handlers are called.
https://bugzilla.gnome.org/show_bug.cgi?id=763491
This reverts commit 0835c3d656.
It causes deadlocks in decodebin, which currently would deadlock if the caps
are already on the pad in have-type and are forwarded while copying the sticky
events (while holding the decodebin lock)... as that might cause the next
element to expose pads, which then calls back into decodebin and takes the
decodebin lock.
This needs some more thoughts.
They can fail for various reasons.
For non-fatal cases (such as the dump feature of identiy and fakesink),
we just silently skip it.
For other cases post an error message.
https://bugzilla.gnome.org/show_bug.cgi?id=728326
Remove calls to gst_pad_has_current_caps() which then go on to call
gst_pad_get_current_caps() as the caps can go to NULL in between. Instead just
use gst_pad_get_current_caps() and check for NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=759539
Change the gst_tracer_record_new() api to take the parameters the make the
spec structure directly. This allows us to own the top-level structure and
also collect the args so that we can take ownership of the sub-structures.
https://bugzilla.gnome.org/show_bug.cgi?id=760821
The use-tags-bitrate property makes queue2 look at
tag events in the stream and extract a bitrate for the
stream to use when calculating a duration for buffers
that don't have one explicitly set.
This lets queue2 sensibly buffer to a time threshold
for any bytestream for which the general bitrate is known.
Only hide GstTracer and GstTracerRecord API behind GST_USE_UNSTABLE_API,
but don't spew any warnings, otherwise everyone has to define this
to avoid compiler warnings.
This reverts parts of commit 89ee5d948d.
We use this class to register tracer log entry metadata and build a log
template. With the log template we can serialize log data very efficiently.
This also simplifies the logging code, since that is now a simple varargs
function that is not exposing the implementation details.
Add docs for the new class and basic tests.
Remove the previous log handler.
Fixes#760267
rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples
https://bugzilla.gnome.org/show_bug.cgi?id=759432
segment.position is meant for internal usage only, but the various
GST_EVENT_SEGMENT creationg/parsing functions won't clear that field.
Use the appropriate segment boundary as an initial value instead
When synchronizing the output by time, there are some use-cases (like
allowing gapless playback downstream) where we want the unlinked streams
to stay slightly behind the linked streams.
The "unlinked-cache-time" property allows the user to specify by how
much time the unlinked streams should wait before pushing again.
Multiqueue should only be used to cope with:
* decoupling upstream and dowstream threading (i.e. having separate threads
for elementary streams).
* Ensuring individual queues have enough space to cope with upstream interleave
(distance in stream time between co-located samples). This is to guarantee
that we have enough room in each individual queues to provide new data in
each, without being blocked.
* Limit the queue sizes to that interleave distance (and an extra minimal
buffering size). This is to ensure we don't consume too much memory.
Based on that, multiqueue now continuously calculates the input interleave
(per incoming streaming thread). Based on that, it calculates a target
interleave (currently 1.5 x real_interleave + 250ms padding).
If the target interleave is greater than the current max_size.time, it will
update it accordingly (to allow enough margin to not block).
If the target interleave goes down by more than 50%, we re-adjust it once
we know we have gone past a safe distance (2 x current max_size.time).
This mode can only be used for incoming streams that are guaranteed to be
properly timestamped.
Furthermore, we ignore sparse streams when calculating interleave and maximum
size of queues.
For the simplest of use-cases (single stream), multiqueue acts as a single
queue with a time limit of 250ms.
If there are multiple inputs, but each come from a different streaming thread,
the maximum time limit will also end up being 250ms.
On regular files (more than one input stream from the same upstream streaming
thread), it can reduce the total memory used as much as 10x, ending up with
max_size.time around 500ms.
Due to the adaptive nature, it can also cope with changing interleave (which
can happen commonly on some files at startup/pre-roll time)
This will mean a much lower delay before a subtitles track changes take
effect. Also avoids excessive memory usage in many cases.
This will also consider sparse streams as (individually) never full, so
as to avoid blocking all playback due to one sparse stream.
https://bugzilla.gnome.org/show_bug.cgi?id=600648
* Avoid the computation completely if we know we don't need it (not in
sync time mode)
* Make sure we don't override highest time with GST_CLOCK_TIME_NONE on
unlinked pads
* Ensure the high_time gets properly updated if all pads are not linked
* Fix the comparision in the loop whether the target high time is the same
as the current time
* Split wake_up_next_non_linked method to avoid useless calculation
https://bugzilla.gnome.org/show_bug.cgi?id=757353
When preparing a buffering message, don't report 0% if there
is any bytes left in the queue at all. We still have something
to push, so don't tell the app to start buffering - maybe
we'll get more data before actually running dry.
