Age | Commit message (Collapse) | Author |
|
https://bugzilla.gnome.org/show_bug.cgi?id=752213
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=769023
|
|
It was always evaluating to false, so clock_gettime.c was always being
included into libcheck. This breaks building on Hurd and causes us to
always override clock_gettime() even when it is available.
https://bugzilla.gnome.org/show_bug.cgi?id=773813
|
|
clock_gettime was also added for iOS 10.0, so don't use it if we're
targetting an older version. That would've caused the symbol to not be
found at runtime on older devices.
|
|
With XCode 8, clock_gettime will be incorrectly detected as being
available regardless of what OS X version we're targetting because the
symbol is available in the .tbd library as a weak symbol.
See: https://github.com/Homebrew/homebrew-core/issues/3727#issue-170086273
It's only starting from macOS 10.12 that clock_gettime is actually
available, so we can unconditionally disable it when targetting older
versions. We cannot simply do AC_CHECK_FUNCS with -Wl,-no_weak_imports
because the autoconf check does its own prototype declaration that
doesn't trigger that compiler flag.
https://bugzilla.gnome.org/show_bug.cgi?id=772451
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=771773
|
|
It's NULL-safe while the libc implementation may not be.
https://bugzilla.gnome.org/show_bug.cgi?id=771773
|
|
|
|
When we get GST_ITERATOR_RESYNC, we need to call gst_iterator_resync()
otherwise we will always get GST_ITERATOR_RESYNC (and that loop would
run forever).
|
|
Same as we do for queue
|
|
Add forgotten "git commit --amend" for last commit
Need to cast away the const as g_queue_foreach() takes a non-const GQueue*
|
|
|
|
Useful for removing the default handler from bindings.
|
|
peek/pop/read_buffer/take_buffer functions
https://bugzilla.gnome.org/show_bug.cgi?id=768948
|
|
gst_structure_id_get() returns a new reference so the returned device is
actually (transfer full).
The code using this API was already correct but the code example in
comments was not.
https://bugzilla.gnome.org/show_bug.cgi?id=768776
|
|
|
|
annotation
gsttypefindhelper.c:485: Warning: GstBase: invalid "transfer" annotation for gsize: only valid for array, struct, union, boxed, object and interface types
|
|
The queue is allocated as part of the tracer struct so we should not
use g_queue_free() to free it.
https://bugzilla.gnome.org/show_bug.cgi?id=764985
|
|
The format string contains a process id, but we did not provice one. This
caused us to log garbage since all args got shifted.
|
|
Otherwise both iterators share the same references, the second one
usually resulting in a crash when being freed.
https://bugzilla.gnome.org/show_bug.cgi?id=771649
|
|
POSIX standards requires strsignal() to return a pointer to a char,
not a const pointer to a char. [1] On uClibc, and possibly other
libc's, that do not HAVE_DECL_STRSIGNAL, libcompat.h declares
const char *strsignal (int sig) which causes a type error.
[1] man 3 strsignal
https://bugzilla.gnome.org/show_bug.cgi?id=763567
|
|
|
|
|
|
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
|
|
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
|
|
It's what introspection.mak does as well. Should
fix spurious build failures on gnome-continuous.
|
|
So CC="ccache gcc" works properly.
|
|
|
|
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.
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=768450
|
|
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
|
|
Needed so GstBus can be tracked by the leaks tracer.
https://bugzilla.gnome.org/show_bug.cgi?id=768141
|
|
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 is an update on c9b6848885f4675d447e823c8fb117e247658252
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
|
|
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
|
|
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
ba943a82c0bbfd17c9ee9f5068d44c9d9274fd13 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
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=762330
|
|
When GST_PAD_PROBE_EVENT_FLUSH is used, the probes already have
a data type and it is not needed to automatically add the default
types. Without this, EVENT_FLUSH probes that didn't specify a data
type would be called also for other data such as buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=762330
|
|
|
|
|
|
|
|
... 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
|
|
Make it explicit that the pad is only blocked while the callback is running,
and the pad will be unblocked again once the callback returned.
If BLOCK and IDLE behaviour is needed, both need to be used.
https://bugzilla.gnome.org/show_bug.cgi?id=766002
|
|
The subclass should do that already, but just in case do it ourselves too as a
fallback. Without this, e.g. playbin will just wait forever if this fails
because it is triggered as part of an ASYNC state change.
|
|
When doing a transition from PLAYING to PLAYING, we will fail
to forward an EOS message on the bus, and noone else will ever
send it because there'll be no actual state changed message.
Allow EOS through directly in that case.
|
|
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
|
|
activate another and failing
When activating a pad in PULL mode, it might already be in PUSH mode. We now
first try to deactivate it from PUSH mode and then try to activate it in PULL
mode. If the activation fails, we would set the pad to flushing and set it
back to its old mode. However the old mode is wrong, the pad is not in PUSH
mode anymore but in NONE mode.
This fixes e.g. typefind in decodebin reactivating PUSH/PULL mode if upstream
actually fails to go into PULL mode after first PUSHING data to typefind.
|
|
The root element was not unreffed when iterating over ancestors.
https://bugzilla.gnome.org/show_bug.cgi?id=765961
|
|
g_signal_emit_by_name() is not like gst_app_src_push_buffer() due to reference
counting limitations of signals, it does *not* take ownership of the buffer.
|
|
Passing years > 9999, months > 12 or days > 31 to gst_date_time_new() will
cause an assertion and generally does not make much sense. Instead consider it
as a parsing error like hours > 24 and return NULL.
|