GNOME Bugzilla – Bug 607105
faac doesn't negotiate channel positions correctly
Last modified: 2010-01-16 23:35:24 UTC
faac accepts multichannel audio in any order, and just feeds into the actual faac encoder as-is, without specifying any channel ordering. Presumably, faac requires the channels in a particular order (probably the AAC/MPEG order, which is e.g. C, L, R, LS, RS, LFE for 5.1). So the element should require this in getcaps. As it is, e.g. gst-launch filesrc location=5.1-sample.wav ! wavparse ! audioconvert ! faac ! qtmux ! filesink will output something with the channels in the wrong order (because the wav channel ordering is different from the AAC one).
commit 007b667366b1fe17d9d356450f56dd7de734bb29 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Sat Jan 16 13:05:58 2010 +0100 faac: Only accept specific channel layouts as required by AAC Fixes bug #607105.
These channel orderings are wrong. Where did you get them from? As noted in my initial comment, the 5.1 ordering is C, L, R, LS, RS, LFE. I don't have the orderings for all the other channel mappings here. Reopening - listening to this being played back, it's obviously incorrect with this patch.
commit 3c0170aa4b179a386ea65142226ddfb32d3047f5 Author: David Schleef <ds@schleef.org> Date: Sat Jan 16 15:32:47 2010 -0800 faac: Fix channel layout Adjusted the channel mappings to agree with the default channel mappings in the spec, which is presumably what faac is using. Fixes #607105.