<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 25, 2018, at 12:47, Martin Leese <<a href="mailto:martin.leese@stanfordalumni.org" class="">martin.leese@stanfordalumni.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Rodger Combs wrote:<br class=""><br class=""><blockquote type="cite" class="">I've run into some issues using Opus with source files in channel layouts<br class="">other than the default 8. For instance, 2.1 isn't supported, so I have to<br class="">either downconvert to 2.0 or upconvert to 5.1 (which usually involves adding<br class="">empty channels, which prevents the playback device from upconverting to the<br class="">native layout).<br class="">To address this, I've put together an initial draft of an I-D I'd like to<br class="">run by this list for feedback.<br class="">Here's the RFCXML:<br class="">And the resulting TXT:<br class=""></blockquote><br class="">You might like to take a look at the OggPCM<br class="">spec. This was never implemented, and has<br class="">not been worked since 2009. Visit:<br class=""> <a href="https://wiki.xiph.org/OggPCM" class="">https://wiki.xiph.org/OggPCM</a><br class=""><br class="">and its companion document:<br class=""> <a href="https://wiki.xiph.org/Channel_mapping_examples" class="">https://wiki.xiph.org/Channel_mapping_examples</a><br class=""></div></div></blockquote><div><br class=""></div><div>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?</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">An alternative approach is to only define<br class="">popular layouts. For more obscure layouts,<br class="">such as 2.1 and Mid/Side, assume that the<br class="">person doing the encoding knew what they<br class="">put in, and so knows what will come out.<br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Regards,<br class="">Martin<br class="">-- <br class="">Martin J Leese<br class="">E-mail: martin.leese <a href="http://stanfordalumni.org" class="">stanfordalumni.org</a><br class="">Web: <a href="http://members.tripod.com/martin_leese/" class="">http://members.tripod.com/martin_leese/</a><br class="">_______________________________________________<br class="">opus mailing list<br class=""><a href="mailto:opus@xiph.org" class="">opus@xiph.org</a><br class="">http://lists.xiph.org/mailman/listinfo/opus<br class=""></div></div></blockquote></div><br class=""></body></html>