similar to: Many changes landing in master

Hi Mark, Jean-Marc, Thanks for your comments. On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com> wrote: > 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 =

Hi! A note on style: Looking at this chunk of the patch -- @@ -382,9 +382,15 @@ int main(int argc, char *argv[]) frame_size = sampling_rate/25; else if (strcmp(argv[ args + 1 ], "60")==0) frame_size = 3*sampling_rate/50; + else if (strcmp(argv[ args + 1 ], "80")==0) + frame_size = 4*sampling_rate/50; +

Hi everyone, I've just released Opus 1.2-alpha. It comes with many improvements, including: - Speech quality improvements especially in the 12-20 kbit/s range - Improved VBR encoding for hybrid mode - More aggressive use of wider speech bandwidth, including fullband speech starting at 14 kbit/s - Music quality improvements in the 32-48 kb/s range - Generic and SSE CELT optimizations - Support

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

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>

Hi Jean-Marc, Thank you. Yes, we do need both channels independent. So, if we encode each channel separately, we will be sacrificing the compression ratio we would achieve with stereo encoding, correct? So, based on what you say here is my understanding. Please confirm this is correct or not: 1) If we use fec, we can reduce cross-talk but increasing bitrate. However, that should result in

Thank you. Very helpful. > On Jan 27, 2017, at 12:40 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > > On 27/01/17 12:29 PM, Jon Lederman wrote: >> Thank you. Yes, we do need both channels independent. So, if we >> encode each channel separately, we will be sacrificing the >> compression ratio we would achieve with stereo encoding, correct? > > Not

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

Xiph.Org is pleased to announce that we've released Opus 1.2. The 1.2 release includes: . Speech quality improvements especially in the 12-20 kbit/s range . Improved VBR encoding for hybrid mode . More aggressive use of wider speech bandwidth, including fullband speech starting at 14 kbit/s . Music quality improvements in the 32-48 kb/s range . Generic and SSE CELT optimizations .

On 27/01/17 12:29 PM, Jon Lederman wrote: > Thank you. Yes, we do need both channels independent. So, if we > encode each channel separately, we will be sacrificing the > compression ratio we would achieve with stereo encoding, correct? Not necessarily. Stereo makes two assumptions: 1) It assumes the two channels are somehow correlated 2) It assumes the two channels are meant to be

Hi, One other question I was wondering about. Is the reason that we hear the crosstalk with fec and packet loss percentage>0 is that Opus uses information from the left channel to try to error correct the right channel and vice versa? I am trying to understand the origin of the crosstalk. Thanks. -Jon > On Jan 27, 2017, at 12:29 PM, Jon Lederman <jon at soniccloud.com> wrote: >

On 2019-04-08 4:55, Gustaf Ullberg wrote: > Thank you Mark. > > I agree and have now updated the pull request with a new commit, > addressing your comments. > Please take a look. > > /Gustaf I think you will also need to check the mode of the previous frame (st->prev_mode) before using internal SILK encoder state. It could have been in SILK DTX some time ago, but then

On 27/01/17 12:16 PM, Jon Lederman wrote: > 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? Correct. Another effect I forgot to mention is that Using FEC will actually force SILK/hybrid rather than CELT, so it's possible that disabling FEC makes you use CELT, which

Hi all, I try to enable FEC in the encoder using the macro OPUS_SET_INBAND_FEC and I set the packet loss percentage to a constant value of 30%, using the macro OPUS_SET_PACKET_LOSS_PERC. Please find my encoder settings below: opus: encoder fmtp (maxplaybackrate=8000;maxaveragebitrate=24000;sprop-stereo=1;cbr=1;useinbandfec=1;usedtx=1) opus: encode bw=narrow bitrate=24000 fch=auto vbr=0 fec=1

Hi everyone, Just to let you know that Opus 1.2 is finally here. This major release brings many quality improvements, new features, and bug fixes. You can read all the details (and hear audio samples) in this release demo page page: https://people.xiph.org/~jm/opus/opus-1.2/ Changes since 1.1.x include: - Speech quality improvements especially in the 12-20 kbit/s range - Improved VBR encoding

The email might have been blocked due to the attachment size, here?s a link to it. https://www.dropbox.com/s/r9j7l3cbb02ob7i/opusDtx_noiseFix1_inOut.zip Pascal On 26/06/14 19:02, "Pascal Huart (phuart)" <phuart at cisco.com> wrote: >Hi Jean-Marc, >Thanks for the fix, the reconstructed signal is now much better. >Unfortunately there are still discontinuities which show

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,

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

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 (returning only TOC, no frame content). We were expecting all or more to be identified as non-voice. Our idea was to check how the decoder re-generates the original ambient noise during the silence duration (when we feed NULL to decoder) when