similar to: [PATCH] opus-tools/opusfile: Support for Ambisonics

Drew Allen wrote: > Friendly ping for supporting ambisonics in opus-tools & opusfile > > Please LMK any ?s you might have. Sorry for the long delay on the review. The high-level design looks a lot better. I have a number of comments on the implementation details. I didn't really like the way that opus_head_projection_parse() turned out. I was originally thinking something

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:

Excellent, thanks Tim for writing back so quickly! Cheers, Drew On Tue, Mar 6, 2018 at 6:25 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Drew Allen wrote: > >> Please feel free to ask any questions or give any feedback you might >> have. :) >> > > A few comments from a quick glance through the opusfile patch: > > You unconditionally

Move demixing matrix defines to opus_define to better determine availability of Projection API. Allows libopusenc, opusfile and opus-tools to much more easily determine availability of Projection API. Cheers, Drew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20180307/110f7aaf/attachment.html>

Hello Jean-Marc et all, I've attached an updated patch which I feel addresses all 3 cases. PTAL, Thanks! Cheers, Drew On Wed, Mar 7, 2018 at 8:39 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Make sure the modified libraries work in all of these three cases: > 1) libopus 1.2.1 > 2) libopus master (or 1.3-beta) with --enable-ambisonics > 3) libopus master (or

Drew Allen wrote: > Please feel free to ask any questions or give any feedback you might > have. :) A few comments from a quick glance through the opusfile patch: You unconditionally #include <opus_projection.h> in the public header, but you haven't updated the libopus version requirement in configure.ac. Ideally, of course, libopusfile would continue to work with older

Hello all, Attached is the initial proposed implementation for ch.mapping 253/3, based on the IETF proposal: https://tools.ietf.org/html/draft-ietf-codec-ambisonics-03 A brief overview of the patch, as it is slightly lengthy: After discussion with Jean-Marc, we determined that ch.253/3 will need the demixing matrix as part of the encoder/decoder struct stack and thus will require a new

Thanks for looking over this, Mark! I'm travelling this week but when I'm back I'll address all of your concerns and send,out another patch. :) On Jun 7, 2017 9:56 AM, "Mark Harris" <mark.hsj at gmail.com> wrote: > On Tue, May 30, 2017 at 3:13 PM, Drew Allen <bitllama at google.com> wrote: > > Hello all, > > > > Attached is the initial

Apologies! That patch will not work correctly with Opus 1.2. Will send an updated patch shortly!! On Mon, Mar 26, 2018 at 11:56 AM Drew Allen <bitllama at google.com> wrote: > Hello all! > > I've attached an updated patch for opusfile, based on formatting > suggestions I got for the opus and libopusenc patches. > > Cheers! > Drew > > On Thu, Mar 22, 2018 at

Just to confirm, I would use opeint_* for all the OpusGenericEncoder-related functions? On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Mark, Drew, > > On 03/20/2018 02:40 AM, Mark Harris wrote: > > + int _oge_use_projection(int channel_mapping); > > > > These functions are part of libopusenc, so I'd expect them to have an

apologies, this is the correct patch I meant to send: On Mon, Jun 12, 2017 at 9:19 AM Drew Allen <bitllama at google.com> wrote: > Thanks again Mark for taking a look and pointing out the issues that > previous patch had. I've addressed your concerns. The tests should no > longer give any warnings or errors regarding usage or c89. I've ensured the > memory issues have

Thanks! 2 down, 2 to go. :D :D :D On Wed, Mar 21, 2018 at 11:19 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Thanks, the libopus and the libopusenc patches are now merged. > > Cheers, > > Jean-Marc > > On 03/20/2018 12:36 PM, Drew Allen wrote: > > Attached is an updated patch based on Jean-Marc and Mark's comments. :) > > > >

Hi Drew, I think the libopusenc patch is better, but there's still a few issues left: 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because if you link libopusenc with a new version of libopus that supports higher order projection or just more projection channels for order 3, then you will overflow the buffer. I think what you'd want is a _ope_opus_header_get_size() call

Hi Drew, Some comments on the libopusenc patch: + int _oge_use_projection(int channel_mapping); These functions are part of libopusenc, so I'd expect them to have an ope prefix like the other functions in the libopusenc library. + if (_oge_use_projection(h->channel_mapping)) + { + len=27+(h->channels*(h->nb_streams+h->nb_coupled)*2); + } + else + { +

Attached is an updated patch based on Jean-Marc and Mark's comments. :) Cheers, Drew On Tue, Mar 20, 2018 at 9:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 03/20/2018 11:51 AM, Drew Allen wrote: > > Just to confirm, I would use opeint_* for all the > > OpusGenericEncoder-related functions? > > Correct. Or you can also use oge_ if you like. Just

Hi Jean-Marc, Thanks so much for your review. Attached are my comments and an updated patch. On Mon, Oct 30, 2017 at 5:48 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I've had some time to dig more deeply into your patch. Here's some more > in-depth comments: > > 1) I note that your OpusMSEncoder struct in private.h adds a > subframe_mem[]

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,

Hi Andrew, I suspect that the configure option should be enable-ambisonics (instead of enable_ambisonics), but for each of opus, libopusenc, opusfile and opus-tools git repos (on master branch), when I try "./configure --enable-ambisonics", I get this error message: configure: WARNING: unrecognized options: --enable-ambisonics Thanks for your help. Marc Le 19-12-18 à 11 h 52, Andrew

Hello Tim and others, Thanks for your help explaining this process on IRC. I wrote out a first draft in the RFC xml format. I have attached the xml (labeled as xml.txt so it will appear inline) and the rendered txt files. Please let me know where I can make improvements. I will upload this draft to the IETF datatracker and send it out to codec@ after addressing your comments. -------------- next

Hi Opus list. I subscribed because your discussion on the IETF draft ("Ambisonics in an Ogg Opus Container") was mentioned on the sursound list. I tried Opus for ambisonics more than a year ago. It does works with uncoupled channels (I had to patch the encoder). I don't know what else could be done to optimize support for ambisonics, as I'm not a codec expert. So I think that