GNOME Bugzilla – Bug 753657
Pbutils fails with WMA caps
Last modified: 2015-08-15 15:11:20 UTC
The following examples in Python shows the issue. A 'complete' WMA caps string seems to make Pbutils fall down. In [1]: from gi.repository import Gdk, Gio, Gtk, GLib, Gst, GstPbutils In [2]: Gst.init(None) Out[2]: [] In [3]: caps = Gst.Caps.from_string("audio/x-wma, channels=(int)[ 1, 2 ], rate=(int)[ 4000, 96000 ], wmaversion=(int)2, block_align=(int)[ 0, 2147483647 ], bitrate=(int)[ 0, 2147483647 ]") In [4]: print(caps) <GstCaps at 0x190f320> In [5]: GstPbutils.pb_utils_get_codec_description(caps) ** (ipython:22858): CRITICAL **: gst_pb_utils_get_codec_description: assertion 'gst_caps_is_fixed (tmp)' failed -------------------------- A smaller caps works: In [6]: caps = Gst.Caps.from_string("audio/x-wma, wmaversion=(int)2") In [7]: GstPbutils.pb_utils_get_codec_description(caps) Out[7]: 'Windows Media Audio 8'
You have ranges in your caps, which makes them unfixed. And pbutils only likes fixed caps.
But is it really 'notabug' I mean there is no reason for pbutils not to be able to handle the caps having ranges as it doesn't affect the job pbutils is supposed to do here, which is to identify what human readable string to do. And needing a human readable string for unfixed caps seems to me to not be an obscure usecase in general?
The first question is: where do your unfixed caps come from? The problem is that if you have unfixed caps, you often have fields unfixed that need to be fixed in order to determine the actual format.