Commit graph

17083 commits

Author SHA1 Message Date
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
Guillaume Desmottes
e73650e5f9 miniobject: weak_unref: display the pointer of the object if failing
That's generally the most useful information to help debugging the
problem.

https://bugzilla.gnome.org/show_bug.cgi?id=768579
2016-07-08 17:52:48 +01:00
Guillaume Desmottes
757a8b04c0 bin: properly display the type of the removed message
Makes debugging easier.

https://bugzilla.gnome.org/show_bug.cgi?id=768579
2016-07-08 17:52:40 +01:00
Tim-Philipp Müller
7a0f4422fa element: re-create threadpool after cleaning up tasks
We don't free this from gst_deinit() but from gst_task_cleanup_all(),
so more GStreamer API may be called. In particular makes unit tests
work again with CK_FORK=no.

https://bugzilla.gnome.org/show_bug.cgi?id=768577
2016-07-08 17:46:06 +01:00
Guillaume Desmottes
9ba53ff1fc leaks: warn if object is destroyed while the tracer is disposing
This should not happen and generally means some thread is still running.

https://bugzilla.gnome.org/show_bug.cgi?id=768578
2016-07-08 17:35:30 +01:00
Guillaume Desmottes
40727d9c83 element: clean up thread pool from gst_task_cleanup_all()
This ensures that all async operations (started from gst_element_call_async())
have been completed and so there is no extra thread running.

Fix races when checking for leaks on unit tests as some of those
operations were still running when the leaks tracer was checking for
leaked objects.

https://bugzilla.gnome.org/show_bug.cgi?id=768577
2016-07-08 17:27:32 +01:00
Guillaume Desmottes
1ed4140d00 leaks tracer: use G_OS_UNIX to check for signal support
Checking for signal.h is not good enough as it's present in Windows.
Those signals are UNIX specific anyway.

https://bugzilla.gnome.org/show_bug.cgi?id=767857
2016-07-08 12:38:46 +03:00
Guillaume Desmottes
17c37efa83 leaks tracer: add creation stack trace support
This allow us to provide the trace of leaked objects making it easier
to debug.

https://bugzilla.gnome.org/show_bug.cgi?id=767862
2016-07-08 12:07:53 +03:00
Guillaume Desmottes
3bb5c1e73a leaks tracer: add checkpoint support using SIGUSR2
https://bugzilla.gnome.org/show_bug.cgi?id=767857
2016-07-08 11:23:43 +03:00
Guillaume Desmottes
53d2e8c977 leaks tracer: log alive objects when receiving SIGUSR1
We don't want to automatically catch signals so use an env variable to
enable this feature.

https://bugzilla.gnome.org/show_bug.cgi?id=767857
2016-07-08 11:23:38 +03: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
Miguel París Díaz
9f982e2d75 pad: check query caps answered and caps not NULL
https://bugzilla.gnome.org/show_bug.cgi?id=768450
2016-07-07 10:08:15 +03:00
Sebastian Dröge
52b1d7f42d Back to development 2016-07-06 13:50:56 +03:00
Sebastian Dröge
af5c9cbb20 Release 1.9.1 2016-07-06 13:05:02 +03:00
Sebastian Dröge
476e139735 Update .po files 2016-07-06 11:37:56 +03:00
Sebastian Dröge
25247aabf1 po: Update translations 2016-07-06 10:17:37 +03:00
Jan Alexander Steffens (heftig)
d71e03b3be baseparse: Don't add calculated bitrates until threshold
Waiting before posting calculated bitrates seems to be the
intent of the code, so avoid adding them to the tag list
pushed with the first frame.

When the threshold is reached, gst_base_parse_update_bitrates
sets tags_changed, so this posts the calculated ones right
that moment.

This prevents an insane average calculated from just the
first (key) frame from getting posted.

https://bugzilla.gnome.org/show_bug.cgi?id=768439
2016-07-05 19:42:38 +03:00
Sebastian Dröge
8e8b8a8d34 baseparse: Make sure to not create an invalid event order when generating the default CAPS event because of a GAP event
There must be a SEGMENT event before the GAP event, and SEGMENT events must
come after any CAPS event. We however did not produce any CAPS yet, so we need
to ensure to insert the CAPS event before the SEGMENT event into the pending
events list.

https://bugzilla.gnome.org/show_bug.cgi?id=766970
2016-07-04 10:35:41 +02:00
Jan Schmidt
17f9ac5657 gstinfo: Avoid gcc 6 warning that breaks the tests build
gcc 6 has problems detecting and avoiding throwing
a warning for tautological compares in macros (they
should only trigger for compares outside macros).

Avoid them with a nasty cast of one parameter to void *

