advanced-dataaccess.xml:1210: element listitem: validity error : Element
listitem content does not follow the DTD, expecting (...),
got (para CDATA para )
</listitem>
Currently the .la path is provided which requires to use libtool as
mentioned in the GStreamer manual section-helloworld-compilerun.html.
It is fine as long as the application is built using libtool.
So currently it is not possible to compile a GStreamer application
within gst-uninstalled with CMake or other build system different
than autotools.
This patch allows to do the following in gst-uninstalled env:
gcc test.c -o test $(pkg-config --cflags --libs gstreamer-1.0)
Previously it required to prepend libtool --mode=link
https://bugzilla.gnome.org/show_bug.cgi?id=720778
This reverts commit b427997119.
It breaks things that used to work before, even if the change by itself is
correct and the previous code is just working around deeper bugs in the async
state change code. Let's go back to what previously worked and then fix async
state changes in general.
https://bugzilla.gnome.org/show_bug.cgi?id=760532
Showcases the regression introduced by this commit:
Commit: ab55ad7eaa
Author: Stian Selnes <stian@pexip.com>
Date: Wed Jan 27 13:20:23 2016 +0100
ghostpad: Do nothing in _internal_activate_push_default
When calling gst_pad_activate_mode() on a ghostpad
gst_ghost_pad_activate_push_default() will be called. This will call
gst_pad_activate_mode() on the proxypad (which is internal of the
ghostpad), calling gst_ghost_pad_internal_activate_push_default(), which
again will call gst_pad_activate_mode() on the original ghostpad.
By simply returning TRUE in
gst_ghost_pad_internal_activate_push_default() the redundant call to
gst_pad_activate_mode() (for the same pad) is avoided.
https://bugzilla.gnome.org/show_bug.cgi?id=761913
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
When allocating a new buffer in the pool, both the do_alloc_buffer() and the
vmethod, alloc_buffer(), receive the parameter GstBufferPoolAcquireParams.
Nonetheless, when default_acquire_buffer() calls the do_alloc_buffer() it does
not pass the received GstBufferPoolAcquireParams, so when the user pass those
parameters they are ignored by alloc_buffer() vmethod.
This one-liner patch pass the received acquire params to do_alloc_buffer().
https://bugzilla.gnome.org/show_bug.cgi?id=761824
Fixes a race where an entry is set to BUSY in
gst_system_clock_id_wait_jitter() and is UNSCHEDULED before
gst_system_clock_id_wait_jitter_unlocked() starts processing it. The
wakeup added by gst_system_clock_id_unschedule() must be cleaned up.
Two stress tests are added. One test that triggers the specific issue
described above. The second stresses the code path where a wait is
rescheduled because the poll returned early.
https://bugzilla.gnome.org/show_bug.cgi?id=761586
If the clockentry is too late and is unscheduled before it gets
a change to detect its lateness the wakeup count and the poll are
used but never properly cleaned up. This leaves it in a dirty state
that is going to mess with the next clock entry waiting requests.
https://bugzilla.gnome.org/show_bug.cgi?id=761586
