similar to: opus_decoder open source

Hi Julien, Quote from : http://dspguru.com/dsp/faqs/multirate/resampling "The problem is that for resampling factors close to 1.0, the interpolation factor can be quite large. For example, in the case described above of changing from the sampling rate from 48 kHz to 44.1 kHz, the ratio is only 0.91875, yet the interpolation factor is 147!" My guess is that Opus would perform similar to

I wrote a proof of concept regarding the cpu capabilities runtime detection and choice of optimized function. I follow design which had been discussed on IRC. Also, i notice a little drawback: we must propagate the arch index through functions which don't have codec state as argument. However, if it's look good, i will continue to implement it. Best regards, -- Aur?lien Zanelli

-- Joshua Bowman Silverback Networks (559) 305-3770 silverbacknet at gmail.com www.silverbacknetworks.net -------------- next part -------------- src/analysis.c | 6 +++--- src/mlp.c | 3 +++ src/opus.vcxproj | 5 +++++ src/opus.vcxproj.filters | 15 +++++++++++++++ src/opus_demo.vcxproj | 4 ++++ src/opus_demo.vcxproj.filters |

The encoder and decoder can handle, 8, 12, 16, 24 and 48 kHz input/output. If doesn't matter what it gets encoded to/decoded from. you can initialize a decoder at 8 kHz and it'll still decode 48 kHz audio fine (you just won't get the high frequencies obviously). For sampling rates other than 8/12/16/24/48, then you'll have to do resampling. Have a look at the speexdsp resampler if

This fixes a tiny copy/paste error in a comment, which confused me for a moment when first reading the code: https://github.com/xiph/opus/pull/60 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170824/efa597ed/attachment-0001.html>

Hi, is there any way to tell the decoder the output sampling Fz we want ? opus_decoder_create = Sampling rate of input signal (Hz) Considering this example (VoIP-out from WebRTC/RTP) MICROPHONE(44.1/48kHz) >> [encoder created at 48kHz but with internalSampleRate set to 8kHz]>> INTERNET >> [decoder(created with 48kHz)] >> 48kHz(?) >> G.711(8kHz) This leaves us with

Hi, another question on the same topic Speex resampler at 44.1kHz seems to be very CPU intensive on Android (even more than the Opus encoder) While Speex at 48kHz is just fine. I wonder any alternate solutions or ideas ? Improve it, look for alternate solution ... I am guessing the NEON optimization are still used for both, etc. On Thu, Apr 2, 2015 at 4:46 PM, Jean-Marc Valin <jmvalin at

Hi Jean-Marc, Could you please update if you got a chance to look into. As I mentioned, I don't see the same issue in 1.1.1, but I don't see any difference in 1.1.1 other than optimization based on the architecture. This optimization could have fixed some stack overflow issue in some specific cases? Thanks Suresh On 13 April 2015 at 12:39, Suresh Thiriveedi <sthiriveedi at

This is observed on a live call between webRTC browser client and another legacy client. Our server is there in between and transcoding from opus to another codec and this is observed while decoding the opus. Anyway, I'll try to capture/dump the packets in the server before feeding to the opus_decode and share with you. But this will not have the first 8 bytes (length+enc range) to directly

Hi Jean-Marc, Thanks for your response. Please find the details as below. *Backtrace we got for this crash:* #0 0x0000000000800c54 in opus_decode_frame (st=0x38906b8f99d09c5, data=0xf0aa10b4ef1008ae <Address 0xf0aa10b4ef1008ae out of bounds>, len=-188613428, pcm=0x6e80016085efd57, frame_size=44037315, decode_fec=58716895) at src/opus_decoder.c:384 #1 0x00000000008009c0 in

I just tried decoding with v1.1: ./opus_demo -d 48000 2 opus_encoded_crash.opus out.pcm and I see no issue (including with valgrind). Does the same command-line create problems for you? What compile flags did you use? fixed-point or float, any assembly, ...? Could be assembly here, or even a compiler bug wouldn't be unheard of. Cheers, Jean-Marc On 20/04/15 07:27 AM, Suresh Thiriveedi

On 2019-04-01 3:37, Gustaf Ullberg wrote: > Hi everyone, > > Some time ago, I sent a pull request > <https://github.com/xiph/opus/pull/107> to the Opus github page. > Jean-Marc asked me to post it to the mailing list so everyone can have a > look at it. > > You can find the description and code changes below. Please let me know > if you have any questions or

Hi, I am new to Opus, I want to decode a RTP packet which has opus payload. Following can describe my intention: I have RTP-packet----------> rtp_header+ opus_payload(20ms/960/48000/1channel) I have now opus_palyload after removing the rtp_header, what I want, a simple code using the opus_decoder which can give me the 20 msec opus paylaod consists of 960 samples. Can anybody put a simple

To be decodable by opus_demo, you'll have to add the 8-byte "header". Just put in the length of the packet followed by "0" for the encoder range (0 means "not present"). That being said, from previous experience, the most likely cause of the crash is a bug in your software causing a corruption in Opus. So it's safe to assume that if you can't reproduce

Hi, We are able to reproduce the issue with the 1.1 opus_demo (sample file). We captured the frames in our server just before the opus_decode and fed the file to opus_demo (1.1) and it is crashing. Same file is tested with 1.1.1 and it is fine. So this is in line with our server testing observation and I think here we can conclude that the 1.1 library is crashing while handling a specific mode

Please provide the input file that produces this with opus_demo. On 16/04/15 03:24 AM, Suresh Thiriveedi wrote: > Hi Jean-Marc, > > Could you please update if you got a chance to look into. As I > mentioned, I don't see the same issue in 1.1.1, but I don't see any > difference in 1.1.1 other than optimization based on the architecture. > This optimization could have

Hi everyone, Some time ago, I sent a pull request <https://github.com/xiph/opus/pull/107> to the Opus github page. Jean-Marc asked me to post it to the mailing list so everyone can have a look at it. You can find the description and code changes below. Please let me know if you have any questions or concerns. Best regards Gustaf Ullberg In WebRTC, we would like to be able to

Still can't reproduce. What OS and compiler version? Jean-Marc On 21/04/15 02:48 AM, Suresh Thiriveedi wrote: > Hi, > > There is no change in the compiler flags. I'm using as it is from the > original code. No change in the Makefile and I believe it is using the > floating point only by default. > > We are using 8k samples and mono so the commands is as follows.

Hi Dmitry, So it's not explicitly in your report, but it looks like the crash is due to a divide-by-zero at: min_coef = silk_DIV32_16( silk_int16_MAX, silk_RSHIFT( psSilk_VAD->counter, 4 ) + 1 ); which happens because counter is -16 (which means (-16 >> 4) + 1 == 0). Now, this could be caused by an integer wrap-around, but it should only happen after encoding around

Stack: (gdb) bt #0 0x0000000000aaf38a in silk_VAD_GetNoiseLevels (pX=pX at entry=0x7f26740297a0, psSilk_VAD=psSilk_VAD at entry=0x15897c38) at silk/VAD.c:315 #1 0x0000000000aa4a9d in silk_VAD_GetSA_Q8_sse4_1 (psEncC=0x15897c18, pIn=<optimized out>) at silk/x86/VAD_sse.c:177 #2 0x0000000000a9f92b in silk_encode_do_VAD_FLP (psEnc=psEnc at entry=0x15897c18) at