GNOME Bugzilla – Bug 601775
GstAudioChannelPosition is not registered when working with the registry
Last modified: 2009-11-16 10:20:11 UTC
When searching for an item from the registry, I iterate over factories and probe what caps the can take: for(node=audiosink_names;node;node=g_list_next(node)) { GstElementFactory * const factory=gst_element_factory_find(node->data); // can the sink accept raw audio? if(gst_element_factory_can_sink_caps(factory,caps)) { ... This is triggering a CRISTIAL warning: GStreamer-CRITICAL **: Could not convert static caps "audio/x-raw-float, endianness=(int)1234, width=(int)32, channels=(int)1, channel-positions=(GstAudioChannelPosition)< { GST_AUDIO_CHANNEL_POSITION_FRONT_MONO } >" Below is a log of details. The problem is that the caps stored in the registry cannot be deserialized as they contain GstAudioChannelPosition mappings (form gst-plugins-base/gst-libs/gst/audio) and when working with the registry, its enum types are not yet registered. See log below. I wonder how we can fix this. 1) Forbid GstAudioChannelPosition in template caps? 2) add a gst_audio_init() and require apps to call it? For now I added a GST_TYPE_AUDIO_CHANNEL_POSITION; infront of the loop above and that works around the problem. 0:00:07.674125076 19931 0x80e4168 INFO bt-core sink-bin.c:339:bt_sink_bin_determine_plugin_name: get audiosink from gst registry by rank 0:00:07.674148333 19931 0x80e4168 INFO bt-core sink-bin.c:344:bt_sink_bin_determine_plugin_name: probing audio sink: "ladspa-mux-cr" 0:00:07.674169006 19931 0x80e4168 DEBUG default gststructure.c:1940:gst_structure_parse_field: trying field name 'endianness' 0:00:07.674185279 19931 0x80e4168 DEBUG default gststructure.c:1991:gst_structure_parse_value: trying type name 'int' 0:00:07.674202111 19931 0x80e4168 DEBUG default gststructure.c:1940:gst_structure_parse_field: trying field name 'width' 0:00:07.674219362 19931 0x80e4168 DEBUG default gststructure.c:1991:gst_structure_parse_value: trying type name 'int' 0:00:07.674235635 19931 0x80e4168 DEBUG default gststructure.c:1940:gst_structure_parse_field: trying field name 'channels' 0:00:07.674250721 19931 0x80e4168 DEBUG default gststructure.c:1991:gst_structure_parse_value: trying type name 'int' 0:00:07.674273419 19931 0x80e4168 DEBUG default gststructure.c:1940:gst_structure_parse_field: trying field name 'channel-positions' 0:00:07.674291578 19931 0x80e4168 DEBUG default gststructure.c:1991:gst_structure_parse_value: trying type name 'GstAudioChannelPosition' 0:00:07.674306524 19931 0x80e4168 WARN default gststructure.c:1995:gst_structure_parse_value: invalid type 0:00:07.674320422 19931 0x80e4168 WARN default gststructure.c:1945:gst_structure_parse_field: failed to parse value channel-positions=(GstAudioChannelPosition)< { GST_AUDIO_CHANNEL_POSITION_FRONT_MONO } > 0:00:07.674337813 19931 0x80e4168 WARN default gststructure.c:2124:gst_structure_from_string: Failed to parse field, r=channel-positions=(GstAudioChannelPosition)< { GST_AUDIO_CHANNEL_POSITION_FRONT_MONO } >
This is a known issue. I believe (1) is what was decided last time this came up.
I believe this was a recent change to ladspa in commit 374d52d257b07e2fc20b405a091ed0d7085e1298 and should probably constitute a blocker.
Jan, yes - thats the commit. For ladspa it's easy to fix - its always mono and we have no reliable metadata about positions. So I can make a patch to remove the position (making it the default). For lv2 its different though. I could change the code to not set anything for mono. But I think this is only working around the problem. Can we maybe just serialize things as GEnum in the core (avoiding specific Enums)?
All the other elements just omit the channel positions in the pad templates, but apply them in getcaps for the actual pad and that works fine. I think deserialising a generic GEnum from the registry is not useful - it's no better than just omitting, since it's still not useful for checking caps compatibility.
Jan, would it be fine for you, if I then make a patch for that to fix it for the release?
yes please
Created attachment 147820 [details] [review] don't set channel positions in template-caps Revert the changes that added audio positions to template caps. We have an un- fortunate limitation in core that does not allow to do it. Keep a few things commented out, so that the channel position can later on be set in setcaps. I will do a 2nd patch that sets the channel position in setcaps, but that needs more changes and imho can be done after the freeze. Okay?
Comment on attachment 147820 [details] [review] don't set channel positions in template-caps thanks for making the patch
commit 38592a566dc83be99392488cc0e7cd01cbcffce7 Author: Stefan Kost <ensonic@users.sf.net> Date: Sun Nov 15 21:46:01 2009 +0200 signalprocessor: don't set channel positions in template-caps, Fixes #601775 Revert the changes that added audio positions to template caps. We have an un- fortunate limitation in core that does not allow to do it. Keep a few things commented out, so that the channel position can later on be set in setcaps.