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%
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.
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.
If downstream returns error and upstream has already delivered
everything (including EOS) and will no longer be around to find
out that we paused (and why), post error message. Fixes#589991.
When we have an input buffer with caps and when those caps are different from
the caps we want, only then make a writable copy of the input buffer as the
output buffer and set the caps on that output buffer. This avoids some cases
where we took a subbuffer for setting caps that were the same.
Users should never see the term 'file descriptor', much less a file
descriptor number, in an error message. Put that into the debug
string instead and use the default error message.
The compiler suggests to add some () to indicate if the && or the || takes
priority, so reflow code a bit so we don't have to add yet another layer
of (). Hopefully this was the intended meaning of the code.
When min-threshold is set on a queue, it is possible that one of
the minima remains unsatisfied while one of the maxima is already
reached. Therefore, always consider the queue non-empty if it is full.
Fixes#585433.
Out-of-band events might lead to us calling g_object_notify() from a
non-streaming thread, which can cause crashes if g_object_notify() is
being called from the streaming thread at the same time. See #554460.
GObject may crash if two threads do concurrent g_object_notify() on the same
object. This may happen if fakesink receives an out-of-band event such as
FLUSH_START while processing a buffer or serialised event in the streaming
thread. Since this may happen with the default settings during a common
operation like a seek, and there seems to be little chance of a timely fix
in GObject (see #166020), we should hack around this issue by protecting all
of fakesink's direct g_object_notify() calls with a lock.
Also add unit test for the above.
Fixes#554460.
