search for: opus_head_parse

Friendly ping for supporting ambisonics in opus-tools & opusfile Please LMK any ?s you might have. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20180410/fd4a3709/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:

...is relatively easy to add to libopus so I'll wrap the function calls and the #include around this #define. This will also allow us to not have to explicitly enable ambisonics. :) > > The addition of fields to the OpusHead struct is a breaking ABI change > (specifically, all callers of opus_head_parse() would need to be rebuilt > from source). > > Is OPUS_DEMIXING_MATRIX_SIZE_MAX future-proof? I seem to recall much > larger matrices being allowed according to the spec. You'll note that > OPUS_CHANNEL_COUNT_MAX is 255, even though opusfile currently only supports > mappings...

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 -------------- next part -------------- An HTML attachment was scrubbed... URL:

...ead_projection_parse() turned out. I was originally thinking something more generic/future proof that could also be used for any other channel mapping families that want to define a custom channel mapping table. The way this is implemented in the patch you sent, it duplicates a lot of code from opus_head_parse(), the user still needs to call opus_head_parse() (so the work gets duplicated at runtime, too), and they have to pass in a buffer of exactly the right size (which means they need to know some details of the specific mapping family and how the demixing matrix works). I think a slightly better...

...lable. See the definition of OP_SOFT_CLIP in opusfile's src/internal.h for the hacks I've had to do to detect other libopus API additions (hopefully we can avoid things like that here). The addition of fields to the OpusHead struct is a breaking ABI change (specifically, all callers of opus_head_parse() would need to be rebuilt from source). Is OPUS_DEMIXING_MATRIX_SIZE_MAX future-proof? I seem to recall much larger matrices being allowed according to the spec. You'll note that OPUS_CHANNEL_COUNT_MAX is 255, even though opusfile currently only supports mappings with up to 8 channels (se...