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
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.
Just use the default c_std used by the compiler. With GCC on Linux this
is gnu89.
Tons of errors related to time.h, signal.h, etc when using c99:
FAILED: libs/gst/check/libcheck/check@sta/check_run.c.o
cc '-Ilibs/gst/check/libcheck/check@sta' '-fdiagnostics-color=always' '-I../libs/gst/check/libcheck' '-Ilibs/gst/check/libcheck' '-I.' '-I../.' '-Ilibs/gst/check/libcheck/..' '-I../libs/gst/check/libcheck/..' '-pipe' '-Wall' '-Winvalid-pch' '-std=c99' '-DHAVE_CONFIG_H' '-fPIC' '-O2' '-g' '-fPIC' '-MMD' '-MQ' 'libs/gst/check/libcheck/check@sta/check_run.c.o' '-MF' 'libs/gst/check/libcheck/check@sta/check_run.c.o.d' -o 'libs/gst/check/libcheck/check@sta/check_run.c.o' -c ../libs/gst/check/libcheck/check_run.c
In file included from ../libs/gst/check/libcheck/check_run.c:21:0:
../libs/gst/check/libcheck/libcompat.h:167:18: warning: ‘struct itimerspec’ declared inside parameter list will not be visible outside of this definition or declaration
const struct itimerspec *new_value, struct itimerspec *old_value);
^~~~~~~~~~
../libs/gst/check/libcheck/check_run.c:98:25: error: array type has incomplete element type ‘struct sigaction’
static struct sigaction old_action[3];
^~~~~~~~~~
../libs/gst/check/libcheck/check_run.c:99:25: error: array type has incomplete element type ‘struct sigaction’
static struct sigaction new_action[3];
^~~~~~~~~~
[...]
ninja: build stopped: subcommand failed.
The change was originally made because gnu99 was causing issues on OS X.
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
This flag is to indicate to child elements that they can add and
remove pads at any point in time without re-adding existing ones.
Elements should post before-hand a GST_MESSAGE_STREAM_COLLECTION
https://bugzilla.gnome.org/show_bug.cgi?id=772741
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).
gst/gstprintf unit test would fail on 32-bit x86 with:
gstprintf.c:83:printf_I32_I64:0: 'str' (64-bit x value = b5a6978f) is not equal to '"64-bit x value = f1e2d3c4b5a6978f"'
This reverts commit cfc565e2d8.
The commit was redundant since gst_gen_sources already contains
gstenum_h. We're still investigating why some people are still seeing
a racy build failure.
This forces gstenumtypes.h to be built whenever something uses gst_dep
as a subproject dependency. This is needed since gst/gst.h includes
gstenumtypes.h
Closes https://github.com/mesonbuild/meson/issues/714 which is not
actually a Meson bug.
This carries over code for a similar test from multiqueue to ensure full
control over the dataflow while testing. (The previous attempt was racy
since the fill level changed without any thread sync with the test code.)
https://bugzilla.gnome.org/show_bug.cgi?id=771210
Earlier we were only using __declspec(dllexport/import) when we were
built with MSVC because when built with MinGW and linking with MinGW we
don't need it (and we get linker errors because of it).
However, when we're built with MinGW and someone wants to link to us
with MSVC, we still need the prototypes to have __declspec(dllimport)
since MSVC cannot do auto-import like GCC can.
https://bugzilla.gnome.org/show_bug.cgi?id=771029
