similar to: encoder with FEC+DTX enabled but not detecting noise

Hi, I changed the VAD sensitivity by varying VAD_SNR_FACTOR_Q16 and now it shows the difference in silence frames. Thanks Suresh On 4 October 2016 at 17:57, Suresh Thiriveedi <sthiriveedi at gmail.com> wrote: > Hi, > > When we pass around 9K samples of only ambient noise (no voice), the > encoder which is enabled FEC+DTX is detecting only some 140 frames as > non-voice

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

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

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

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, 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

Hi, I'm curious to know when would be the 1.1.1 stable version available. In 1.1, we are facing crash when opus library is trying to decode the CELT-only, full band and 20 ms. So we tried with 1.1.1 beta and it looks to be fine. Is there any open issue regarding this in 1.1 version? Thanks Suresh -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Looks like 1.1 version is sensitive to the system architecture/compiler/kernel version. Below is my observation in various linux system I have. As you mentioned, you are not observed the crash in your system, can you please share your system details. And also please comment on the below table/observations. *Machine IP* *optimization flags* *RHEL version* *kernel version* *gcc version*

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.

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

Hello, Is FEC supposed to work in NARROWBAND mode ?(with maxaveragebitrate=12000; maxplaybackrate=8000 ) ?I am having some confusing results, it appears that FEC is enabled in the encoder, but the decoder cannot find any packet with FEC. I am also wondering if this piece of code is correct (webrtc): /* The following is to parse the LBRR flags. */? if (opus_packet_parse(payload,

Hi, I'm trying to use the FEC feature. I have a service which does the encoding with OPUS_SET_INBAND_FEC(1) and OPUS_SET_PACKET_LOSS_PERC(20) with 10ms packets. I'm not clear on the decoding process though. 1- When a packet is lost, do I need to call decode with fec=1 ONLY or do I need to call decode with fec=0 after as well? 2- How do I know up front the size of the pcm that I send to

HI All, We are trying to use Opus in a VoIP environment for sending stereo audio. We have noticed a phenomenon where when FEC is enabled and packet_loss_percentage>0, that there is a mixing of audio from the left channel into the right channel and vice versa. That is, rather than hearing each channel in its pristine form as it was in the file, there is a combination of right and left

Hello, I understand the encoder provides an option for FEC to provide some protection against packet loss, but I don't understand the details of this arrangement. I'd appreciate answers to the following: * Adding FEC seems to change the encoded audio bit-stream itself, i.e., it doesn't just add additional protection bits, but also changes the encoded bits. This is easy to show by

Hello, We have a use case where we want to record an opus RTP stream to a .opus file. We want to fill in any gaps in the stream, and we also want to take advantage of inband FEC whenever possible. The ogg/opus draft describes[1] how to fill in gaps by generating zero-byte frames, but I do not understand how (and if) FEC can be used. Is this possible, and if so, what is the recommended way of

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

Thanks. When you say that with fec enabled, the threshold is increased, do you mean the bitrate - i.e., you need higher bitrate with fec enabled to suppress crosstalk? Also, can you make any recommendations to decide whether to use fec or not? We are trying to tune the parameters appropriately. Audio quality and reduction of crosstalk are critical for us. Thanks again. Jon Sent from my

Hello: We noticed that opus reconstructed noise is pulsing with a 400ms pattern when dtx is enabled in silk mode. This is independent of the background noise level and is found with speech + non-speech period test files as well as variable level noise-only test files. This issue can be reproduced with opus v1.1 using this command: ./opus_demo voip 16000 1 25000 -dtx input.bin

Dear Opus community, I have a question about the SILK inband FEC. I am using the opus_demo (opus-1.2-alpha) for testing opus codec, and when I choose the "-inbandfec" option I get the exactly the same results when I don't add it to the command line. Are these results logical? Thank you in advance. Best regards, Ayoub. *--------------------BOUZIANE AyoubPhone : (+212) 633 092 157*