[opus] [PATCH] Support for Ambisonics and Projection API.

Jean-Marc Valin jmvalin at jmvalin.ca
Wed Mar 14 15:39:06 UTC 2018

Hi Drew,

Had a look at your libopusenc patch and I think overall it's on the
right track. I have a few comments though:
1) It's changing the meaning of MAX_HEADER_SIZE. That value isn't meant
to mean the max size of the Opus header, but rather it's the max size of
an Ogg page header. It should not be changed here.

2) In general, I think you should use dynamic allocation for the Ogg
header, because libopusenc *could* be linked to a newer version of
libopus that supports order-10 projection encoding. libopusenc should
not make assumptions about what libopus version it is linked against.

3) Not sure on that one, but wouldn't the stuff you do in
_generic_encoder_fetch_header_data() be cleaner if you moved it to
_ope_opus_header_to_packet()? Considering point 2) above, maybe it's
possible to avoid the dynamic allocation by copying the data straight to
the packet?

4) I *think* there's a way to make a _generic_encoder_ctl() through the
use of a macro. The macro would look something like (untested):
#define _generic_encoder_ctl(st, request) ((st->family == 253) ?
opus_projection_encoder_ctl(st->pr, request) :
opus_multistream_encoder_ctl(st->ms, request))
The macro would of course have a simpler definition when ambisonics
support is disabled.
Based on a quick experiment I made, I think the _generic_encoder_ctl()
above should work even with multiple-argument requests.


On 03/06/2018 06:42 PM, Drew Allen wrote:
> Hello all,
> Attached are patches for libopusenc, opusfile and opus-tools in order to
> provide support for Ambisonics and the Projection API for
> encoding/decoding channel mapping 253 and 254.
> Please feel free to ask any questions or give any feedback you might
> have. :)
> Cheers,
> Drew
> _______________________________________________
> opus mailing list
> opus at xiph.org
> http://lists.xiph.org/mailman/listinfo/opus

More information about the opus mailing list