GNOME Bugzilla – Bug 590361
vorbisenc caps are ordered improperly
Last modified: 2018-11-03 11:15:28 UTC
First structure of the caps should be the preferable one. Vorbisenc however specifies its first structure as gst_caps_append_structure (caps, gst_structure_new ("audio/x-raw-float", "rate", GST_TYPE_INT_RANGE, 1, 200000, "channels", G_TYPE_INT, 1, "endianness", G_TYPE_INT, G_BYTE_ORDER, "width", G_TYPE_INT, 32, NULL)); Because of that some elements (namely a52dec) pick first structure to work with, thinking that vorbisenc prefers mono (and because they are able to convert anything to mono, making it compatible). If vorbisenc have had its 8-channel structure first, 7-channel structure second etc, any element would have picked the highest channel count compatible with its natural channel count. For this to happen elements (namely a52dec) should iterate over structures in the caps until they find a structure that is compatible (can be used without upmixing). Elements should not use gst_structure_fixate_field_nearest_int() with structure's channel count and natural channel count, because this way they would pick 8-channel structure as compatible, if natural channel count is less than 8 (fixating to natural channel count), which is OK in terms of channel count, but may lead them into picking wrong channel layout designed for 8-channel audio (the exact result depends on how gst_audio_fixate_channel_positions() would work in situations when channel count does not match channel-positions). There's also a channels=[9,256] structure, and it should be the last one.
So you want the getcaps() function of the sinkpad to return 8, 7, 6, 5, 4, 3, 2, 1, [9-256] channels in that order? Makes sense I guess, do you want to provide a patch? :) Also, are you aware of any other elements than a52dec (audioconvert maybe? ffdec?) that handles this incorrectly?
I found a link to this problem with little bit more info here: http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg793916.html I can confirm the issue: ~/tmp$ gst-launch-0.10 alsasrc ! audioconvert ! vorbisenc ! oggmux ! filesink location=tmp.ogg ~/tmp$ file tmp.ogg tmp.ogg: Ogg data, Vorbis audio, mono, 44100 Hz, ~80000 bps, created by: Xiph.Org libVorbis I ~/tmp$ gst-launch-0.10 alsasrc ! audioconvert ! wavenc ! filesink location=tmp.wav ~/tmp$ file tmp.wav tmp.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 32 bit, stereo 44100 Hz In case of vorbis, I am getting only a mono stream, while in wav, I can get stereo.
I ran into this in thoggen as well a while back.
Created attachment 171283 [details] [review] changes order of caps to 8-1, 9-256.
Testing with the pipeline in comment 2, and the patch by Tristan Matthews, it all works fine, but I get a 8 channel file. That's on a laptop where I'm not even sure there's more than one microphone. Considering that there's some uncertainty about channel ordering above 2, I'm not sure generating those by default is such a good idea if the source does not have so many actual channels in the first place. 2 would seem the best choice for that pipeline, but is hardly a generic assumption.
Review of attachment 171283 [details] [review]: These should be generated Using GstAudioInfo instead I think, so we'd have the right masks and stuff.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/22.