Commit graph

2040 commits

Author SHA1 Message Date
Sebastian Dröge
abe60a92c4 funnel: Make sure to only lock the stream lock once
We also only unlock it once, and otherwise have it locked forever from
this thread, causing deadlocks on shutdown later.
2016-11-09 11:37:09 +02:00
Jan Schmidt
812d4976f0 fakesink: Add property to not drop out-of-segment buffers
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
2016-11-02 11:21:37 +11:00
Sebastian Dröge
c56e1d18c1 funnel: Always push all sticky events whenever we forward a serialized event
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
2016-11-01 21:01:28 +02:00
Sebastian Dröge
25bf63d6f7 tee: Set GST_PAD_FLAG_PROXY_CAPS before forwarding sticky events
https://bugzilla.gnome.org/show_bug.cgi?id=752213
2016-11-01 20:53:43 +02:00
Sebastian Dröge
cfdb97a135 Revert "queue: Fix race when calculating cur_level.time"
This reverts commit d03bd54780.

It breaks the unit test, although it ensures that only correct values
are used for calculations. Needs to be fixed up.

https://bugzilla.gnome.org/show_bug.cgi?id=773096
2016-10-21 15:23:14 +03:00
Stian Selnes
d03bd54780 queue: Fix race when calculating cur_level.time
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
2016-10-20 14:14:20 +03:00
Edward Hervey
ace418d226 queue2: Implement gst_event_full_func handling
Same as we do for queue
2016-10-08 13:56:18 +02:00
Carlos Rafael Giani
7413064f06 queue2: Update buffering if its enabled and low/high watermarks are changed
https://bugzilla.gnome.org/show_bug.cgi?id=771210
2016-09-17 09:54:29 +01:00
Carlos Rafael Giani
5988095f90 multiqueue: Add higher-resolution low/high-watermark properties
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
2016-08-31 12:56:19 +03:00
Carlos Rafael Giani
67874ea86d multiqueue: Distinguish between buffering percentage and buffering level
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
2016-08-31 12:56:19 +03:00
Carlos Rafael Giani
e83412b4fd multiqueue: Rename percent/percent_changed to buffering_percent(_changed)
This is a prerequisite for subsequent commits, and makes queue2 and
multiqueue code a little more consistent.

https://bugzilla.gnome.org/show_bug.cgi?id=770628
2016-08-31 12:56:19 +03:00
Edward Hervey
3117525cb6 multiqueue: Fix high_time wakeup logic
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
2016-08-30 12:28:40 +03:00
Thibault Saunier
4714ef2f8e Make use of the new GST_ELEMENT_FLOW_ERROR API all around.
https://bugzilla.gnome.org/show_bug.cgi?id=770158
2016-08-27 09:33:20 -03:00
Carlos Rafael Giani
db66cb51b3 queue2: Add higher-resolution low/high-watermark properties
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
2016-08-25 11:54:33 +03:00
Carlos Rafael Giani
e0f1a9e618 queue2: Distinguish between buffering percentage and buffering level
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
2016-08-25 11:54:33 +03:00
Nirbheek Chauhan
b2f9808722 Add support for Meson as alternative/parallel build system
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.html
http://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.
2016-08-19 21:26:14 +01:00
Edward Hervey
5154dcfbdc queue2: Post buffering messages earlier in ringbuffer mode
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
2016-08-12 16:26:40 +02:00
Josep Torra
5f021759b3 multiqueue: removed redundant call to g_thread_self
Remove an unneeded call to g_thread_self and minor coding style fix.
2016-08-08 16:42:06 +02:00
Jan Schmidt
b50a12b8ac inputselector: Handle stream-group-done
Handle the new stream-group-done message to unblock pads which
are waiting for the running time to advance on that group.

