gst_harness_new_parse() returns without any error even if it doesn't
find the specified element. Then a succeeding call to
gst_harness_set_sink_caps_str() causes an error like this:
Unexpected critical/warning: gst_pad_push_event: assertion 'GST_IS_PAD (pad)' failed
This is a bit cryptic and doesn't give users any clue what was going
on.
gst_harness_new_parse() calls gst_harness_add_parse() with a newly
created empty harness and the given pipeline description string, but
gst_harness_add_parse() does not have a way to propagate the error
back to the caller. Since the function, gst_harness_add_parse(), is a
public API, it's not a good idea to change its signature. This patch,
instead, makes the function to g_error() when it discovers any error.
With this change the same error prints:
** (myelement-test:25345): ERROR **: Unable to create pipeline 'bin.( myelement )': no element "myelement"
The current implementation of gst_parse_launch_full() doesn't return
partially constructed pipeline when GST_PARSE_FLAG_FATAL_ERRORS is
specified, however, this patch also adds a check for it.
https://bugzilla.gnome.org/show_bug.cgi?id=781958
New API functions to filter log messages before they are processed by
GstCheck. This can be used to discard specific messages that are
accepted by the test or to add callbacks that test specific messages.
Default bevavior when no callback is given to a filter is to discard the
message, because it does not makes sense to have a filter with no
callback which does not discard; that would be a noop.
Discarded messages will in addition to bypass the GstCheck handling also
return to GLib that the message is not fatal if it occurs.
https://bugzilla.gnome.org/show_bug.cgi?id=773091
When malloc is not available, this will set #define malloc rpl_malloc
which is implemented only inside libcheck, and not everything will link
to libcheck.
We don't really need to care too much about how malloc is implemented
and we don't care about platforms that don't implement malloc.
This brings us up-to-speed with the latest compatibility code from upstream
check git. For completeness, we do all the checks that upstream check does, but
we skip the snprintf/vsnprintf code because it's not straightforward (involves
running code and that is bad for cross-compilation) and not necessary for the
platforms we support anyway.
If someone really wants this, they can uncomment this and copy the relevant
checks from the check git repository.
https://bugzilla.gnome.org/show_bug.cgi?id=775870
Makes it clearer which files are actually used in libcheck and which are used
for cross-platform compatibility. This is going to be especially useful when we
add all the libcompat fallback code that upstream libcheck has which will add
about 6 new files.
https://bugzilla.gnome.org/show_bug.cgi?id=775870
Upstream seems to have stopped doing releases, but we need to update for better
Windows and Visual Studio support.
This patch only updates the libcheck sources and ignores the compatibility
sources for now.
https://bugzilla.gnome.org/show_bug.cgi?id=775870
Hurd also defines __MACH__, but it does not have mach_absolute_time. Use
the more strict __APPLE__ instead.
Has also been sent upstream: https://github.com/libcheck/check/pull/65
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.
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
To allow the GstTestClock to be used as a GstSystemClock, it is
useful to implement the clock-type property that GstSystemClock
provides. This allows GstTestClock to be used as the system clock
with code that expects a GstSystemClock.
https://bugzilla.gnome.org/show_bug.cgi?id=762147
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
Similar to the stress test functions for buffers that has a callback to
create the buffer to be pushed, it's useful to have functions that use a
callback to create the event to be pushed.
API: gst_harness_stress_push_event_with_cb_start()
API: gst_harness_stress_push_event_with_cb_start_full()
API: gst_harness_stress_send_upstream_event_with_cb_start()
API: gst_harness_stress_push_upstream_event_with_cb_start_full()
https://bugzilla.gnome.org/show_bug.cgi?id=761932
Depending on when gst_harness_pull was called - before the buffer reached
gst_harness_chain or after we can get different behaviors of the test
with enabled blocking push mode. The fix makes the behavior always the
same. In pull function we get the buffer first, thus making sure
gst_harness_chain waits for the signal, and emitting the signal after.
https://bugzilla.gnome.org/show_bug.cgi?id=761931
Set the sink_forward_pad to NULL before tearing down sink_harness to
avoid that the harness tries to forward events/queries to it while it's
tearing down.
https://bugzilla.gnome.org/show_bug.cgi?id=761904
Broke this when I removed the G_GNUC_PRINTF in a previous
commit to fix indentation, since it was not really needed.
Turns out unlike gcc clang warns though if a non-literal
format string is passed then. Fix indentation differently.
http://clang.llvm.org/docs/AttributeReference.html#format-gnu-format
In order for gst_harness_new_full to be MT-safe the increase and
decrease of HARNESS_REF must be MT-safe. This allows for creating
multiple harnesses from different threads wrapping the same element.
https://bugzilla.gnome.org/show_bug.cgi?id=754661
