similar to: [PATCH] Add checksum for opus 1.3.1 release

Hi, Just to let everyone know that RFC 8251, aka "Updates to the Opus Audio Codec" has been approved by the IETF: https://tools.ietf.org/html/rfc8251 This means that the two changes that were previously behind a --enable-update-draft option are now enabled by default in git. If needed (not sure why), they can still be disabled using --disable-rfc8251 The changes require a new set of

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In addition to Chrome's support for Opus in WebRTC, Tom Flanagan has added support for .opus files in the HTML <audio> element, similar to what Firefox has. It's currently behind a switch, so you'll need to pass --enable-opus-playback to M25 or M26 to evaluate. I tried some the files https://people.xiph.org/~greg/opus_testvectors/

Hi, I'm working on porting libopus and I'd like to get information how to test Opus Encoder properly. There is information in RFC6716, that Opus Decoder's test files (http://opus-codec.org/testvectors/opus_testvectors.tar.gz) were created specifically to exercise all aspects of the decoder. Using these files, a custom implementation of libopus can be verified to be sure the Opus

Viswanath Puttagunta wrote: > a. Simplest use case to validate this optimization for correctness. > b. Simplest use case to validate this optimization for performance. > > Would prefer something like opusdec that can be executed on command > line. The easiest thing to use is probably opus_demo (opusdec does a bunch of extra things, plus for interactive use we care about both the

On 21 November 2014 at 18:06, Timothy B. Terriberry <tterribe at xiph.org> wrote: > > Viswanath Puttagunta wrote: >> >> a. Simplest use case to validate this optimization for correctness. >> b. Simplest use case to validate this optimization for performance. >> >> Would prefer something like opusdec that can be executed on command >> line. > >

Hi Marcus, Thanks for the fixes. I did some more cmake build testing and encountered a few issues: The option -DFORTIFY_SOURCE=2 should be -D_FORTIFY_SOURCE=2, as the macro has a leading underscore. In the autotools build it defines this if it is not already defined (m4/ax_add_fortify_source.m4). When custom modes are not enabled, the cmake build is nevertheless installing the include file

On 24 November 2014 at 14:53, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > > On 21 November 2014 at 18:06, Timothy B. Terriberry <tterribe at xiph.org> wrote: > > > > Viswanath Puttagunta wrote: > >> > >> a. Simplest use case to validate this optimization for correctness. > >> b. Simplest use case to validate this

On 24 November 2014 at 17:48, Peter Robinson <pbrobinson at gmail.com> wrote: >>> >> a. Simplest use case to validate this optimization for correctness. >>> >> b. Simplest use case to validate this optimization for performance. >>> >> >>> >> Would prefer something like opusdec that can be executed on command >>> >>

>> >> a. Simplest use case to validate this optimization for correctness. >> >> b. Simplest use case to validate this optimization for performance. >> >> >> >> Would prefer something like opusdec that can be executed on command >> >> line. >> > >> > >> > The easiest thing to use is probably opus_demo (opusdec

On Wed, Apr 10, 2019 at 5:30 PM Marcus Asteborg <xnorpx at outlook.com> wrote: > Hi Mark, > > Thanks for the feedback. > > By default CMake is building the static library in debug, to get other > things one has to explicit turn it on. > > Hi, By default CMake uses the "empty" build, which is used in combination with the environment variables CFLAGS and

Hello, I received feedback from engineers working on NE10 [1] that it would be better to use NE10 [1] for FFT optimizations for opus use cases. However, these FFT patches are currently in review and haven't been integrated into NE10 yet. While the FFT functions in NE10 are getting baked, I wanted to optimize the celt_pitch_xcorr (floating point only) and use it to introduce ARM NEON

--- src/opus_demo.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/src/opus_demo.c b/src/opus_demo.c index 72506b5..5a75679 100644 --- a/src/opus_demo.c +++ b/src/opus_demo.c @@ -245,14 +245,14 @@ int main(int argc, char *argv[]) double bits=0.0, bits_max=0.0, bits_act=0.0, bits2=0.0, nrg; double tot_samples=0; opus_uint64 tot_in, tot_out; - int

Fixes CID 1227580 --- silk/process_NLSFs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/silk/process_NLSFs.c b/silk/process_NLSFs.c index c27cf03..d9123ef 100644 --- a/silk/process_NLSFs.c +++ b/silk/process_NLSFs.c @@ -100,6 +100,6 @@ void silk_process_NLSFs( } else { /* Copy LPC coefficients for first half from second half */ - silk_memcpy(

Hi, On Fri, Jul 29, 2016 at 1:50 PM, dos386 <dos386 at gmail.com> wrote: > I recently stumbled upon <speex/speex_resampler.h> and made a chain of > discoveries: > > - "http://speex.org/downloads" some links are broken ("rarewares" and git) What do you mean by broken? Those links seem to work here. > - there is some (minor) development (whitespace

This is on my TODOOn Wed, Aug 3, 2016 at 1:19 PM, dos386 <dos386 at gmail.com> wrote: > Thanks ... > >> Those links seem to work here. > > 2 links "http://rarewares.hydrogenaudio.org" redirect > to "https://hydrogenaud.io" ... no "rarewares" subdomain > > "http://git.xiph.org/speex.git" maybe better >

Hi, On Sat, Jan 28, 2017 at 2:04 AM, Raghavan, Karthik < karthikr at qti.qualcomm.com> wrote: > Hi > > > > I am not sure if this issue has been resolved, but on the latest opus > 1.1.4, > > · I downloaded the tarball, > > · ran ./configure followed by > > · make and then > > · make check > > > > Can you

Hi, On Thu, Jan 8, 2015 at 11:13 PM, Vikram Karve <Vikram.Karve at citrix.com> wrote: > > Hi, > Has anyone attempted to build the Speex codec for ARM64? If so, could you please share the build instructions or some references detailing what scripts need to be updated. I don't have access to any ARM64 hardware, but you might want to try --disable-neon, see:

Hi, On Thu, Mar 5, 2015 at 2:18 PM, SellBuy Sammamish <sellbuysam at gmail.com> wrote: > Friends, > > My name is Igor, I am new to this forum. > > I have a peculiar problem with my OGG/Speex implementation: I encode a short > PCM stream in OGG/Speex, but the result can not be read by VLC and MediaInfo > reports that the file is too short (240ms). In reality the file

Hi, On Sat, Mar 28, 2015 at 2:34 PM, Evan JIANG <firstfan at gmail.com> wrote: > Hi all, > > (Sorry that may be duplicated that I was not a mail-list member before, > so last mail sent failed) > > I build successfully with speex-1.2rc2. And with speexdsp 1.2rc3, I > build with i386, X86_64, armv7 and armv7s all passed. > But when I build for ARM64 (for

--- src/wave_out.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/wave_out.c b/src/wave_out.c index 57b5703..0f871b9 100644 --- a/src/wave_out.c +++ b/src/wave_out.c @@ -71,7 +71,7 @@ Box ( const char* msg ) */ static void CALLBACK -wave_callback ( HWAVE hWave, UINT uMsg, DWORD dwInstance, DWORD dwParam1, DWORD dwParam2 ) +wave_callback ( HWAVEOUT hWave, UINT