[opus] Proposal - Extended Channel Layouts in Opus
rodger.combs at gmail.com
Thu Oct 25 17:58:28 UTC 2018
> 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:
> 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.
> Martin J Leese
> E-mail: martin.leese stanfordalumni.org
> Web: http://members.tripod.com/martin_leese/
> opus mailing list
> opus at xiph.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the opus