https://bugzilla.gnome.org/show_bug.cgi?id=764526
2016-07-01 22:38:01 +10: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
3623f168e9 streams: sprinkle some Since: markers for docs 2016-06-30 15:07:28 +01: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
Edward Hervey
63f6f05d66 gst: New Stream listing/selection system
* GstStream
* GstStreamCollection
* GST_EVENT_SELECT_STREAMS
* GST_MESSAGE_STREAM_COLLECTION
2016-06-30 12:31:06 +02:00
Sebastian Dröge
241d0f16f6 poll: #define EWOULDBLOCK to EAGAIN if it's not defined on Windows 2016-06-29 23:24:02 +02:00
Sebastian Dröge
60a2087cb1 bufferpool: Fix handling of the GstPoll
Especially if multiple threads are waiting for buffers to be available again,
the current code was wrong. Fix this and document clearly how the GstPoll is
supposed to be used.

Also fix some potential races with reading from the GstPoll before writing
actually happened.

https://bugzilla.gnome.org/show_bug.cgi?id=767979
2016-06-29 21:21:04 +02:00
Sebastian Dröge
4ff2721810 bus: Make sure to always read the control after popping a message
It might happen that we popped the message before writing of the control
happened. In this case we just have to retry again a bit later, and failure to
do so will cause an additional byte in the control and the GSource /
gst_poll_wait() to always wake up again immediately.

https://bugzilla.gnome.org/show_bug.cgi?id=750397
2016-06-29 21:21:04 +02:00
Sebastian Dröge
149127b755 systemclock: Improve GstPoll handling and don't check for impossible errno values
Also just read/write control every time, GstPoll is optimized by itself
already to only do I/O if switching between empty and one byte.

https://bugzilla.gnome.org/show_bug.cgi?id=750397
2016-06-29 21:21:04 +02:00
Sebastian Dröge
cda3f1213b poll: Clarify when FALSE is returned from read/write_control()
And also mention what the expected values of errno are going to be.

write_control() will only ever return FALSE if there was a critical error. It
will never return because of EINTR, EAGAIN or EWOULDBLOCK.

read_control() will return FALSE if there was no byte to read, in which case
errno would be EWOULDBLOCK.
In all other cases there was a critical error.

https://bugzilla.gnome.org/show_bug.cgi?id=750397
2016-06-29 21:21:04 +02:00
Sebastian Dröge
254955df62 poll: set_controllable(), restart() and set_flushing() are only valid for non-timer GstPolls
On timer GstPolls it will cause the control socket state to become
inconsistent as now one less read_control() than write_control() be would
needed.

Similarly, read_control() and write_control() are only valid on timer
GstPolls.

https://bugzilla.gnome.org/show_bug.cgi?id=750397
2016-06-29 21:21:04 +02:00
Sebastian Dröge
0bfc9fb212 poll: Warn if the return value of gst_poll_read_control() is unused
This might fail even under correct usage, e.g. if read_control() is called
from another thread before write_control() finished in another. It has to be
retried then, or other measures have to be taken, depending on how it is used
by the surrounding code.

https://bugzilla.gnome.org/show_bug.cgi?id=750397
2016-06-29 21:21:04 +02:00
Matthew Gruenke
cd06aea103 poll: Fix various race conditions with read_control() and write_control()
This addresses slightly different race conditions on Linux and Windows, and
fixes gst_poll_read_control() when control_pending == 0.

On Linux, the socketpair() used for control should not be made O_NONBLOCK.
If there's any propagation delay between set->control_write_fd.fd and
set->control_read_fd.fd, even the mutex now held will not be sufficient to
prevent a race condition.  There's no benefit to using O_NONBLOCK, here.
Only liabilities.

For Windows, it's necessary to fix the race condition between testing
set->control_pending and performing WAKE_EVENT()/RELEASE_EVENT().  This is
accomplished by acquiring and holding set->lock, for both of these operations.
We could optimize the Linux version by making this Windows-specific.

For consistency with the Linux implementation, Windows' RELEASE_EVENT()
has also been made to block, although it should never happen.

Also, changed release_wakeup() to return TRUE and decrement control_pending
only when > 0.  Furthermore, RELEASE_EVENT() is called only when
control_pending == 1.

Finally, changed control_pending to use normal, non-atomic arithmetic
operations, since it's now protected by set->lock.

Note: even though the underlying signaling mechanisms are blocking,
release_wakeup() is effectively non-blocking, as it will only attempt to read
from control_read_fd.fd after a byte has been written to control_write_fd.fd
or WaitForSingleObject() after it's been signaled.

https://bugzilla.gnome.org/show_bug.cgi?id=750397
2016-06-29 21:21:04 +02:00
Guillaume Desmottes
e11539c30b bus: chain up GObject::constructed() to the parent class' implementation
Needed so GstBus can be tracked by the leaks tracer.

https://bugzilla.gnome.org/show_bug.cgi?id=768141
2016-06-28 17:23:17 +03:00
Nirbheek Chauhan
54fa564e01 gstconfig.h: Don't use extern with dllexport
GCC emits an error for this with -Werror:

