GNOME Bugzilla – Bug 576234
[basetransform] Suggesting non-fixed caps or no size doesn't work for upstream negotiation
Last modified: 2010-03-16 23:43:20 UTC
Version: 2.26.0 What were you doing when the application crashed? Just a crash while watching move Distribution: Gentoo Base System release 2.0.0 Gnome Release: 2.26.0 2009-03-20 (Gentoo) BugBuddy Version: 2.26.0 System: Linux 2.6.28 #134 SMP PREEMPT Sat Dec 27 13:16:10 EET 2008 x86_64 X Vendor: The X.Org Foundation X Vendor Release: 10503000 Selinux: No Accessibility: Disabled GTK+ Theme: Clearlooks Compact Icon Theme: gnome GTK+ Modules: canberra-gtk-module, gnomebreakpad Memory status: size: 729612288 vsize: 729612288 resident: 122068992 share: 20512768 rss: 122068992 rss_rlim: 18446744073709551615 CPU usage: start_time: 1237667802 rtime: 1266 utime: 1186 stime: 80 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/totem' [Thread debugging using libthread_db enabled] [New Thread 0x7f9897f6a750 (LWP 17769)] [New Thread 0x7f986ffff950 (LWP 17781)] [New Thread 0x7f9874b51950 (LWP 17780)] [New Thread 0x7f9875352950 (LWP 17779)] [New Thread 0x7f98761a0950 (LWP 17778)] [New Thread 0x7f9876ffd950 (LWP 17777)] [New Thread 0x7f98777fe950 (LWP 17776)] [New Thread 0x7f9877fff950 (LWP 17775)] [New Thread 0x7f987ffee950 (LWP 17774)] [New Thread 0x7f9882cf3950 (LWP 17771)] 0x00007f9894a9d5e6 in __poll (fds=0x1870190, nfds=11, timeout=199) at ../sysdeps/unix/sysv/linux/poll.c:87 in ../sysdeps/unix/sysv/linux/poll.c
+ Trace 213697
Thread 5 (Thread 0x7f98761a0950 (LWP 17778))
---- Critical and fatal warnings logged during execution ---- ** totem **: gst_base_transform_find_transform: assertion `gst_caps_is_fixed (caps)' failed Output of custom script "/usr/libexec/totem/totem-bugreport.py": gst-typefind-0.10 version 0.10.21 GStreamer 0.10.21 http://packages.gentoo.org/package/media-libs/gstreamer Listened to a "" file on 2009-03-21T22:36:42 ----------- .xsession-errors (104746 sec old) --------------------- console message: @1: Unsafe JavaScript attempt to access frame with URL http://www.gmodules.com/ig/ifr?url=http%3A%2F%2Fwww.google.com%2Fsupport%2Fforum%2Fstatic%2Fv1%2Ffeedreader.xml&up_feed_title=& console message: @1: Unsafe JavaScript attempt to access frame with URL http://www.gmodules.com/ig/ifr?url=http%3A%2F%2Fwww.google.com%2Fsupport%2Fforum%2Fstatic%2Fv1%2Ffeedreader.xml&up_feed_title=& console message: @1: Unsafe JavaScript attempt to access frame with URL http://www.gmodules.com/ig/ifr?url=http%3A%2F%2Fwww.google.com%2Fsupport%2Fforum%2Fstatic%2Fv1%2Ffeedreader.xml&up_feed_title=& console message: @1: Unsafe JavaScript attempt to access frame with URL http://www.gmodules.com/ig/ifr?url=http%3A%2F%2Fwww.google.com%2Fsupport%2Fforum%2Fstatic%2Fv1%2Ffeedreader.xml&up_feed_title=& console message: @1: Unsafe JavaScript attempt to access frame with URL http://www.gmodules.com/ig/ifr?url=http%3A%2F%2Fwww.google.com%2Fsupport%2Fforum%2Fstatic%2Fv1%2Ffeedreader.xml&up_feed_title=& console message: @1: Unsafe JavaScript attempt to access frame with URL http://www.gmodules.com/ig/ifr?url=http%3A%2F%2Fwww.google.com%2Fsupport%2Fforum%2Fstatic%2Fv1%2Ffeedreader.xml&up_feed_title=& console message: @1: Unsafe JavaScript attempt to access frame with URL http://www.gmodules.com/ig/ifr?url=http%3A%2F%2Fwww.google.com%2Fsupport%2Fforum%2Fstatic%2Fv1%2Ffeedreader.xml&up_feed_title=& ...Too much output, ignoring rest... --------------------------------------------------
How to reproduce: 1) Start movie with totem and set it playing 2) Edit -> Preferences 3) Choose audio tab 4) Change the "output" type ie. from Stereo to 5.1 channel audio Crash :)
Which version of gstreamer and gst-plugins-base is used here?
> Which version of gstreamer and gst-plugins-base is used here? media-libs/gstreamer-0.10.21-r3 media-libs/gst-plugins-base-0.10.21
Could you run totem in gdb with $ G_DEBUG=fatal_warnings gdb --args /usr/bin/totem file-or-uri so we get a stack trace from the "** totem **: gst_base_transform_find_transform: assertion `gst_caps_is_fixed (caps)' failed" warning? Also, the audioresample element has been replaced by a new element in the last release, so it would be great if you could retest with the latest core/base releases (0.10.23).
** CRITICAL **: gst_base_transform_find_transform: assertion `gst_caps_is_fixed (caps)' failed aborting... Program received signal SIGABRT, Aborted.
+ Trace 215791
Thread 140615810365712 (LWP 28721)
a nasty refcounting problem has been fixed in git too, it should be in 0.10.25 when it's out.
Does this stilll happen with latest GIT? If it does GST_DEBUG=5 output would be nice to have (bzip2 compressed attached because it's probably too large).
(In reply to comment #7) > Does this stilll happen with latest GIT? If it does GST_DEBUG=5 output would be > nice to have (bzip2 compressed attached because it's probably too large). This is still happening with 0.10.24. I feel a bit reluctant about trying git version, can't this wait until either 0.10.25 is out or I can just test specific patch?
0.10.24 is fine too. Could you provide a debug log with 0.10.24?
Here we go: http://plaes.org/files/2009-Q3/totem.log.bz2
Priit, is this still an issue with gstreamer-0.10.25?
(In reply to comment #11) > Priit, is this still an issue with gstreamer-0.10.25? Yes it is (updated version). Uploaded a new log file: http://plaes.org/files/2010-Q1/totem.log.lzma
FWIW, I can reproduce it now :)
Problem is, that totem has a capsfilter which will get new caps whenever the audio settings are changed. Capsfilter will call gst_base_transform_suggest() with this, which will later in gst_base_transform_buffer_alloc() call gst_base_transform_find_transform(). Unfortunately this function requires fixed caps but totem sets unfixed caps :) Not sure what should be done here, capsfilter should definitely accept unfixed caps.
Created attachment 151566 [details] [review] basetransform: Only use suggested caps in buffer allocation if a size was suggested too
(In reply to comment #15) > Created an attachment (id=151566) [details] [review] > basetransform: Only use suggested caps in buffer allocation if a size was > suggested too This "fixes" the assertion but it's definitely not a complete and correct fix. Not sure how the new caps suggestion by capsfilter should be forwarded upstream without them being fixed and without having a size suggestion too.
Comment on attachment 151566 [details] [review] basetransform: Only use suggested caps in buffer allocation if a size was suggested too From the code it seems this has been committed
Created attachment 156297 [details] [review] basetransform: Accept non-fixed caps suggestions When doing pad_allocs, use non-fixed caps suggestions and try to fixate them before using. This makes possible to have suggested buffer size with 0 in basetransform just to signal upstream a renegotiation is needed Fixes #576234 Fixes #609046
Review of attachment 156297 [details] [review]: Looks good except this: ::: libs/gst/base/gstbasetransform.c @@ +1599,3 @@ + + if (!gst_caps_is_fixed (sink_suggest)) + goto not_fixed; If the caps are not fixed after intersecting and fixating you should not error out but instead do no upstream negotiation. This case can happen if the upstream element is some converter for example. Take the totem case, the sample rate would still not be fixated if audioresample is before the capsfilter.
Created attachment 156302 [details] [review] basetransform: Accept non-fixed caps suggestions Updated patch with suggestions.
(In reply to comment #20) > Created an attachment (id=156302) [details] [review] > basetransform: Accept non-fixed caps suggestions > > Updated patch with suggestions. Looks good :)
Pushed Module: gstreamer Branch: master Commit: a6a3c129d11e81e932b5e4ce2b42f1294d135e3c URL: http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?id=a6a3c129d11e81e932b5e4ce2b42f1294d135e3c Author: Thiago Santos <thiago.sousa.santos@collabora.co.uk> Date: Tue Mar 16 10:32:12 2010 -0300 basetransform: Accept non-fixed caps suggestions When doing pad_allocs, use non-fixed caps suggestions and try to fixate them before using. This makes possible to have suggested buffer size with 0 in basetransform just to signal upstream a renegotiation is needed Fixes #576234 Fixes #609046