similar to: [Patch] Non-diegetic support for channel mapping 254

Hi Jean-Marc et all, Thanks for the quick feedback, responses to your questions are below: I've attached a revised patch. PTAL, thanks! On Fri, Apr 7, 2017 at 1:22 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: Hi Drew, Thakns for the patch. Here's some comments for now (not done reviewing): 1) You want to use isqrt32() rather than celt_sqrt(), since celt_sqrt() changes

Hi Drew, Thakns for the patch. Here's some comments for now (not done reviewing): 1) You want to use isqrt32() rather than celt_sqrt(), since celt_sqrt() changes behaviour for fixed-point and provides no guarantee about rounding. 2) About these two lines: + if (nondiegetic_channels && 2 != nondiegetic_channels) + return OPUS_UNIMPLEMENTED; Why not just have the

Hi Drew, I think your revised patch looks good overall. Just two comments: 1) In opus_multistream_encoder_init_impl(), rather than use a huge condition with two ORs for the return OPUS_BAD_ARG, maybe you can just multiple three separate if()s, each with its own condition (one of which will be entirely in an #ifdef). That should make the code easier to read. 2) In

Hi Jean-Marc, Thanks again for your comments. Attached is a revised patch. On Mon, Apr 24, 2017 at 1:08 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I think your revised patch looks good overall. Just two comments: > > 1) In opus_multistream_encoder_init_impl(), rather than use a huge > condition with two ORs for the return OPUS_BAD_ARG, maybe you can

On 25/04/17 10:12 AM, Drew Allen wrote: > We assume that the input file is ordered first by ACN ambisonic channels > followed by a (possible) stereo track, and we want to swap the order for > the API in order to couple the stereo for coding. Well, if you look at section 5.1.1 of RFC7845: The 'coupled stream count' field indicates that the decoders for the first M

Oops, looks like we both should have been more careful. The patch had some extra lines that shouldn't have been there. Jean-Marc On 28/04/17 12:59 PM, Drew Allen wrote: > My apologies for the confusion, I think I have the mapping layout > correct in this patch. > > Cheers! > > > > On Tue, Apr 25, 2017 at 10:07 AM Jean-Marc Valin <jmvalin at jmvalin.ca >

On 28/04/17 07:54 PM, Drew Allen wrote: > sorry about that... extra lines... was it whitespace? If so, sorry about > that. No, that was worse than that. It broke all the builds. See the fix: https://git.xiph.org/?p=opus.git;a=commitdiff;h=a31e9fd24cd Jean-Marc

Hey Jean-Marc, sorry about that... extra lines... was it whitespace? If so, sorry about that. Thanks! Cheers, Drew Cheers, Drew On Fri, Apr 28, 2017 at 2:43 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Oops, looks like we both should have been more careful. The patch had > some extra lines that shouldn't have been there. > > Jean-Marc > > On

My apologies for the confusion, I think I have the mapping layout correct in this patch. Cheers! On Tue, Apr 25, 2017 at 10:07 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 25/04/17 10:12 AM, Drew Allen wrote: > > We assume that the input file is ordered first by ACN ambisonic channels > > followed by a (possible) stereo track, and we want to swap the order for

Hello, in celt/celt_encoder.c line 369, the 'b' argument to MAX16 can sometimes be greater than what can be represented by a 16bit integer. The default definition of MAX16 is type-less, but I am working on an architecture with hardware support for min/max of 16bit. Changing the default definition to take advantage of this hardware changes the result of that computation. Please consider

Hello All I have successfully run the Opus Decoder for 16-bit WAV files. However when doing the same on 8-bit, the decoder produces noise, but on 16 bit data the output is working. Both the 8 and 16 bit files are from the same source and hence except for some loss of quality on 8 bit, they are identical in total play back duration. For both 8 and 16 bit data I have used the following parameters

Hello Ralph, > Likewise opus_encode() takes 16 bit samples, so you need to extend each > sample from an 8 bit source before encoding. Two questions 1. In opusenc.c which API does the extending the 8-bit to 16-bit? 2. If that is the case then how will 24 bit PCM sample work? Regards Amit On Thu, Jan 7, 2016 at 12:21 PM, Ralph Giles <giles at thaumas.net> wrote: > On 07/01/16

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

Change-Id: I16bd4cd990d8ad5888c9e30016218ac25242ecb5 --- src/opus_multistream_encoder.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/opus_multistream_encoder.c b/src/opus_multistream_encoder.c index 30cafe1..c07132f 100644 --- a/src/opus_multistream_encoder.c +++ b/src/opus_multistream_encoder.c @@ -747,7 +747,8 @@ static void ambisonics_rate_allocation( if

Fixes issue #95 on GitHub. --- src/opus_multistream_encoder.c | 57 ++++------------------------------ 1 file changed, 6 insertions(+), 51 deletions(-) diff --git a/src/opus_multistream_encoder.c b/src/opus_multistream_encoder.c index 6cc1f432..9cb9bf34 100644 --- a/src/opus_multistream_encoder.c +++ b/src/opus_multistream_encoder.c @@ -742,20 +742,9 @@ static void ambisonics_rate_allocation( {

--- src/opus_multistream_encoder.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/opus_multistream_encoder.c b/src/opus_multistream_encoder.c index 6e87337..7163d14 100644 --- a/src/opus_multistream_encoder.c +++ b/src/opus_multistream_encoder.c @@ -98,7 +98,8 @@ static opus_val32 *ms_get_preemph_mem(OpusMSEncoder *st) else ptr += align(mono_size);

On 07/01/16 10:04 AM, Amit Ashara wrote: > opus_decoder_ctl(sOpusDec, OPUS_SET_LSB_DEPTH(ui32BitsPerSample)); OPUS_SET_LSB_DEPTH only affects the encoder. If you check the return value here you should get OPUS_UNIMPLEMENTED. > output_samples = opus_decode(sOpusDec, (const unsigned char > *)&pcRdBuf[0], len, opi16_out, (ui32SizeOfWrBuf/ui8ScaleFactor), 0); I suspect the issue is

Hi Drew, I think the idea of returning OPUS_UNIMPLEMENTED for all projection encoder/decoder calls is pretty reasonable. I haven't looked in detail, but I think some of the calls are missing. I think all calls should have that behaviour and not just the ones used by libopusenc. As for the includes, how about leaving OPUS_PROJECTION_*_REQUEST in opus_projection.h, but defining

Should call celt_inner_prod(). --- celt/bands.c | 7 ++++--- celt/bands.h | 2 +- celt/celt_encoder.c | 6 +++--- celt/pitch.c | 2 +- src/opus_multistream_encoder.c | 2 +- 5 files changed, 10 insertions(+), 9 deletions(-) diff --git a/celt/bands.c b/celt/bands.c index bbe8a4c..1ab24aa 100644 --- a/celt/bands.c +++ b/celt/bands.c

Hello Benjamin, The original WAV file I have is linear 8-bit PCM. I want to ensure that original linear formats are kept as is. Later I will add support for ulaw. Regards Amit On Fri, Jan 8, 2016 at 5:34 PM, Benjamin Schwartz < benjamin.m.schwartz at gmail.com> wrote: > Do you really need linear 8-bit PCM or do you want ulaw? Linear 8-bit is > ... pretty rare. > > On Thu,