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 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. Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/
> 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>
On 10/25/18, Rodger Combs wrote:> >> On Oct 25, 2018, at 12:47, Martin Leese <martin.leese at stanfordalumni.org> >> wrote:...>> 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.Yes, passing the details of obscure layouts out-of-band is exactly what I meant, particularly as the person decoding the file is probably also the person who encoded it. As you will have seen in the OggPCM spec, there are an awful lot of possible layouts. 2.1 is not a *consumer* format, so the need to create a standard for it is not great. Regards, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: http://members.tripod.com/martin_leese/