similar to: Please help me decode this webrtc chrome conversation

Yes, I parse the RTP header, decrypt the payload and then feed the decrypted data to opus. Besides, opus_decoder_get_nb_samples() on 1st packet returns reasonable number 960, but then opus_decode() fails. On Fri, Nov 29, 2013 at 11:39 PM, Jean-Marc Valin <jmvalin at jmvalin.ca>wrote: > On 29/11/13 01:49 PM, Ilya Basin wrote: > > For example, the RTP payload is decrypted

On 29/11/13 01:49 PM, Ilya Basin wrote: > For example, the RTP payload is decrypted successfully, but > opus_packet_get_nb_samples() or opus_decode() return > OPUS_INVALID_PACKET. Are you sure you didn't forget to strip the RTP header before decoding it? Jean-Marc

On the call where even opus_decoder_get_nb_samples() fails, what's the value of the first two bytes of the buffer you're sending? And what's the length of the buffer? Jean-Marc On 11/29/2013 03:31 PM, Ilya Basin wrote: > Yes, I parse the RTP header, decrypt the payload and then feed the > decrypted data to opus. Besides, opus_decoder_get_nb_samples() on 1st > packet returns

Hello, there is a chance for an integer overflow in opus_packet_parse_impl(): int padding=0; int p; do { if (len<=0) return OPUS_INVALID_PACKET; p = *data++; len--; padding += p==255 ? 254: p; } while (p==255); len -= padding; ... if (len<0) return OPUS_INVALID_PACKET; When ~16 MB of 0xff bytes is fed to the decoder, the padding

Hi, Opus team I'm Huang Hao and trouble you again. When I used the OpusRepacketizer as Jean-Marc mentioned, I got a result (maybe problem I'm not sure) that perplexes me, please give me some comments. The result be described as below: First(all init which are needed I have done), I used opus_encode() to get the encoded data successfully. The encoder control parameters are set: VBR=0,

Hi All. I have an application where the sample rate of the sender and receiver can vary by a small margin and the latency needs to be maintained within bounds and can't drift significantly and the system has to be able to cope with clock mismatches up to 0.5%. For example, the sender may have a clock rate of 48.1kHz and the receiver may have a clock rate of 47.9kHz. Unfortunately the clock

Hi all, I am a developer for embedded system and totally new to Opus and open source audio codec. I'm now using Microchip dsPIC33 to develop a decoder for Opus. I am now using sources of libopus. The first question is for calling opus_decode(), do I need to skip the header bytes of an opus file before I can input the file data to opus_decode()? Or will libopus handle this automatically?

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

opus_decode() produces 16-bit signed linear PCM, and opus_decode_float() produces 32-bit floating point PCM that is useful when you want a higher bit depth. If you need 8-bit linear PCM then a simple solution would be to use only the top 8 bits of each 16-bit sample from opus_decode(). Note that the WAV format uses unsigned rather than signed integers for 8-bit linear PCM. (It uses signed for

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

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

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

Thanks for your comments, Ralph and Jean-Marc. Please find attached the amended patch: - decodes a sequence of input packets rather than just one (I'm planning on using the Opus test vectors as the seed corpus) - decides on decoder setup and FEC independently of the packet data - uses Opus functions to parse ToC Cheers, Felicia On Sun, Jan 29, 2017 at 9:48 PM Jean-Marc Valin <jmvalin at

Hi all, I'm working on fuzzing Opus with OSS-Fuzz and have started with the decoder. Attached is a patch to add the corresponding fuzz target. Please let me know if there are any concerns? Thanks, Felicia -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170127/f69951aa/attachment-0001.html>

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. [root at MEDIA opus-1.1]# ./opus_demo -d 8000 1 opus_encoded_crash.opus opus_encoded_crash.pcm *And segmentation is as below..*. ............ Calling

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

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

Hello Mark, The resulting 8 bit file has a lot of squelching noise compared to the 16 bit output from OPUS decoder. During encode I am using popi16fmtBuffer[ui32Loop] = (opus_int16)pcRdBuf[ui32Loop]; And during decode since the data is in the lower 8 bit I use pc8bitSamples[ui32Loop] = ((unsigned short)pcop16OutBuf[ui32Loop] ^ 0x80); Regards Amit On Sat, Jan 9, 2016 at 2:39 PM, Amit Ashara

Red Hat Enterprise Linux Server release 6.4 (Santiago) gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) We see the issue in all our Intel based Linux servers. Thanks Suresh On 21 April 2015 at 12:41, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Still can't reproduce. What OS and compiler version? > > Jean-Marc > > On 21/04/15 02:48 AM, Suresh Thiriveedi

Hello everyone. I have a problem with a high level of noise after opus encoding/decoding procedure. If I stream a raw data from the microphone and send it back to the speakers I hear the clear sound (with a small delay). If I encode each frame, decode it and send it back to the speakers I hear a very noisy signal - it is so large, so it is almost impossible to distinguish words in my speech...