Add a first draft with some ideas and use cases for the implementation
for bufferpools. The purpose is to be able to make elements negotiate
their buffer requirements as well as provide an infrastructure to
preallocate and reuse buffers in an easy way.
Failing to do so in the Windows case (implicitly triggered otherwise)
would have a subsequent _wait return immediately leading to high CPU
usage timeout loops.
Fixes#640675.
Make adding/removing gst_debug_log_default() work reliably in all
circumstances. The problem was that depending on platform and linker
flags the function argument might resolve to different addresses,
which made it impossible to remove the default log function added
in gst_init() from application code (because the pointer values
didn't match). The new approach should keep things simple by passing
NULL for the default function, which the code in libgstreamer can
then handle.
https://bugzilla.gnome.org/show_bug.cgi?id=625396https://bugzilla.gnome.org/show_bug.cgi?id=640771
Makes gst_bus_add_watch(), gst_bus_add_watch_full(), gst_bus_add_signal_watch(),
and gst_bus_add_signal_watch_full() convenience functions automatically pick up
any non-default main contexts set for the current thread via
g_main_thread_push_thread_default().
gstelement.c: In function ‘gst_element_get_request_pad’:
gstelement.c:1052:18: error: variable ‘tmp’ set but not used [-Werror=unused-but-set-variable]
https://bugzilla.gnome.org/show_bug.cgi?id=640850
Once we switch to normal mode, we're not typefinding anymore and thus the caps
will not change. Therefore can avoid the object lock in the data-flow path.
The locking was added in order to fix bug #608877.
Remove code that isn't needed any longer, which sets the multiqueue
to PLAYING and back before unreffing, in order to avoid a deadlock
waiting for gstpad tasks that were never started. The problem seems
to have been fixed long ago.
The description string was changed to an inlined string a while back.
(But: no need to intern the const strings here, we just use the interning
to avoid allocating duplicates and make memory management easier,
since the strings will be around for the life-time of the app anyway).
https://bugzilla.gnome.org/show_bug.cgi?id=640071
So the encoding of the original document is respected and
displays properly in browsers where the encoding autodetection
fails to recognise that it's utf-8.
https://bugzilla.gnome.org/show_bug.cgi?id=639448
This reverts commit 3a59d416af.
Reverting this, as the feature we bumped the requirement for
didn't actually work properly or help with the issue we were
trying to fix (and it was fixed differently in the end).