Commit graph

14 commits

Author SHA1 Message Date
Sebastian Dröge
b44d555865 multiqueue: Don't leak pads in the named pads unit test 2011-04-14 09:07:25 +02:00
Tim-Philipp Müller
0e94961069 tests: fix unusued-but-assigned-variable warnings with gcc 4.6 2011-04-11 15:08:30 +01:00
Sebastian Dröge
8db570f48c multiqueue: Make assignment of queue IDs and pad names threadsafe
Also add a test for naming pads by the caller and return NULL
when requesting an already existing pad.
2011-03-30 10:52:36 +02:00
Jan Schmidt
d38933081e multiqueue test: Remove workaround for pad_task hangs
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.
2011-01-25 16:09:18 +10:00
Jan Schmidt
6d590c65e5 tests: Add a multiqueue sparse streams test 2010-10-27 18:11:35 +02:00
Edward Hervey
5a0cdc7001 tests: Fix multiqueue test for latest commits.
The problem lies in the fact that multiqueue will now operate somewhat
similarly to the flow aggregation logic of demuxers and therefore
will stopp whenever all downstream pads return NOT_LINKED and/or
UNEXPECTED and there's no more buffers to push.

The latest commits should not affect any regular use-case, but the bug
report will be kept open so the previous behaviour can be re-established
if needed.

Fixes #609486
2010-02-10 14:40:17 +01:00
Edward Hervey
9cc47f8cba Revert "multiqueue: handle UNEXPECTED flowreturn better"
This reverts commit fbdf4dceda.

Partly fixes #609274
2010-02-09 15:58:36 +01:00
Wim Taymans
fbdf4dceda multiqueue: handle UNEXPECTED flowreturn better
When we receive an UNEXPECTED flowreturn from downstream, we must not shutdown
the pushing thread because upstream will at some point push an EOS that we still
need to push further downstream.

To achieve this, convert the UNEXPECTED return value to OK. Add a fixme so that
we implement the right logic to propagate the flowreturn upstream at some point.

Also clean up the unit test a little.

Fixes #608136
2010-01-26 17:07:31 +01:00
Wim Taymans
cc8334905c Don't use gst_element_get_pad().
Original commit message from CVS:
* gst/gstpad.c: (gst_pad_load_and_link):
* gst/gstutils.c: (gst_element_link_pads),
(gst_element_unlink_pads):
* libs/gst/check/gstcheck.c: (gst_check_setup_src_pad),
(gst_check_teardown_src_pad), (gst_check_setup_sink_pad),
(gst_check_teardown_sink_pad),
(gst_check_element_push_buffer_list):
* tests/check/elements/fakesink.c: (GST_START_TEST):
* tests/check/elements/filesink.c:
* tests/check/elements/filesrc.c: (GST_START_TEST):
* tests/check/elements/multiqueue.c: (setup_multiqueue),
(mq_sinkpad_to_srcpad):
* tests/check/elements/tee.c: (GST_START_TEST):
* tests/check/generic/sinks.c: (GST_START_TEST):
* tests/check/gst/gstbin.c: (GST_START_TEST):
* tests/check/gst/gstevent.c: (GST_START_TEST):
* tests/check/gst/gstghostpad.c: (GST_START_TEST):
* tests/check/gst/gstpipeline.c: (GST_START_TEST):
* tests/check/gst/gstquery.c: (GST_START_TEST):
* tests/check/gst/gstutils.c: (GST_START_TEST):
* tests/check/libs/basesrc.c: (GST_START_TEST):
* tests/check/pipelines/parse-launch.c: (run_delayed_test),
(gst_parse_test_element_change_state):
Don't use gst_element_get_pad().
2008-05-21 15:57:52 +00:00
Jan Schmidt
f37e97764b plugins/elements/gstmultiqueue.c: Make it so that pads are considered linked until a buffer is pushed and discovered ...
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.
2007-10-25 15:14:02 +00:00
Jan Schmidt
4fb00301dd tests/check/elements/multiqueue.c: Use a GStaticMutex to protect all cases where libcheck fail_if/fail_unless macros ...
Original commit message from CVS:
* tests/check/elements/multiqueue.c: (mq_dummypad_chain),
(mq_dummypad_event), (run_output_order_test):
Use a GStaticMutex to protect all cases where libcheck
fail_if/fail_unless macros might be called from multiple threads
simultaneously to avoid errors like:
"check_pack.c:107: :-1081725400:Bad message type arg"
2007-07-16 16:04:49 +00:00
Jan Schmidt
afebd394fa plugins/elements/gstmultiqueue.*: Take the multiqueue lock when updating the fill level so we don't get confused.
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.
2007-06-26 14:45:15 +00:00
Tim-Philipp Müller
2a3d26e66e Fix multiqueue leaking buffers and events when downstream or the queue are flushing. Make refcounting assumptions exp...
Original commit message from CVS:
* libs/gst/base/gstdataqueue.c:
* libs/gst/base/gstdataqueue.h:
* plugins/elements/gstmultiqueue.c: (gst_single_queue_push_one),
(gst_multi_queue_item_new), (gst_multi_queue_chain),
(gst_multi_queue_sink_event):
* tests/check/elements/multiqueue.c: (multiqueue_suite):
Fix multiqueue leaking buffers and events when downstream or the
queue are flushing. Make refcounting assumptions explicit and
document them (shouldn't break existing code that uses it other than
maybe leak miniobjects, but that already happens anyway). Add unit
test for the most common flushing case. Fixes #423700.
2007-06-06 18:11:10 +00:00
Tim-Philipp Müller
df244cef04 plugins/elements/gstmultiqueue.c: Don't leak GCond.
Original commit message from CVS:
* plugins/elements/gstmultiqueue.c: (gst_single_queue_free):
Don't leak GCond.
* tests/check/Makefile.am:
* tests/check/elements/.cvsignore:
* tests/check/elements/multiqueue.c: (setup_multiqueue),
(GST_START_TEST), (multiqueue_suite):
Add some dead simple unit tests for the 'multiqueue' element
(some bits don't work yet and are disabled for now).
2007-03-28 18:38:11 +00:00