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

For some reason the attachment did not go through. Re-attaching. From: Mukund Raman Sent: Wednesday, April 01, 2015 6:12 PM To: 'opus at xiph.org' Subject: 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

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 + { +

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

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

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

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

Thanks, Bob! I guess we should be expecting a 4.2.1 update after clang 3.0 has been released, shouldn't we? Best, Akos From: Bob Wilson <bob.wilson at apple.com<mailto:bob.wilson at apple.com>> Date: Thu, 20 Oct 2011 08:46:38 -0700 To: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>> Cc: "llvmdev at cs.uiuc.edu<mailto:llvmdev

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

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

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. :) > > > >

This is http://llvm.org/pr10514 Unfortunately the fix did not make it into that version of clang. On Oct 20, 2011, at 7:47 AM, Somorjai, Akos wrote: > Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) > >

Here is a simple patch to fix a bug in opusenc's set-ctl-int code -- Thanks, Michael Graczyk -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-potential-uninitialized-access-for-set-ctl-int.patch Type: text/x-patch Size: 992 bytes Desc: not available URL: <http://lists.xiph.org/pipermail/opus/attachments/20160425/22994ffa/attachment.bin>

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

Here's a code generated with -Os on darwin/x86_64 with clang from the Xcode 4.2 GM toolset on Mac OSX 10.7.2 (Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn), Target: x86_64-apple-darwin11.2.0) 0x000000010277d281 <+2102> lea 0x1d43bd0(%rip),%rax # 0x1044c0e58 <gFloorPlanCutData> 0x000000010277d288 <+2109> movaps 0x80(%rax),%xmm0

I've run into some issues using Opus with source files in channel layouts other than the default 8. For instance, 2.1 isn't supported, so I have to either downconvert to 2.0 or upconvert to 5.1 (which usually involves adding empty channels, which prevents the playback device from upconverting to the native layout). To address this, I've put together an initial draft of an I-D I'd

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

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

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

I just recently found that opus_multistream_encode_float is returning -1 (OPUS_BAD_ARG) with the libopus 1.1 build but works just fine with the libopus 1.0.1 and libopus 1.1-beta builds. I tried using opus_multistream_encoder_create and opus_multistream_surround_encoder_create. Tried with coupled and uncoupled quadraphonic and uncoupled stereo encodes. I'm dynamically loading the libopus