After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 590361 - vorbisenc caps are ordered improperly
vorbisenc caps are ordered improperly
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal minor
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-07-31 11:24 UTC by LRN
Modified: 2018-11-03 11:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
changes order of caps to 8-1, 9-256. (2.16 KB, patch)
2010-09-28 16:49 UTC, Tristan Matthews
reviewed Details | Review

Description LRN 2009-07-31 11:24:00 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.
Comment 1 Sebastian Dröge (slomo) 2009-08-14 08:20:09 UTC
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?
Comment 2 Balachandran. C 2010-07-13 13:20:36 UTC
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.
Comment 3 Tim-Philipp Müller 2010-07-14 09:09:45 UTC
I ran into this in thoggen as well a while back.
Comment 4 Tristan Matthews 2010-09-28 16:49:55 UTC
Created attachment 171283 [details] [review]
changes order of caps to 8-1, 9-256.
Comment 5 Vincent Penquerc'h 2011-11-08 11:24:11 UTC
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.
Comment 6 Olivier Crête 2018-05-04 11:26:44 UTC
Review of attachment 171283 [details] [review]:

These should be generated Using GstAudioInfo instead I think, so we'd have the right masks and stuff.
Comment 7 GStreamer system administrator 2018-11-03 11:15:28 UTC
-- 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.