GNOME Bugzilla – Bug 584945
camerabin unit tests failing
Last modified: 2009-06-26 18:10:07 UTC
Since the camerabin changes yesterday, the unit tests are failing, on the buildbots and on my local machine. For example: http://build.gstreamer.org:8010/builders/g64~-bad-fast/builds/192/steps/make-check/logs/stdio Needs fixing before we release, since I can't distcheck with failing tests.
A couple of information about that buildslave: configure: *** checking feature: METADATA muxer and demuxer *** configure: *** for plug-ins: metadata *** checking for EXIF... yes checking for IPTC... no checking for XMP... no checking for XMP_1_99_5... no no configure: *** These plugins will be built: metadata Whereas that test runs fine on my other home computer (same architecture, same distro) which as an extra library: configure: *** checking feature: METADATA muxer and demuxer *** configure: *** for plug-ins: metadata *** checking for EXIF... yes checking for IPTC... no checking for XMP... yes checking for XMP_1_99_5... yes configure: *** These plugins will be built: metadata I'm not 100% sure this is why the test is failing... but all the other buildslaves which pass that test successfully have got XMP installed. Either we *require* XMP ... or the code/test needs to be modified accordingly.
And that's indeed the cause of the problems. the title tag requires the XMP backend to be rendered. Here's a simple fix: diff --git a/tests/check/pipelines/metadata.c b/tests/check/pipelines/metadata.c index a632df4..383f849 100644 --- a/tests/check/pipelines/metadata.c +++ b/tests/check/pipelines/metadata.c @@ -190,7 +190,9 @@ test_tags (const gchar * tag_str) GST_START_TEST (test_common_tags) { +#if HAVE_XMP test_tags ("taglist,title=\"test image\""); +#endif } GST_END_TEST; On another matter... it would be good to have some programatic feedback on whether a tag was properly accepted or not... it would avoid this kind of ugly hack.
commit 34100ce1c702207c12d5e339d668572b06778d6c Author: Edward Hervey <bilboed@bilboed.com> Date: Sun Jun 7 10:55:59 2009 +0200 tests/metadata: Don't try tags we can't handle. Fixes #584945
*** Bug 585144 has been marked as a duplicate of this bug. ***
Still broken in today's git.
Gotz, could you be more explicit ? What fails exactly ?
Êdward, read bug #585144.
Since I'm not a lazy bugger, here's the failing test : This is with latest git of gst-plugins-bad on Mandriva Cooker: $ make check check_PROGRAMS=elements/camerabin 2>check.log Running suite(s): camerabin 40%: Checks: 5, Failures: 0, Errors: 3 elements/camerabin.c:371:E:general:test_single_image_capture:0: (after this point) Test timeout expired elements/camerabin.c:391:E:general:test_video_recording:0: (after this point) Test timeout expired elements/camerabin.c:408:E:general:test_image_video_cycle:0: (after this point) Test timeout expired FAIL: elements/camerabin This happens on several machines/arch/distros
Lets disable the test for the release. I'll have it fixed by the end of the week. I'll already added a lot of debugging which is good foor later sessions and I have a hunch where it hangs, but don't know why yet.
Created attachment 136395 [details] [review] 1/3
Created attachment 136396 [details] [review] 2/3
Created attachment 136397 [details] [review] 3/3 One test is still racy "test_image_video_cycle". I'll see if I can find a fix for it too, but if we want to make the release I'd be fine with disabling the test. I alos have a lot of code-cleanups for camerabin, but those can be committed after the release.
Created attachment 136398 [details] [review] 3/3 also add Makefile.am cleanups
Created attachment 136413 [details] [review] 3/3 In addition to the previous one, this now correctly request low res and low fps to avoid test timing out due to video encoding.
These generally seem OK, although I'm not sure if there are wider implications to making outputselector always accept incoming buffer alloc requests even when no output pad is (yet) selected. Even if that's OK, it's probably simpler to implement by changing the ret = GST_FLOW_NOT_LINKED to ret = GST_FLOW_OK and returning a null output buffer? That way the core will do the fallback allocation for us. Otherwise the patches seem OK
Created attachment 136436 [details] [review] 1/3 I did not know that *buf=NULL would trigger a default fallback alloc. But it works and is better to avoid code duplication. Thanks.
One test is still racy :/ Unexpected critical/warning: Changing the `location' property on filesink when a file is open is not supported. 80%: Checks: 5, Failures: 1, Errors: 0 gstcheck.c:72:F:general:test_image_video_cycle:0: Unexpected critical/warning: Changing the `location' property on filesink when a file is open is not supported. Shall I disable it for now?
I also get issues with caps on thsi system now: 0:00:04.233123948 5070 0x8266a00 WARN basetransform gstbasetransform.c:1047:gst_base_transform_acceptcaps:<volume0> transform could not transform audio/x-raw-float, endianness=(int)1234, width=(int)64, rate=(int)44100, channels=(int)1 in anything we support 0:00:04.241041951 5070 0x8212840 WARN basetransform gstbasetransform.c:1047:gst_base_transform_acceptcaps:<volume0> transform could not transform audio/x-raw-float, endianness=(int)1234, width=(int)64, rate=(int)44100, channels=(int)1 in anything we support 0:00:04.273415675 5070 0x82669d8 WARN basetransform gstbasetransform.c:1047:gst_base_transform_acceptcaps:<capsfilter0> transform could not transform video/x-raw-yuv, format=(fourcc)YUY2, width=(int)320, height=(int)240, framerate=(fraction)5/1 in anything we support 0:00:04.279899806 5070 0x82669d8 WARN basetransform gstbasetransform.c:1047:gst_base_transform_acceptcaps:<capsfilter0> transform could not transform video/x-raw-yuv, format=(fourcc)YUY2, width=(int)320, height=(int)240, framerate=(fraction)5/1 in anything we support
Created attachment 136732 [details] [review] reset filename to fix racyness uncovered by one test Wth this patch supplied the camerabin tests pass make check nice -19 make check make valgrind (for me \o/)
Looks good, please commit and I'll make a new pre-release later
OK, committed