Add support for buffering mode where we post BUFFERING messages based on the
level of the queues. It currently operates on the first queue that goes over or
under the high/low thresholds.
In buffering mode we want to ignore the max visible items to decide when the
queue is filled. Instead, we only look at the number of bytes and/or time in the
queue.
Don't shadow the sq argument in the underrun_cb function but use
a different variable name to iterate the other queues.
Use the same variable name in the overrun_cb function.
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%.
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.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c:
* plugins/elements/gstmultiqueue.h:
revert extra-size-buffers stuff, caused some race conditions
and extra-size-buffers is not used anymore. Docs needs some updates
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c:
Don't update the cur_time on GST_CLOCK_TIME_NONE (#537804) and don't
activate the pads if they are added in STATE_NULL.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c:
Add documentation for the signals to push our core plugin docs
coverage back up to 100%.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c: (single_queue_overrun_cb),
(single_queue_underrun_cb):
When trying to make room in the queue, bump the max allowed buffers
bigger than the current amount of buffers in the queue. this fixes some
nasty deadlocks in multiqueue when dynamically changing the limits of
the queue.
Original commit message from CVS:
* docs/design/part-synchronisation.txt:
Update some docs.
* docs/plugins/Makefile.am:
* docs/plugins/gstreamer-plugins-docs.sgml:
* docs/plugins/gstreamer-plugins-sections.txt:
* plugins/elements/gstmultiqueue.c:
Add multiqueue to the docs.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c: (gst_multi_queue_set_property),
(gst_multi_queue_request_new_pad), (gst_single_queue_flush),
(gst_multi_queue_loop), (gst_multi_queue_sink_activate_push):
Make it so that pads are considered linked until a buffer is pushed
and discovered otherwise. This avoids problems with decodebin2 hanging
after a seek in the filesrc ! decodebin2 name=d ! fakesink d. ! fakesink
case.
Make sure we lock the multiqueue when updating the max-size properties.
Fix a crash on Solaris in a debug statement in get_request_pad that
passes a NULL string to GST_DEBUG.
* tests/check/elements/multiqueue.c: (mq_dummypad_chain),
(run_output_order_test):
Fix the test to allow the first buffer on not-linked pads to come out
of sequence while multiqueue discovers that they are not-linked.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c: (gst_single_queue_push_one),
(gst_single_queue_new):
* plugins/elements/gstqueue.c: (gst_queue_init),
(gst_queue_push_one):
Fix queue negotiation. If acceptcaps unconditionally returns TRUE,
upstream is tricked into thinking it can suggest a format downstream
while downstream does not support that format. The real problem is that
core calls acceptcaps when pushing a buffer with new caps, for which we
do a little workaround by setting the caps on the srcpad ourselves
before pushing the buffer (until this is figured out). Fixes#486758.
Original commit message from CVS:
Patch by: Mark Nauwelaerts <manauw at skynet be>
* plugins/elements/gstmultiqueue.c:
(gst_multi_queue_get_internal_links), (apply_buffer),
(single_queue_overrun_cb), (gst_single_queue_new):
Implement non-default GstPadIntLinkFunction for multiqueue pads so that
the pipeline layout can be tracked correctly. Fixes#453732.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c: (apply_buffer),
(single_queue_overrun_cb):
When figuring out when a queue is filled, use our internal time estimate
based on segments, just like check_full does.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c: (gst_multi_queue_init),
(gst_single_queue_flush), (apply_segment), (apply_buffer),
(gst_single_queue_push_one), (gst_multi_queue_loop),
(gst_multi_queue_sink_activate_push), (gst_multi_queue_sink_event),
(gst_multi_queue_src_activate_push), (wake_up_next_non_linked),
(compute_high_id), (gst_single_queue_new):
* plugins/elements/gstmultiqueue.h:
Take the multiqueue lock when updating the fill level so we don't get
confused.
After applying a buffer or event on the src pad segment, make sure to
call gst_data_queue_limits_changed() to get the data queue to unblock
and check the filled state again.
Rework the not-linked pad handling so the logic is that not-linked
pads can push as fast as they like, but only so they never get
ahead of any linked pads.
* tests/check/elements/multiqueue.c: (mq_sinkpad_to_srcpad),
(mq_dummypad_getcaps), (mq_dummypad_chain), (mq_dummypad_event),
(run_output_order_test), (GST_START_TEST), (multiqueue_suite):
Add a test to check that not-linked pads always stay behind
linked pads.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c: (apply_buffer),
(gst_single_queue_push_one), (gst_multi_queue_chain),
(gst_multi_queue_sink_event):
Make sure we don't reference the buffer/event after we have given away
ownership in the queue.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c: (gst_single_queue_flush),
(gst_multi_queue_chain), (gst_multi_queue_sink_event):
Update queue state _after_ adding the item in the queue because else we
could end up being full without the element added yet.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c: (gst_multi_queue_item_destroy),
(gst_multi_queue_item_new):
Don't use GSlice because we don't depend on >= 2.10 yet.
