similar to: Quality degradation with 1.3.1 when using FEC

Hi, I noticed that in some scenarios, Opus 1.2.1 produces better quality than 1.3.1 does. In the use case here, I'm enabling FEC and "transcode" signals from telephony networks (PCMU, 8kHz sampling) to VoIP (48kHz here). In this case, Opus always produced some leakage/ringing above 4kHz but for 1.3.1, these artifacts became worse. The small script below can be used to demonstrate

At 4:37 PM -0400 7/6/01, Brendan Cully wrote: >On Friday, 06 July 2001 at 13:21, tom erbe wrote: >> At 1:48 PM -0400 7/6/01, Brendan Cully wrote: >> > > 0.2 doesn't segfault, but it seems to overrun the server (if that >> >> makes any sense), it plays a 3 minute file in seconds. >> > >> >I'd like to know more about this. Are you

At 1:48 PM -0400 7/6/01, Brendan Cully wrote: >On Friday, 06 July 2001 at 10:32, tom erbe wrote: >> icecast 1.3.10 is the server i'm running, but its ices 0.1 that gives >> me a segfault under solaris. it works just fine on my linux box. ices > >The segfaults are a stack size problem. Try changing STACKSIZE near >the top of thread/thread.c from 8192 to 65536 or so...

icecast 1.3.10 is the server i'm running, but its ices 0.1 that gives me a segfault under solaris. it works just fine on my linux box. ices 0.2 doesn't segfault, but it seems to overrun the server (if that makes any sense), it plays a 3 minute file in seconds. maybe i'll have to switch to mod_mp3 for my solaris boxes. At 12:38 PM +0100 7/6/01, Ciaran Anscomb wrote: >Sgrifennodd

On Friday, 06 July 2001 at 13:21, tom erbe wrote: > At 1:48 PM -0400 7/6/01, Brendan Cully wrote: > > > 0.2 doesn't segfault, but it seems to overrun the server (if that > >> makes any sense), it plays a 3 minute file in seconds. > > > >I'd like to know more about this. Are you reencoding? If so, note that > >the reencode/samplerate/channels options

On Friday, 06 July 2001 at 15:22, tom erbe wrote: > At 4:37 PM -0400 7/6/01, Brendan Cully wrote: > >Can you add a -v there and see what kind of debug messages you get? > >Also compile with --without-libshout to make sure you are compiling > >with the builtin shout library instead of a possibly buggy already > >installed copy. > > Sure - I did both of those

Has anyone been successful getting an icecast webcast going under Solaris? I have tried several times using different versions of icecast, ices, shout and solaris, but have never been able to get it working without seg. faults, or glitching, or other problems. -- ........................................................................ Tom Erbe . 608 Carla Way, La Jolla, CA, 92037

Hi, I am looking at the conformance test using opus_compare and the test vectors and I am a bit confused about FEC. Is there a way to validate that a decoder processes LBRR frames correctly? Thanks, Alexis

Hi, When running opus_demo with FEC enabled, there is a bug related to the length of FEC frames. The FEC frames will be decoded with a length of max_frame_size and the resulting output file will be much longer than the input file.

Hi, I would like to monitor FEC usage in order to include it in RTCP EX or calculate MOS estimation, etc. However the Opus codec library does not seem to expose such information. "Was LBRR found and used or was it PLC ?" I saw in WebRTC that they are using a technique to parse the "frame header" WebRtcOpus_PacketHasFec() It this something that is supported ? What would you

Hi guys,

At this bitrate the encoder likely decides that it's better to put all the bits in the normal packet than use FEC. When you enable FEC it steals a lot of bits from the non-FEC content. Also, the use of FEC depends on the reported percentage of packet loss. The more loss there is, the lower the threshold for enabling FEC. Overall, the encoder attempt to make the best decision on a

having a hard time communicating on IRC, thank you gmaxwell, very informative. anyway, we were discussing the proper implementation of FEC on the decoder side. well, encoder side is just a boolean thing so that's alright. i gave an example where the receiver lost 5 rtp packets, 1 2 3 4 and 5 during which, we call opus_decode with a null pointer and fec=0 for every packet lost. now, when it

Hi all, Newbie to the group. Just started using Opus as part of a WebRTC project and amazed by the versatility of the codec. Great stuff!!!! I have been trying to understand the performance of Opus inband FEC in the presence of bursty loss. Although I do not have exact characterization of the loss profile, we are seeing issues over WiFi. RTCP reports about 33% loss, but I am guessing a lot of it

What do you mean by "implement"? You're just using the Opus built-in PLC (passing NULL), right? The PLC generally attempts to find periodicity and replicate it. I guess if your signal isn't periodic it can lead to a repetition that isn't great. It's something that could probably be improved in the PLC. Cheers, Jean-Marc On 08/25/2015 01:21 PM, Scott Boekweg wrote:

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

Hi Jon, On 27/01/17 08:31 AM, Jon Lederman wrote: > 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

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*

The -inbandfec option means that the encoder is *allowed* to use FEC, not that it has to. The final decision is based on the bitrate and the percentage of packet loss (and a few minor factors). If you're not seeing a difference, it means that given the options you're using, the encoder thinks actually using FEC would result in worse quality. Cheers, Jean-Marc On 08/05/17 07:11 PM,

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