After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 742098 - rtp: Fails rtpaux and rtpcollision tests
rtp: Fails rtpaux and rtpcollision tests
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.4.5
Other Linux
: Normal minor
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-12-29 21:43 UTC by Mart Raudsepp
Modified: 2014-12-30 17:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test suite report (2.01 KB, text/plain)
2014-12-29 21:43 UTC, Mart Raudsepp
  Details
tests: rtp: Don't run tests requiring speex plugins when speex is disabled (932 bytes, patch)
2014-12-30 16:04 UTC, Mart Raudsepp
none Details | Review

Description Mart Raudsepp 2014-12-29 21:43:37 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.
Comment 1 Mart Raudsepp 2014-12-29 22:01:02 UTC
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)?
Comment 2 Mart Raudsepp 2014-12-29 22:02:45 UTC
(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
Comment 3 Tim-Philipp Müller 2014-12-30 10:52:47 UTC
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?
Comment 4 Mart Raudsepp 2014-12-30 11:13:43 UTC
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 ;)
Comment 5 Mart Raudsepp 2014-12-30 16:04:12 UTC
Created attachment 293483 [details] [review]
tests: rtp: Don't run tests requiring speex plugins when speex is disabled
Comment 6 Sebastian Dröge (slomo) 2014-12-30 16:09:39 UTC
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
Comment 7 Tim-Philipp Müller 2014-12-30 16:15:01 UTC
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.
Comment 8 Tim-Philipp Müller 2014-12-30 17:25:28 UTC
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