Everyone running an uninstalled git setup is going to wonder about
this failure next time they update, so let's mention the solution
in the error message.
We know earlier on in the code whether we're handling an event or a buffer,
just pass that information through.
This commit and the previous commit reduce instruction fetch:
* when pushing buffer (_chain) by 10%
* when popping buffer (_loop) by 3%
Reflow the code to move error handling to the end of the functions. Initialize
gvalue like we do in the setter. Add a unit-test module with two simple tests
the catche this bug.
The task will always exist as long as its owner (i.e. the pad) and that
owner's owner (i.e. multiqueue) exist.
Reduces the number of instruction fetches by 36%.
We know whether we have a buffer or an event, use that instead of going
trough the expensive GLib typecheck.
The overall instruction fetch reduction introduced by this commit and the
2 previous commits:
* receiving a buffer (_chain) by 20%
* popping a buffer (_loop) by 14%
Numbers acquired through callgrind passing 100000 buffers through queue.
Init variable to avoid compiler warning and make the build bot happy
(the compiler most likely complains about this because it doesn't know
here that fail_unless will abort/exit in the path where it fails).
Pads have their GstSingleQueue stored as element private data
so there's no need to iterate over the list of single queues
every time. Also every pad only has a single internal link so
use a single iterator instead of a complex custom iterator.
Set the element private data of the pad to NULL when freeing the
single queue.
We don't need the hold the proxy mutex locked for getting the internal pad and
for linking the new target pad when we retarget. So take the lock a little later
and release it earlier.
Fixes#596366
Init variable to avoid compiler warning and make the build bot happy
(the compiler most likely complains about this because it doesn't know
here that fail_unless will abort/exit in the path where it fails).
Guard against a hostile child process that sends bogus data
due to memory corruption by adding a magic number to each packet,
and limit the maximum size of any message to 32MB
When trying to find a function plugin-scanner, include a check on the
version of the binary registry chunks it sends, to make sure it's
what we understand.
Add a simple version check when starting the plugin-scanner so we can
verify we're talking to one that talks the same language.
First try a plugin-scanner in the installed path, then try one via the
GST_PLUGIN_SCANNER env var if that doesn't work.
Update the uninstalled script.
Install the plugin-scanner to the libexec dir
When updating the registry, we don't need to re-read the registry cache
and waste time replacing all our existing, hopefully identical, plugins
and features that we're about to re-scan anyway.
phase 2 - make the plugin loader receive the list of plugins to load and
send back the results asynchronously, so we don't context switch back
and forth so much.
