GNOME Bugzilla – Bug 662312
Upgrading GStreamer core causes PiTiVi to start spewing warnings
Last modified: 2011-10-30 20:52:37 UTC
Upgrading from gstreamer-0.10.34-1.fc15.i686 to todays git master (while keeping all other modules unchanged), causes pitivi to start ouputing the following debug spew on the terminal: (pitivi:6233): GStreamer-WARNING **: pad internal-volume:src accepted caps ANY although they are not a subset of its caps audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)44100, channels=(int)2; audio/x-raw-float, width=(int)64, rate=(int)44100, channels=(int)2, endianness=(int)1234; audio/x-raw-int, width=(int)32, depth=(int)32, rate=(int)44100, channels=(int)[ 2, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-float, width=(int)32, rate=(int)44100, channels=(int)2, endianness=(int)1234; audio/x-raw-float, width=(int)64, rate=(int)44100, channels=(int)[ 2, 11 ], endianness=(int)1234; audio/x-raw-int, width=(int)24, depth=(int)24, rate=(int)44100, channels=(int)[ 2, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-float, width=(int)32, rate=(int)44100, channels=(int)[ 2, 11 ], endianness=(int)1234; audio/x-raw-int, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)[ 2, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-int, width=(int)32, depth=(int)32, rate=(int)44100, channels=(int)[ 1, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-int, width=(int)24, depth=(int)24, rate=(int)44100, channels=(int)[ 1, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-int, width=(int)16, depth=(int)16, rate=(int)44100, channels=(int)[ 1, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-float, width=(int)64, rate=(int)44100, channels=(int)[ 1, 11 ], endianness=(int)1234; audio/x-raw-int, width=(int)8, depth=(int)8, rate=(int)44100, channels=(int)[ 1, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-float, width=(int)32, rate=(int)44100, channels=(int)[ 1, 11 ], endianness=(int)1234; audio/x-raw-int, endianness=(int)1234, signed=(boolean)true, width=(int)32, depth=(int)32, rate=(int)[ 1, 2147483647 ], channels=(int)2; audio/x-raw-float, width=(int)64, rate=(int)[ 1, 2147483647 ], channels=(int)2, endianness=(int)1234; audio/x-raw-int, width=(int)32, depth=(int)32, rate=(int)[ 1, 2147483647 ], channels=(int)[ 2, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-float, width=(int)32, rate=(int)[ 1, 2147483647 ], channels=(int)2, endianness=(int)1234; audio/x-raw-float, width=(int)64, rate=(int)[ 1, 2147483647 ], channels=(int)[ 2, 11 ], endianness=(int)1234; audio/x-raw-int, width=(int)24, depth=(int)24, rate=(int)[ 1, 2147483647 ], channels=(int)[ 2, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-float, width=(int)32, rate=(int)[ 1, 2147483647 ], channels=(int)[ 2, 11 ], endianness=(int)1234; audio/x-raw-int, width=(int)16, depth=(int)16, rate=(int)[ 1, 2147483647 ], channels=(int)[ 2, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-int, width=(int)32, depth=(int)32, rate=(int)[ 1, 2147483647 ], channels=(int)[ 1, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-int, width=(int)24, depth=(int)24, rate=(int)[ 1, 2147483647 ], channels=(int)[ 1, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-int, width=(int)16, depth=(int)16, rate=(int)[ 1, 2147483647 ], channels=(int)[ 1, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-float, width=(int)64, rate=(int)[ 1, 2147483647 ], channels=(int)[ 1, 11 ], endianness=(int)1234; audio/x-raw-int, width=(int)8, depth=(int)8, rate=(int)[ 1, 2147483647 ], channels=(int)[ 1, 11 ], endianness=(int)1234, signed=(boolean)true; audio/x-raw-float, width=(int)32, rate=(int)[ 1, 2147483647 ], channels=(int)[ 1, 11 ], endianness=(int)1234
This is probably a duplicate of bug #659606 but OTOH gst_pad_accept_caps() should never ever be called with non-fixed caps anyway because that behaviour is not defined.
Almost forgot about this one. The problem is apparently in gnonlin, and Edward fixed it on the 0.11 branch. I'll try to backport it.
This should do the trick: commit 46c355038b9998ab57801511797ad17e8b013dfa Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Thu Oct 6 10:50:12 2011 +0200 gnlsource: Don't use _accept_caps to figure out compatible pads It isn't reliable due to issues with gst_caps_is_subset. Instead we just check if a pad caps intersect with the target caps Ported from 0.11 (471611). Fixes bug #662312. Conflicts: gnl/gnlsource.c