[opus] Proposal - Extended Channel Layouts in Opus

[Rodger Combs]

> On Oct 25, 2018, at 12:47, Martin Leese <martin.leese at stanfordalumni.org> wrote:
> 
> Rodger Combs wrote:
> 
>> I've run into some issues using Opus with source files in channel layouts
>> other than the default 8. For instance, 2.1 isn't supported, so I have to
>> either downconvert to 2.0 or upconvert to 5.1 (which usually involves adding
>> empty channels, which prevents the playback device from upconverting to the
>> native layout).
>> To address this, I've put together an initial draft of an I-D I'd like to
>> run by this list for feedback.
>> Here's the RFCXML:
>> And the resulting TXT:
> 
> You might like to take a look at the OggPCM
> spec.  This was never implemented, and has
> not been worked since 2009.  Visit:
>    https://wiki.xiph.org/OggPCM
> 
> and its companion document:
>    https://wiki.xiph.org/Channel_mapping_examples <https://wiki.xiph.org/Channel_mapping_examples>

This seems like a nice, rich set of channels, but I'm not sure if a draft spec (intended for RFC) citing another draft spec is wise. Maybe a case for copying a basic set into this, and defining a new IANA registry?

> 
> An alternative approach is to only define
> popular layouts.  For more obscure layouts,
> such as 2.1 and Mid/Side, assume that the
> person doing the encoding knew what they
> put in, and so knows what will come out.

I'm not sure what you mean here. There are a few ways to push some encoder API work onto the user (or API consumer), but there has to be some way to communicate the layout in-stream to the decoder, or else (as is currently the case) we'd be forcing anyone encoding less-than-universal layouts to pass that information out-of-band to anyone wanting to decode the stream.

> 
> Regards,
> Martin
> -- 
> Martin J Leese
> E-mail: martin.leese  stanfordalumni.org
> Web: http://members.tripod.com/martin_leese/
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/opus/attachments/20181025/b229c0e3/attachment.html>