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 589663 - gstreamer asserts in gstaudiofilter
gstreamer asserts in gstaudiofilter
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.23
Other Linux
: Normal blocker
: 0.10.24
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-07-25 02:16 UTC by Youness Alaoui
Modified: 2009-07-30 13:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
audiofilter.diff (754 bytes, patch)
2009-07-28 19:54 UTC, Sebastian Dröge (slomo)
committed Details | Review
audiofilter: Don't assert on slightly different caps (949 bytes, patch)
2009-07-29 18:21 UTC, Olivier Crête
committed Details | Review

Description Youness Alaoui 2009-07-25 02:16:53 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
  • #0 __kernel_vsyscall
  • #1 raise
    from /lib/i686/cmov/libc.so.6
  • #2 abort
    from /lib/i686/cmov/libc.so.6
  • #3 IA__g_assertion_message
  • #4 IA__g_assertion_message_expr
  • #5 gst_audio_filter_set_caps
    at gstaudiofilter.c line 168
  • #6 gst_base_transform_configure_caps
    at gstbasetransform.c line 694
  • #7 gst_base_transform_setcaps
    at gstbasetransform.c line 1107
  • #8 gst_pad_set_caps
    at gstpad.c line 2506
  • #9 gst_proxy_pad_do_setcaps
    at gstghostpad.c line 305
  • #10 gst_pad_set_caps
    at gstpad.c line 2506
  • #11 gst_pad_configure_sink
    at gstpad.c line 2560
  • #12 gst_pad_chain_unchecked
    at gstpad.c line 3962
  • #13 gst_pad_push
    at gstpad.c line 4144
  • #14 gst_valve_chain
    at gstvalve.c line 214
  • #15 gst_pad_chain_unchecked
    at gstpad.c line 3977
  • #16 gst_pad_push
    at gstpad.c line 4144
  • #17 gst_base_transform_chain
    at gstbasetransform.c line 2038
  • #18 gst_pad_chain_unchecked
    at gstpad.c line 3977
  • #19 gst_pad_push
    at gstpad.c line 4144
  • #20 gst_base_src_loop
    at gstbasesrc.c line 2279
  • #21 gst_task_func
    at gsttask.c line 172
  • #22 g_thread_pool_thread_proxy
    at /build/buildd-glib2.0_2.20.4-1-i386-6KfM1O/glib2.0-2.20.4/glib/gthreadpool.c line 265
  • #23 g_thread_create_proxy
    at /build/buildd-glib2.0_2.20.4-1-i386-6KfM1O/glib2.0-2.20.4/glib/gthread.c line 635
  • #24 start_thread
    from /lib/i686/cmov/libpthread.so.0
  • #25 clone
    from /lib/i686/cmov/libc.so.6

Please fix before the next release.

Thanks,
KaKaRoTo
Comment 1 Olivier Crête 2009-07-25 16:55:51 UTC
I think the g_assert() is just wrong in this case, since the caps have to be compatible, not necessarily equal.
Comment 2 Sebastian Dröge (slomo) 2009-07-28 19:54:05 UTC
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.
Comment 3 Olivier Crête 2009-07-28 21:34:54 UTC
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)
Comment 4 Sebastian Dröge (slomo) 2009-07-29 05:38:10 UTC
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?
Comment 5 Olivier Crête 2009-07-29 18:21:32 UTC
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.
Comment 6 Olivier Crête 2009-07-29 18:22:54 UTC
Jan, can we get this one in before 0.10.24 ?
Comment 7 Jan Schmidt 2009-07-30 08:45:57 UTC
please commit, and I'll make a new pre-release
Comment 8 Jan Schmidt 2009-07-30 13:34:44 UTC
Applied and pushed, thanks