Edward Hervey 3537ad8ae1 check: Disable multiqueue test_output_order check ... The check itself is racy. (CK_FORK=no GST_CHECK=test_output_order make elements/multiqueue.forever). The problem is indeed the test and not the actual element behaviour. The objects to push are being pulled out of the single internal queues in the right order and at the right time... But between: * the moment the global multiqueue lock is released (which was used to detect if we should pop and push downstream the next buffer) * and the moment it is received by the source pad (which does the check) => another single queue (like the unlinked pad) might pop and push a buffer downstream What should we do ? Putting a bigger margin of error (say 5 buffers) doesn't help, it'll eventually fail. I can't see how we can detect this reliably. https://bugzilla.gnome.org/show_bug.cgi?id=708661		2013-10-02 11:26:09 +02:00
..
elements	check: Disable multiqueue test_output_order check	2013-10-02 11:26:09 +02:00
generic	check: fix position unit test	2013-05-30 07:03:40 +02:00
gst	value: fix caps serialization when there are caps inside caps	2013-09-30 16:20:48 -03:00
libs	tests: handle unscheduled entries correctly	2013-09-23 11:47:14 +02:00
pipelines	typefind: fix caps leak when used in connection with uridecodebin and playbin	2013-04-27 00:05:45 +01:00
tools	Fix FSF address	2012-11-03 20:44:48 +00:00
.gitignore	tests: add check for gst-inspect --exists functionality	2012-09-01 23:02:10 +01:00
Makefile.am	context: Add unit test for GstContext	2013-04-17 12:44:29 +02:00