GNOME Bugzilla – Bug 742098
rtp: Fails rtpaux and rtpcollision tests
Last modified: 2014-12-30 17:25:28 UTC
Created attachment 293455 [details] test suite report Unexpected critical/warning: gst_element_link_pads_full: assertion 'GST_IS_ELEMENT (dest)' failed during test runs for rtpaux and rtpcollision tests for gst-plugins-good-1.4.5 build. Happens both before and after system has 1.4.5 (so does not appear to be an issue of wrongly using system plugins/libs) Considering this a blocker on my end, until it is known this has no actual ill effect to real programs (i.e, a test code issue, not rtp or other gstreamer plugins issue). There's a simple-pipeline failure too, but that might have something to do with jpeg being split out on my end in this case. So not bothering you with that until I analyze that angle for that test. Can test and analyze further another day (like making sure which element is failing creation to fail the assert), so filing meanwhile in case someone has a quick idea meanwhile.
It's an expected failure, marked as failure, in case --disable-speex is passed. Could the test be passed in case speex element isn't seen, or use a different element without its own --enable flag (and external dep)?
(In reply to comment #1) > Could the test be passed in case speex element isn't seen, or use a different > element without its own --enable flag (and external dep)? whoops, I mean could the test be SKIPPED in case it isn't seen, or use a diff element
The rtpaux test is known to be a bit flaky, but I don't think this is what you're hitting here. It seems it's just relying unconditionally on being able to create speexenc/dec. I don't know why this would be a 'blocker' for you in any case; even if the tests showed a real bug it's not much different from any of the other confirmed bugs that sit in bugzilla really. And I don't think it's a regression from 1.4.4, is it?
I didn't have 1.4.4, it's an upgrade from 1.2.5 or something. The problem probably started whenever the test started to use speex plugin. Test fails when gst-plugins-good is built with --disable-speex and system plugins are (for a good reason) hidden from its view. That test should then see that speex is disabled and disable the test or subtest, or perhaps use something else that doesn't need speex. Kind-of blocker as our users can choose to build and execute tests as well, and they are expected to work then. If they are known not to work, I would have to preferably fix them, patch those tests to not be ran, or as a last resort restrict all tests running in the package. But given how it fails with --disable-speex for everyone, not just me and my "weird" source level package splitting, something should be done here; I can just figure some workaround meanwhile at distro level though and "unblock". Note that I didn't mark this upstream at blocker severity ;)
Created attachment 293483 [details] [review] tests: rtp: Don't run tests requiring speex plugins when speex is disabled
Tim already fixed that a while ago but forgot to update the bug. Sorry! http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=d416336a6e9c92a61c59276f6aed8f1e821a142d
I left the bug open because I only changed the rtpaux test. With the rtpcollision test something else needs changing beside the element names which I haven't looked at yet.
commit d67da4c8ae76320914016fd46acfef82298dba2c Author: Tim-Philipp Müller <tim@centricular.com> Date: Tue Dec 30 17:19:42 2014 +0000 tests: rtpcollision: use alawenc/dec in these tests instead of Speex They should always be built, while the speex elements are not. Need to check for a smaller number of buffers then (7->4) because speexenc will add 3 header buffers while alawenc will just output as many buffers as it receives as input. https://bugzilla.gnome.org/show_bug.cgi?id=742098