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 576322 - [basetransform] doesn't fixate non-fixated suggested caps
[basetransform] doesn't fixate non-fixated suggested caps
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.22
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-22 19:54 UTC by Aren Olson
Modified: 2012-09-27 23:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
last few lines of log and stack trace of warning (13.75 KB, text/x-log)
2009-06-11 22:12 UTC, Tim-Philipp Müller
Details
python test program (1.70 KB, text/x-python)
2009-06-11 22:12 UTC, Tim-Philipp Müller
Details

Description Aren Olson 2009-03-22 19:54:46 UTC
I'm using capsfilter and audioresample to force the sample rate in my pipeline. However, when I try to change the sample rate while the pipeline is running, by setting a new caps on the capsfilter, it does not change, and outputs a lot of the following message instead:

** (sample.py:31086): CRITICAL **: gst_base_transform_find_transform: assertion `gst_caps_is_fixed (caps)' failed


Some sample code (in pygst) that replicates the problem may be found here: http://pastebin.ca/1368322
Comment 1 Sebastian Dröge (slomo) 2009-03-23 09:33:48 UTC
You must set fixed caps on the capsfilter. The second caps are not fixed as they contain two different structures (one for float, one for int).

Not sure if this is a bug in capsfilter (it doesn't check the caps and doesn't truncate them) or in basetransform (it doesn't handle non-fixed suggestion caps).
Comment 2 Aren Olson 2009-03-23 20:31:52 UTC
Alright, I changed them to fixed caps, and now it appears to give correct audio output but in the debug output it continually prints

0:00:26.052693439  8383      0x2cd13e0 WARN         basetransform gstbasetransform.c:1037:gst_base_transform_acceptcaps:<audioconvert0> transform could not transform audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)8000, channels=(int)2 in anything we support (othercaps (NULL))


In addition, if I make this change in my larger program, it shows that when the caps are reset the uridecodebin fires a drained signal, which is undesirable as that is how I know that stream is ended and can be discarded. When setting the caps in this case, the following appears in the debug output:

0:00:54.515690671  8349      0x2e88d00 WARN         basetransform gstbasetransform.c:1037:gst_base_transform_acceptcaps:<identity2> transform could not transform audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)8000, channels=(int)2 in anything we support (othercaps (NULL))
0:00:54.516985807  8349      0x2e88d00 WARN         basetransform gstbasetransform.c:1037:gst_base_transform_acceptcaps:<audioconvert0> transform could not transform audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)8000, channels=(int)2 in anything we support (othercaps (NULL))
0:00:54.520743268  8349      0x2e88d00 WARN         basetransform gstbasetransform.c:1037:gst_base_transform_acceptcaps:<identity2> transform could not transform audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)8000, channels=(int)2 in anything we support (othercaps (NULL))
0:00:54.522018849  8349      0x2e88d00 WARN         basetransform gstbasetransform.c:1037:gst_base_transform_acceptcaps:<audioconvert0> transform could not transform audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)8000, channels=(int)2 in anything we support (othercaps (NULL))
0:00:54.525576565  8349      0x2e88d00 WARN         basetransform gstbasetransform.c:1037:gst_base_transform_acceptcaps:<identity2> transform could not transform audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)8000, channels=(int)2 in anything we support (othercaps (NULL))
0:00:54.530959442  8349      0x2e88d00 WARN         basetransform gstbasetransform.c:1037:gst_base_transform_acceptcaps:<capsfilter0> transform could not transform audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)8000, channels=(int)2 in anything we support (othercaps (NULL))
0:00:54.531053448  8349      0x2e88d00 INFO               basesrc gstbasesrc.c:2278:gst_base_src_loop:<source> pausing after gst_pad_push() = not-negotiated
0:00:54.531149620  8349      0x2e88d00 WARN               basesrc gstbasesrc.c:2330:gst_base_src_loop:<source> error: Internal data flow error.
0:00:54.531182097  8349      0x2e88d00 WARN               basesrc gstbasesrc.c:2330:gst_base_src_loop:<source> error: streaming task paused, reason not-negotiated (-4)
0:00:54.531258433  8349      0x2e88d00 INFO      GST_ERROR_SYSTEM gstelement.c:1675:gst_element_message_full:<source> posting message: Internal data flow error.
0:00:54.531493379  8349      0x2e88d00 INFO      GST_ERROR_SYSTEM gstelement.c:1698:gst_element_message_full:<source> posted error message: Internal data flow error.
0:00:54.531557214  8349      0x2e88d00 INFO              GST_PADS gstpad.c:3235:gst_pad_event_default_dispatch:<id3demux0:sink> Sending event 0x18e42c0 (eos) to all internally linked pads


My debug level is GST_DEBUG=*:3,GST_STATES:0, and the fixed caps are "audio/x-raw-int, rate=(int)44100" and "audio/x-raw-int, rate=(int)8000".  Let me know if you require any additional information.
Comment 3 Tim-Philipp Müller 2009-03-23 21:13:09 UTC
Unfixed caps should be allowed as filter caps, shouldn't it? 
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2009-03-27 20:17:59 UTC
I can also confirm what tim said. Unfixed caps should (and for me) work fine. I once had the problem that the caps I set on caps filter were constrained too much and it resulted in warnings a bit unrelated at first. It looked like what you have in comment #2. Othercaps are NULL. I would suggest to dump a pipeline graph and look at the caps. Put a GST_DEBUG_BIN_TO_DOT_FILE_WITH_TS into your pipeline bus error handler and run the app using GST_DEBUG_DUMP_DOT_DIR=$PWD ./myapp
Convert the dot files to pngs (dot -Tpng -oimage.png graph_lowlevel.dot) and check the caps beein set on the pad-links.
Comment 5 Tim-Philipp Müller 2009-06-11 22:03:21 UTC
Looks to me like either a bug in basetransform or in capsfilter:

 - if it's supposed to be ok to pass non-simple/unfixed
   caps to gst_base_transform_suggest(), then it's a bug
   in basetransform, as it doesn't fixate the caps somewhere

 - if it's not supposed to be ok to pass non-simple/unfixed
   caps to gst_base_transform_suggest(), then it looks like
   primarily a bug in capsfilter, and there should be an
   g_return_if_fail() guarding gst_base_transform_suggest()
Comment 6 Tim-Philipp Müller 2009-06-11 22:12:25 UTC
Created attachment 136370 [details]
last few lines of log and stack trace of warning
Comment 7 Tim-Philipp Müller 2009-06-11 22:12:57 UTC
Created attachment 136371 [details]
python test program
Comment 8 Tim-Philipp Müller 2012-09-27 23:11:53 UTC
This seems to have been fixed somewhere in the last three years, closing. Please re-open if there's still an issue.