similar to: Opus multi-stream/surround: Audio corruption on decoded content

Displaying 20 results from an estimated 300 matches similar to: "Opus multi-stream/surround: Audio corruption on decoded content"

2015 Apr 02
1
Opus multi-stream/surround: Audio corruption on decoded content
Hello Everyone, I am using the opus 1.1 multistream APIs to encode a 5.1 surround stream on the server, stream it to client, decode it and capture the pcm data. I noticed that there was severe corruption/attenuation on one of the channels(specifically Back/Rear Right). This would appear to be the last channel in the stream. I am attaching an image of the PCM dumps from the original and the one
2018 Mar 20
2
[PATCH] Support for Ambisonics
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 + { +
2018 Mar 20
0
[PATCH] Support for Ambisonics
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 > ope prefix like the other functions in the libopusenc library. I'd like to avoid using the ope_ prefix for functions that's aren't in the public API. Right now there are other functions
2018 Mar 20
0
[PATCH] Support for Ambisonics
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 don't use something that starts with an underscore. > On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > Hi
2012 Oct 19
3
How to cross-compile opus-tools?
Hi Is it possible to cross-compile opus-tools with mingw and Ubuntu? So far I have done this:- # prepare $ mkdir $HOME/source $ mkdir $HOME/builds $ export PATH="$PATH:$HOME/mingw-w64-i686/bin" $ PKG_CONFIG_PATH="$HOME/builds/lib/pkgconfig" # Install ogg $ cd $HOME/source $ svn co http://svn.xiph.org/trunk/ogg $ cd ogg $ ./autogen.sh && ./configure
2018 Mar 20
2
[PATCH] Support for Ambisonics
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
2018 Mar 22
0
[PATCH] Support for Ambisonics
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. :) > > Cheers, > Drew > > On Tue, Mar 20, 2018 at 9:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > On
2018 Mar 26
0
[PATCH] Support for Ambisonics
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 9:19 AM Drew Allen <bitllama at google.com> wrote: > 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
2018 Mar 20
2
[PATCH] Support for Ambisonics
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
2018 Mar 22
2
[PATCH] Support for Ambisonics
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. :) > > > >
2018 Jul 07
0
[PATCH] Support for Ambisonics
Minor thing missed: Adding the files to the VS project file. (Sorry for the direct reply, Drew, Gmail's interface always trips me up on mailing lists.) On Fri, Jul 6, 2018 at 6:06 PM Joshua Bowman <silverbacknet at gmail.com> wrote: > Minor thing missed: Adding the files to the VS project file. > > (Sorry for the direct reply, Drew, Gmail's interface always trips me up
2016 Apr 26
0
Antw: [opus-tools] [PATCH] Add channel-mapping argument to force channel mapping
Hi! I haven't looked into the code yet, but the patch uses different coding conventions like "if(" and "if ("; like wise "){" and ") {". My personal taste is to have spaces after keywords, but that's just me. I'd prefer a consistent coding style. Regards, Ulrich >>> Michael Graczyk <mgraczyk at google.com> schrieb am 26.04.2016
2016 Apr 26
3
[opus-tools] [PATCH] Add channel-mapping argument to force channel mapping
This patch adds a new option "channel-mapping" to opusenc which sets the channel mapping family used by the multistream encoder. Please let me know whether adding this option is worthwhile and whether the help string is okay. I tried to keep it short but accurate. The error message for an unimplemented channel mapping is "Error cannot create encoder: request not implemented".
2018 Mar 26
3
[PATCH] Support for Ambisonics
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
2018 Mar 19
3
[PATCH] Support for Ambisonics
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
2016 May 27
2
Channel Mapping Family for Ambisonics
Hello Jean-Marc, Thanks for the quick reply and comments. On Thu, May 26, 2016 at 5:41 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Michael, > > Here's some more minor comments below. As long as you address the two > comments from my previous email (254 -> 2 and the draft name), the draft > is good for submitting as initial version on the IETF website (even
2017 Jun 07
0
Initial implementation of ch.mapping 253/3
On Tue, May 30, 2017 at 3:13 PM, Drew Allen <bitllama at google.com> wrote: > 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
2017 Jun 12
0
Initial implementation of ch.mapping 253/3
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 also been addressed. Please let me know any and all other concerns as well. :) Attached is the new proposed patch. Cheers, Drew On Wed, Jun 7, 2017 at
2014 Jan 06
2
Possible bug in opus_multistream_surround_encoder_create()
I get reliable crashes if I create a 6-channel encoder using opus_multistream_surround_encoder_create(). If I use opus_multistream_encoder_create() instead and pass in the same parameters that opus_multistream_surround_encoder_create() sends out (streams = 4, coupled_streams = 2, mapping = {0, 4, 1, 2, 3, 5}) I don't get the crashes. I notice that opus_demo.c uses
2017 Jun 12
1
Initial implementation of ch.mapping 253/3
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