[Vorbis-dev] Multichannel Vorbis encode

[xiphmont at xiph.org]

On Mon, Jan 25, 2010 at 11:41 AM, Lucas Clemente Vella <lvella at gmail.com> wrote:
> There is some time now that I reported this issue on the bugtracker:
> https://roundup.ffmpeg.org/roundup/ffmpeg/issue1325
>
> And this guy, jbr, kindly created a patch that solved the problem. What
> is needed now for the patch to be included in the SVN?
>
> About his patch, there is a remap table that maps the channel order from
> SMPTE order to Vorbis order. What is this SMPTE order? Vorbis
> specification was updated to include channel order for 6.1 and 7.1
> audio, but I can't update the patch to include them because I don't know
> what is this SMPTE order.

Vorbis channels are explicitly in ASTM/ETSI order, that is, the
traditional channel order for eight track theater sound and the same
as AC3..   all compliant AC3 decoders should be in the same channel
order as Vorbis as they're all using the same spec.  So FFMPEG is
apparently rearranging the channels out of the correct order and then
needs a libvorbis patch to undo it...????  That doesn't seem right.
Something is confused (or just forgetting there are systems other than
Windows out there).

Regardless of what's actually going on in ffmpeg, remapping
functionality doesn't belong in every codec, it belongs in the
framework.  Libvorbis is already used in many systems that are able to
remap channels between codecs, adding that functionality to libvorbis
too is just bloat.  If ffmpeg needs to rearrange channels (it must be
able to, to have rearranged the AC3 output into SMPTE) it should
rearrange the channels, not force every codec to change to what it
wants to pass.

Eg, it turns out that ogg123 wasn't able to handle different channel
orders, so the proper place to fix it (just added to SVN last night)
is in libao, not all the codecs and loaders.  One piece of code in one
place instead of 50.

Monty