GNOME Bugzilla – Bug 589663
gstreamer asserts in gstaudiofilter
Last modified: 2009-07-30 13:34:44 UTC
Hi, aMSN uses gstreamer/farsight for audio/video calls and it looks like gstreamer contains an assert that shouldn't be there... In the following program, I dynamically link elements when the pipeline is running and my 'volume' element gets as input caps "audio/x-raw-int,width=8,depth=8,rate=44100,signed=true,channels=1" but in it's output caps it has 'endianness=1234' added.. this is caused by osssrc that has the endianness missing for the 'width=8,depth=8,...' caps. In gst_audio_filter_set_caps, there's an assert on gst_caps_equal(incaps, outcaps). First, osssrc should add the endianness for its width/depth=8 caps, but also the assert in gstaudiofilter.c should either be removed or should be on gst_caps_interest, not on gst_caps_equal... Here's the small python code that reproduces the error (same as my C app), as well as the assertion error I get and the backtrace. -------------- example code ------------------- #!/usr/bin/python import gst, time p = gst.parse_launch("osssrc ! audio/x-raw-int, width=8 ! valve name=v drop=true") p.set_state(gst.STATE_PLAYING) time.sleep(1) v = p.get_by_name("v") b = gst.parse_bin_from_description("volume ! fakesink", True) p.add(b) v.link(b) p.set_state(gst.STATE_PLAYING) v.set_property("drop", False) time.sleep(1) ----------------------------------------------- ---------------------- output ----------------- ** ERROR:gstaudiofilter.c:168:gst_audio_filter_set_caps: assertion failed: (gst_caps_is_equal (incaps, outcaps)) zsh: abort python bug_gstreamer.py ----------------------------------------------- ------------------- backtrace ----------------- (gdb) bt
+ Trace 216619
Please fix before the next release. Thanks, KaKaRoTo
I think the g_assert() is just wrong in this case, since the caps have to be compatible, not necessarily equal.
Created attachment 139420 [details] [review] audiofilter.diff This patch does what you suggested and IMHO that makes absolutely sense. I'll push it after 0.10.24 release and close this bug now.
This patch wont work, you shouldn't assert at all. Anyway, gst_caps_is_always_compatible won't work here. Because the output caps are more restrictive than the input caps. It should try setting the caps downwards and let it fail. Also, Youness is not happy because it breaks his aMsn stuff with osssrc (so he'd like for that assert to not be in 0.10.24)
Why doesn't it work here? incaps is a subset of outcaps (they are the same except that outcaps has the additional endianness field, which shouldn't be there for 8 bit anyway btw). If there should be an assertion or not should be discussed though. I've talked with ds about this 1-2 years ago and the reason why he added it was, that audio filters by definition are working on one format and don't convert it to something else. I agree that in that context the is_equal() is wrong but is_always_compatible() would be the correct thing to do (in/outcaps must describe the same format but outcaps can be more specific, i.e. can have more fields). What do you think? Shall we remove the assertion (and the informat==outformat restriction) from audiofilter?
Created attachment 139495 [details] [review] audiofilter: Don't assert on slightly different caps Plugins should not assert on incompatible caps, caps negotiation will fail anyway.
Jan, can we get this one in before 0.10.24 ?
please commit, and I'll make a new pre-release
Applied and pushed, thanks