[opus] Channel Mapping Family for Ambisonics

[Michael Graczyk]

Tim,

Would you mind giving me a more specific example of the sort of document
that you think this should look like? I'd like to write up something that
is somewhat final.



On Mon, May 2, 2016 at 9:30 PM, Michael Graczyk <mgraczyk at google.com> wrote:

> On Fri, Apr 29, 2016 at 4:32 PM, Timothy B. Terriberry
> <tterribe at xiph.org> wrote:
> > As a general point, it's too late to add anything to the soon-to-be RFC
> > 7845. It's too far along in the publication process. This would have to
> go
> > in a separate document (which, other than having to add an abstract,
> brief
> > introduction, and some other boilerplate sections, shouldn't be a big
> deal).
>
> That makes sense. Also congrats on the RFC. Could you link me to an
> example of such a document? I don't mind writing up the abstract and
> such based on an example if you have one.
>
> > You say l = 1...15 but the explicit list actually shows (l + 1) ranging
> from
> > 1 to 15, meaning l ranges from 0 to 14.
>
> Thanks, fixed.
>
> > "Channel" is ambiguous. There are "internal" or "encoded channels"
> (signaled
> > in each Opus packet using the stereo flag), "decoded channels" (based on
> the
> > configuration applied to each decoder, as specified by the stream count
> and
> > coupled stream count), and "output channels", which are what you wind up
> > with after applying the channel mapping table. I assume you mean "output
> > channels" here, and should say so.
> Thanks for clarifying, I changed channels here to "output channels".
>
> > It's also probably a good idea to explicitly say that you use the same
> > channel mapping table format as channel mapping families 1 and 255. At
> > least, I'm assuming you do. I'm also assuming you don't plan to support
> > Ambix's "extended format" with its adaptor matrix.
> Thanks, I reworded to
>
> "This channel mapping uses the same channel mapping table format used
> by channel mapping families 1 and 255. Each output channel is
> assigned..."
>
> You are correct, I think it is not worth the complexity to support
> adaptor matrices. Should I explicitly mention that or will the choice
> be clear by not mentioning it?
>



-- 

Thanks,
Michael Graczyk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/opus/attachments/20160516/6b1abc8f/attachment.html>