On Tue, Apr 19, 2016 at 10:20 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote:> So the important question is "can an existing decoder (assuming it knows > about the ambisonics channel mapping) decode your file?". If the answer > is yes, then it's just an encoder-only change and it's easy to add to > the code base. If the answer is no, then it's actually a bitstream > change. A bitstream change would either have to go through the IETF > process or (if it's just a pre/post transform) at the very least have a > formal definition somewhere. In either case, that's a lot more work than > just a new mapping or even an encoder-only change.That makes sense. For now I will focus on encoder only changes. If an adaptive pre/post transform had to send side information, would it also need to go through the IETF process?> The first step is definitely to add a new channel mapping for ambisonics.Great, I'll write up something precise and send it out. On Tue, Apr 19, 2016 at 10:19 AM, Timothy B. Terriberry <tterribe at xiph.org> wrote:> I'm assuming that the pre/post transform would be something like a > decorrelating transform on the channels, and the actual core parts of Opus > would not change. For that, I think an extra channel mapping is a reasonable > approach, without requiring a new version number. > > We've talked about using the Opus padding as a place to store extra side > information in the past. I haven't thought deeply about the trade-offs > between that and other approaches, like using an invalid TOC sequence to add > additional packet data, as we did with the MPEG TS embedding > (<https://wiki.xiph.org/OpusTS>). > > The difficulty with padding is that it prevents transparent repacketization, > because the padding occurs once per Opus packet, while side information is > typically required once per Opus frame (of which there can be several in an > Opus packet). The invalid TOC sequence approach would put the data in its > own Opus packet entirely, which might have other drawbacks.Thanks for the link. It looks like that embedding carries metadata. Would it be possible to include something like residual coded transform coefficients that way?> That seems like the best approach. See also > <https://www.iana.org/assignments/opus-channel-mapping-families/opus-channel-mapping-families.xhtml>. > As long as there is a specification somewhere (this does not have to be an > IETF specification, though it could be), we can add it to this list.Great, I will use these as a guide to writing a more precise description of the ambisonic mapping. -- Thanks, Michael Graczyk
Michael Graczyk wrote:> That makes sense. For now I will focus on encoder only changes. If an > adaptive pre/post transform had to send side information, would it > also need to go through the IETF process?The IANA registry for channel mappings has a policy of "specification required", but not "RFC required", so it is possible to specify something without going through the full IETF process. Still, if this is something you expect to be used outside of Google properties (and it sounds like it is), I think going through the IETF process would be a good idea (even though that means more work for me).> Thanks for the link. It looks like that embedding carries metadata. > Would it be possible to include something like residual coded > transform coefficients that way?Yes. The intent in MPEG TS was to extend this someday to support dynamic range control (see, e.g., ISO/IEC 23003-4) and explicit downmixing matrices, but no one's done the work for that yet (nor does anyone have concrete plans to do it, that I'm aware of). MPEG TS does not have global headers (as it is meant for over-the-air broadcast streaming), so all of this has to be in-band. We should probably start keeping track of the space of invalid TOC sequences somewhere global so that people don't define conflicting extensions.
On 04/19/2016 03:17 PM, Timothy B. Terriberry wrote:> Michael Graczyk wrote: >> That makes sense. For now I will focus on encoder only changes. If an >> adaptive pre/post transform had to send side information, would it >> also need to go through the IETF process? > > The IANA registry for channel mappings has a policy of "specification > required", but not "RFC required", so it is possible to specify > something without going through the full IETF process. Still, if this is > something you expect to be used outside of Google properties (and it > sounds like it is), I think going through the IETF process would be a > good idea (even though that means more work for me).Well, keep in mind that the side information has to go somewhere too. If that information goes into the padding, then we'd need an RFC that updates the Opus RFC. If it goes into Ogg directly, then we may need an RFC to update the Ogg Opus RFC. Jean-Marc
On 19/04/16 12:17 PM, Timothy B. Terriberry wrote:> We should probably start keeping track of the space of invalid TOC > sequences somewhere global so that people don't define conflicting > extensions.I started such a page at https://wiki.xiph.org/OpusExtensions -r -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: <http://lists.xiph.org/pipermail/opus/attachments/20160419/54f56bd2/attachment.sig>