similar to: Availability of the 1.1.1 stable version

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

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

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

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

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

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

Yes, good point. I added the checking of prev_mode for Silk DTX to avoid using stale data from the Silk state. The PR is updated, and I'm attaching an updated patch. /Gustaf On Tue, 9 Apr 2019 at 12:42, Mark Harris <mark.hsj at gmail.com> wrote: > On 2019-04-08 4:55, Gustaf Ullberg wrote: > > Thank you Mark. > > > > I agree and have now updated the pull request

Thank you Mark. I agree and have now updated the pull request with a new commit, addressing your comments. Please take a look. /Gustaf On Fri, 5 Apr 2019 at 11:41, Mark Harris <mark.hsj at gmail.com> wrote: > 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>

Hi, I wondered if are there any further thoughts on these patches? Thanks, Felicia On Thu, Jun 2, 2016 at 2:13 PM Felicia Lim <flim at google.com> wrote: > OK, I've amended the second patch and also added 80 and 100 ms. > > Thanks, > Felicia > > > On Thu, Jun 2, 2016 at 7:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > >> On 06/01/2016 02:06

Hi Felicia, A few comments: > - /* CELT can only support up to 20 ms */ > subframe_size = st->Fs/50; > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > + nb_subframes = frame_size/subframe_size; This will use six 20ms frames to make a 120ms packet, even for SILK-only mode where frames can be up to 60ms. For SILK, two 60ms frames would be a more

Attached is the amended second patch. It now extends the multistream API as well to 80/100/120 ms and incorporates changes based on Mark's comments. Thanks, Felicia On Mon, Jun 13, 2016 at 4:21 PM Felicia Lim <flim at google.com> wrote: > Hi Mark, Jean-Marc, > > Thanks for your comments. > > On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com>

On 06/01/2016 02:06 PM, Felicia Lim wrote: > That was my intention with refactoring out the subframe encoding and > repacketizing bit. Or do you mean I should merge the explicit check for > 120 ms frame and the existing checks for 40/60 ms wideband? What I mean is that this line in opus_encoder.c: if (frame_size > st->Fs/50 && (st->mode == MODE_CELT_ONLY ||

Hi Ulrich, thanks for the suggestion. My concern is that one of the valid inputs is "2.5", which would require conversion to an int, e.g. x10, but doing something like this would start to affect the code readability. On Mon, Jun 27, 2016 at 3:02 PM Ulrich Windl < Ulrich.Windl at rz.uni-regensburg.de> wrote: > Hi! > > A note on style: Looking at this chunk of the patch

Hello all, after FOMS I decided to take a look at the opus library and I found that I could improve a bit the build system and cleanup the code a little bit. Most of the changes to the code has been suggested by my two tools cowstats and missingstatic (part of the ruby-elf gem if you care). HTH, Diego

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