similar to: How to obtain optimized opus codec?

Hi all, Currently I am working on a WebRTC based audio application that requires opus codec to be integrated. For that purpose, I need optimized version of opus codec. Can you please guide me in obtaining the same? Regards, Vignesh prabu -------------- next part -------------- An HTML attachment was scrubbed... URL:

I was wondering if anyone knows if Asterisk 12 will be supporting the OPUS codec, which is part of the WebRTC standard as the default codec. Thank you, -- James Mortensen Project Manager, VoiceCurve, Inc. 866-707-4590 james.mortensen at voicecurve.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi,? Anyone could provide more information on the level of complexity (OPUS_SET_COMPLEXITY(x) , x between 0 and 10 ?) which is recommended for generic Android devices ? How about the iPhone devices ??Is there a way to choose this complexity level according to the device model ? Any hints ? We've seen they set 5 in webrtc :http://code.google.com/p/webrtc/issues/detail?id=3093Freeswitch is

Hi! everybody: We used opus-codec for a VOIP gateway. The GW is running at a UBUNTU server. The opus stream is transcoded to G711 pcmu stream.So there are many opus codecs running simultaneously. We noticed that if there more than 5 streams in. the voice then has notisable glitchs.More streams in, worse voice got. Then we write test code for opus-codec which encode a .pcm file simultaneously.

Hi, I work on a webRTC application and recently tried updating from opus 1.1.5 to 1.2.1 Afterwards I noticed occasionally weird audio glitches. I finally tracked down the issue to the opus decoder in my application outputting samples with the value of -32768. This behaviour stopped when reverting to opus 1.1.5 or compiling opus 1.2.1 without configuring --enable-float-aprox and --0fast. The

On 02/22/2018 09:34 PM, Stepan Salenikovich wrote: > Its unexpected because the decoder continues to output all samples > of -32768 even when the microphone input is silence or near silence, so > I would expect the decoded values to be at or near 0. Oh, if the output is stuck at -32768, then it's likely some NaNs crept in. The first thing to check is whether the problem is on the

hello all - sorry for such a basic newbie question, but is opus now fully supported using the latest google-chrome? according to this link: http://news.cnet.com/8301-1023_3-57577464-93/google-hitches-opus-audio-technology-to-webrtc-star/ "Chrome 27, making its way through the development pipeline, is helping to advance the fortunes of a?new audio compression technology called Opus."

Hi Stepan, I would need more information to be able to investigate further. It's legal for the decoder to output -32768, so it would be good if you could explain how this is unexpected. Ideally an audio file with details on how to reproduce the problem would help. Optionally, if you could bisect the git repo to see where the problem started. Cheers, Jean-Marc On 02/22/2018 07:15 PM,

Any luck reproducing the problem with opus_demo or opus-tools? Jean-Marc On 02/22/2018 10:14 PM, Stepan Salenikovich wrote: > > > On Thu, Feb 22, 2018 at 9:53 PM, Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > On 02/22/2018 09:34 PM, Stepan Salenikovich wrote: > > Its unexpected because the decoder continues to

On Thu, Feb 22, 2018 at 8:34 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Stepan, > > I would need more information to be able to investigate further. It's > legal for the decoder to output -32768, so it would be good if you could > explain how this is unexpected. Its unexpected because the decoder continues to output all samples of -32768 even when the

Hi folks sincere apologies if this is not meant to be posted here. I am the CEO at http://directi.com. One of our products http://talk.to is in the messaging space and we are planning to add voice support to our application and are currently investigating codecs (Opus, ilbc, isac, G.729, AMR etc). There are several variables and obviously Opus would be our preferred choice given its quality, VBR,

Hi folks sincere apologies if this is not meant to be posted here. I am the CEO at http://directi.com. One of our products http://talk.to is in the messaging space and we are planning to add voice support to our application and are currently investigating codecs (Opus, ilbc, isac, G.729, AMR etc). There are several variables and obviously Opus would be our preferred choice given its quality, VBR,

Hello Opus community, I'd like to ask you for advice and recommendations. WebRTC uses Opus, and I noticed https://webrtc-codereview.appspot.com/5549004 started referring to currently internal Opus headers. This is possible because for Chromium the Opus sources are just checked in, so any header can be #included. I detected this when trying to package Chromium for Linux distributions with

On 13-08-14 10:09 PM, Bob Estes wrote: > I've been studying the Opus code and documentation for a while and have > seen it mentioned several times that Opus uses pre-skip to allow the > codec to converge. What convergence are they referring to? Rate > control? Energy envelope prediction after seeking? Not rate control, but there are a number of predictors running in the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In addition to Chrome's support for Opus in WebRTC, Tom Flanagan has added support for .opus files in the HTML <audio> element, similar to what Firefox has. It's currently behind a switch, so you'll need to pass --enable-opus-playback to M25 or M26 to evaluate. I tried some the files https://people.xiph.org/~greg/opus_testvectors/

Mark Edwards just pointed out to me that Chrome 33 is now in stable release. That means that by default, Chrome users can play Opus files. In addition to using Opus with WebRTC connections, M33 is the first release with default support for .opus encapsulated files and http(s) streams. Congratulations, Google! In my quick testing it played all my music files, including surround, and respected the

On Thu, Feb 22, 2018 at 9:53 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 02/22/2018 09:34 PM, Stepan Salenikovich wrote: > > Its unexpected because the decoder continues to output all samples > > of -32768 even when the microphone input is silence or near silence, so > > I would expect the decoded values to be at or near 0. > > Oh, if the output is

Yes, that's a start. Ultimately, though, I'm hoping to reduce the 80ms requirement, and am trying to get a handle on what state in the decoder must converge and what complications I might be up against. I'm also only considering CELT-based encodings if that simplifies things. I know that Opus can do inter-frame energy envelope prediction, but that dependency can be eliminated by

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

Hi Stephen, > So we have been advised from this thread > https://github.com/muaz-khan/WebRTC-Experiment/issues/28#issuecomment-18385702 > to not use http put as it is not in real-time, instead they are > suggesting the use of SDP, is that something that icecast supports? Or > does anyone have other ideas on this? The imminent Airtime 2.4.0 release has support for Opus, and it