Michael Graczyk wrote:> As for mixing matrices, we are not confident in any choices for setups > beyond stereo. Although there have been papers and studies onOkay, better to give no advice than bad advice.> provide only a stereo downmixing matrix. It looks like this would go > in 5.1.1.5? The matrix should beAs 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).> Allowed numbers of channels: (1 + l)^2 for l = 1...15. > > Explicitly 1, 4, 9, 16, 25, 36, 49, 64, 81, 100, 121, 144, 169, 196, > 225. Ambisonics from first to fifteenth order.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.> Each channel is assigned to an ambisonic component in Ambisonic > Channel Number (ACN) order. The ambisonic component with degree n and > ambisonic index m corresponds to channel (n * (n + 1) + m)."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. 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.
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?
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>