plugin.c:22:1: error: 'gst_plugin_desc' initialized and declared 'extern' [-Werror]

This matches how glib does symbol exporting.

https://bugzilla.gnome.org/show_bug.cgi?id=767463
2016-06-24 01:09:32 +01:00
Nirbheek Chauhan
48088867db win32: Don't use dllexport/import when only building statically
If the prototypes in the public API have dllimport in them when building
statically on Windows, the compiler will look for symbols with symbol
mangling and indirection corresponding to a DLL. This will cause a build
failure when trying to link tests/examples/etc.

External users of GStreamer also need to define -DGST_STATIC_COMPILATION
if they want to link to static gstreamer libraries on Windows.

A similar version of this patch has been committed to all gstreamer
repositories.

https://bugzilla.gnome.org/show_bug.cgi?id=767463
2016-06-23 23:39:45 +01:00
Nicolas Dufresne
084bb505f4 Automatic update of common submodule
From ac2f647 to f363b32
2016-06-21 11:45:26 -04:00
Vincent Penquerc'h
08d30b05c6 tests: add a test for small ring buffer sizes
https://bugzilla.gnome.org/show_bug.cgi?id=767688
2016-06-21 10:20:21 +01: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
Tim-Philipp Müller
e452acb634 tests: gstobject: fix typo in test name 2016-06-20 11:34:49 +01:00
Reynaldo H. Verdejo Pinochet
6b8494072e docs/design/part-tracing: fix reference to renamed func 2016-06-17 13:31:12 -07: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
Stefan Sauer
06d2c6989d gst-plot-traces.sh: add a script to plot gst-tracer graphs
The script extracts cpu-usage data from a tracelog and plots it via gnuplot.
2016-06-16 15:53:52 +02:00
Sebastian Dröge
6b9e70d193 device: Fix typo
paramater -> parameter
2016-06-15 16:12:36 +02:00
Tim-Philipp Müller
09d5ff4097 info: flesh out GST_PTR_FORMAT docs a bit 2016-06-14 19:16:33 +01:00
Sebastian Dröge
b9a4a2a952 basesink: Update start time when losing state only if we were in PLAYING
If we were in PAUSED, the current clock time and base time don't have much to
do with the running time anymore as the clock might have advanced while we
were PAUSED. The system clock does that for example, audio clocks often don't.

Updating the start time in PAUSED will cause a) the wrong position to be
reported, b) step events to step not just the requested amount but the amount
of time we spent in PAUSED. The start time should only ever be updated when
going from PLAYING to PAUSED to remember the current running time (to be able
to compensate later when going to PLAYING for the clock time advancing while
PAUSED), not when we are already in PAUSED.

Based on a patch by Kishore Arepalli <kishore.arepalli@gmail.com>

The updating of the start time when the state is lost was added in commit
ba943a82c0 to fix the position reporting when
the state is lost. This still works correctly after this change.

https://bugzilla.gnome.org/show_bug.cgi?id=739289
2016-06-13 20:20:44 +02:00
Sebastian Dröge
37713c3388 pad: Log pad offsets as signed times 2016-06-11 22:18:22 +03:00
Sebastian Dröge
da46fe236b pad: Also check the number of segment events and if other serialized events and queries trigger segment updating too
https://bugzilla.gnome.org/show_bug.cgi?id=765049
2016-06-11 21:57:00 +03:00
Sebastian Dröge
c8cae6a94b pad: Add unit test for pad offset handling on src pads
https://bugzilla.gnome.org/show_bug.cgi?id=765049
2016-06-11 21:40:15 +03:00
Sebastian Dröge
8c7da1d426 adapter: Rename functions and implement new functions, update test
We don't do calculations with different units (buffer offsets and bytes)
anymore but have functions for:
1) getting the number of bytes since the last discont
2) getting the offset (and pts/dts) at the last discont

and the previously added function to get the last offset and its distance from
the current adapter position.

https://bugzilla.gnome.org/show_bug.cgi?id=766647
2016-06-10 09:49:33 +03:00
Edward Hervey
67ae0ad225 adapter: Add methods to query current offset
API: gst_buffer_prev_offset
API: gst_buffer_get_offset_from_discont

The gst_buffer_get_offset_from_discont() method allows retrieving the current
offset based on the GST_BUFFER_OFFSET of the buffers that were pushed in.

The offset will be set initially by the GST_BUFFER_OFFSET of
DISCONT buffers, and then incremented by the sizes of the following
buffers.

The gst_buffer_prev_offset() method allows retrievent the previous
GST_BUFFER_OFFSET regardless of flags. It works in the same way as
the other gst_buffer_prev_*() methods.

https://bugzilla.gnome.org/show_bug.cgi?id=766647
2016-06-10 09:49:33 +03:00