https://bugzilla.gnome.org/show_bug.cgi?id=768995
2016-07-25 20:22:20 +10:00
Jan Schmidt
4981e09bc7 inputselector: Wake other pads when selected goes EOS
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.
2016-07-25 19:34:52 +10:00
Edward Hervey
1ff80fbf52 queue2: Fix average input rate calculation on small input range
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
2016-07-11 10:08:44 +02:00
Sebastian Dröge
528fbfe7c1 funnel: Only forward sticky events on GAP events if needed
That is, if the active pad changed and if forwarding of sticky events is
requested at all. We otherwise forward events too often.
2016-07-07 13:32:39 +03:00
Edward Hervey
530001661d multiqueue: Fix behaviour with not-linked and eos pads
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
2016-07-01 09:47:31 +02:00
Tim-Philipp Müller
715939cce7 multiqueue: add gtk-doc blurb for new pad property 2016-06-30 14:37:17 +01:00
Edward Hervey
f4ba43b15d multiqueue: Add a pad property to "group" streams
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).
2016-06-30 14:45:10 +02:00
Vincent Penquerc'h
b3802f7a9e queue2: fix crash deleting current region for small ring buffers
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
2016-06-21 10:20:20 +01:00
Nicolas Dufresne
4603722e2d tee: Properly handle return value when only 1 pad
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
2016-06-17 13:03:20 +03:00
Sebastian Dröge
722ad08733 queue: Only unblock upstream waiting for the query once downstream is finished
... 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
2016-05-15 11:06:08 +03:00
Sebastian Dröge
5e43ee5989 typefind: Only push a CAPS event downstream if the sinkpad is not in PULL mode
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
2016-05-11 15:06:39 +03:00
Matej Knopp
efb1955ffb multiqueue: Ignore time when determining whether sparse stream limits have been reached
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
2016-04-29 16:09:23 +03:00
Carlos Rafael Giani
3bd5aeac52 multiqueue: Recheck buffering status after changing low threshold
https://bugzilla.gnome.org/show_bug.cgi?id=763757
2016-04-15 16:04:54 +03:00
Carlos Rafael Giani
a1d2f387c6 multiqueue: Recalculate fill level after changing high-threshold
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
2016-04-15 16:04:54 +03:00
Vincent Penquerc'h
53a7a991e2 multiqueue: catch errors and flushing case after lock
This ensures we can not get into an indefinite wait on the
following cond var wait.

https://bugzilla.gnome.org/show_bug.cgi?id=764999
2016-04-14 09:12:27 +01:00
Havard Graff
1bc8d9f2ea valve: don't send sticky events as a direct response to upstream events
Also refactor the existing valve test to actually test the valve,
and not just test the EOS mechanism of a pad.

https://bugzilla.gnome.org/show_bug.cgi?id=763753
2016-03-24 14:50:50 +02:00
Tim-Philipp Müller
bc78548cfe capsfilter: optimisation: avoid unnecessary gst_pad_has_current_caps() checks
No need to do this for every input buffer, since it involves
locking and iterating of the sticky events array and such.

https://bugzilla.gnome.org/show_bug.cgi?id=763337
2016-03-24 14:48:40 +02:00
Edward Hervey
f87ec5e014 queue: Use full running time for level calculation
Ensures we have proper time level estimation for the cases where
the incoming buffers have PTS/DTS outside of the segment start/stop
values.

https://bugzilla.gnome.org/show_bug.cgi?id=762995
2016-03-24 14:42:31 +02:00
Sebastian Dröge
0d5326950a typefind: Remove redundant assignment
CID 1357158
2016-03-24 11:49:44 +02:00
Jan Schmidt
c9b6848885 multiqueue: Fix not-linked pad handling at EOS
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
2016-03-18 21:21:44 +11:00
Romain Picard
20859af3f2 typefind: Allow caps query in "have-type" signal handlers
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
2016-03-15 18:58:06 +02:00
Sebastian Dröge
57bbd18471 typefind: Store caps on the pad before emitting have-type but send it downstream only in the default signal handler
https://bugzilla.gnome.org/show_bug.cgi?id=763491
2016-03-14 13:07:49 +02:00
Carlos Rafael Giani
46573a27da concat: Fix comment typo 2016-03-14 12:23:12 +02:00
Sebastian Dröge
a15fca1934 Revert "typefind: Store caps on the pad before emitting have-type but send it downstream only in the default signal handler"
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.
2016-03-12 12:57:47 +02:00
Sebastian Dröge
0835c3d656 typefind: Store caps on the pad before emitting have-type but send it downstream only in the default signal handler
https://bugzilla.gnome.org/show_bug.cgi?id=763491
2016-03-12 11:56:49 +02:00
Tim-Philipp Müller
cf0680017e elements: use new gst_element_class_add_static_pad_template()
https://bugzilla.gnome.org/show_bug.cgi?id=762778
2016-02-28 13:10:07 +00:00
Tim-Philipp Müller
94ec3f8a3e typefind: fix indentation 2016-02-27 16:39:50 +00:00
Sebastian Dröge
e953f20786 identity: Add a " " after pts: in the silent=false output 2016-02-25 14:12:00 +02:00
Edward Hervey
555df9d614 plugins: Check return values of gst_buffer_map()
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
2016-02-23 17:30:45 +01:00
Sebastian Dröge
fd253ab1ab Revert "queue2: add overrun signal"
This reverts commit 8ae8b2723d.

It's not used anymore by anything and was considered a bad idea in general.
2016-02-16 19:11:59 +02:00
Alex Henrie
78ba7f9a8e typefindelement: Improve English grammar
https://bugzilla.gnome.org/show_bug.cgi?id=761273
2016-01-29 10:34:44 +01:00
Tim-Philipp Müller
469475f06b multiqueue: two small fixes for when an existing pad is requested
Unlock when returning NULL from gst_single_queue_new(), and don't
crash with debug logging enabled if NULL is returned.

Spotted by Steven Hoving.
2016-01-20 10:06:14 +00:00