search for: opus_head_parse_ext

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:

...private OP_NCHANNELS_MAX used > internally, for comparison). The idea was that I did not want to break ABI > when we added support for new mappings. > > I will change the define to make it future-proof as well as make it a separate struct (OpusHeadExt, for example) and make the call the opus_head_parse_ext() in order not to break the ABI. > One way to go about this without breaking ABI might be to add support for > "extended" mapping data. I.e., we could create an opus_head_parse_ext() > that takes an extra buffer to return the extended mapping data into. Since > it looks like...

...us_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 approach is along the lines of the opus_head_parse_ext() I originally suggested, but just return a pointer into the user-supplied packet instead of copying the data. For the simple case where the user is just going to pass the data immediately to opus_projection_decoder_create(), they don't need a separate buffer at all, and the parameters to r...

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:

...annels (see the private OP_NCHANNELS_MAX used internally, for comparison). The idea was that I did not want to break ABI when we added support for new mappings. One way to go about this without breaking ABI might be to add support for "extended" mapping data. I.e., we could create an opus_head_parse_ext() that takes an extra buffer to return the extended mapping data into. Since it looks like you're not parsing this matrix anyway, but returning it as a chunk of binary data, hopefully this wouldn't be too unergonomic. The limit on the caller's buffer size could be the limit imposed...