similar to: RFC 8251 approved, now enabled by default

--- releases.sha2 | 1 + 1 file changed, 1 insertion(+) diff --git a/releases.sha2 b/releases.sha2 index dc0a6fce..334976b1 100644 --- a/releases.sha2 +++ b/releases.sha2 @@ -40,6 +40,7 @@ cfafd339ccd9c5ef8d6ab15d7e1a412c054bf4cb4ecbbbcc78c12ef2def70732 opus-1.2.1.tar 96fa28598e8ccd558b297277ad59a045c551ba0e06d65a9675938e084f837669 opus-1.3-rc.tar.gz

Hi, I'm working on porting libopus and I'd like to get information how to test Opus Encoder properly. There is information in RFC6716, that Opus Decoder's test files (http://opus-codec.org/testvectors/opus_testvectors.tar.gz) were created specifically to exercise all aspects of the decoder. Using these files, a custom implementation of libopus can be verified to be sure the Opus

Viswanath Puttagunta wrote: > a. Simplest use case to validate this optimization for correctness. > b. Simplest use case to validate this optimization for performance. > > Would prefer something like opusdec that can be executed on command > line. The easiest thing to use is probably opus_demo (opusdec does a bunch of extra things, plus for interactive use we care about both the

Hi everyone, I'm pleased to announce that the IETF has just approved for Opus to become a standard. I'll still take a few more weeks of editing before it's published as an RFC, at which point we'll release version 1.0. From now on, we'll be replacing the use of the CELT name with Opus and I'd like to encourage everyone to switch to Opus in their applications. Note that

On 24 November 2014 at 14:53, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > > On 21 November 2014 at 18:06, Timothy B. Terriberry <tterribe at xiph.org> wrote: > > > > Viswanath Puttagunta wrote: > >> > >> a. Simplest use case to validate this optimization for correctness. > >> b. Simplest use case to validate this

On 21 November 2014 at 18:06, Timothy B. Terriberry <tterribe at xiph.org> wrote: > > Viswanath Puttagunta wrote: >> >> a. Simplest use case to validate this optimization for correctness. >> b. Simplest use case to validate this optimization for performance. >> >> Would prefer something like opusdec that can be executed on command >> line. > >

On 24 November 2014 at 17:48, Peter Robinson <pbrobinson at gmail.com> wrote: >>> >> a. Simplest use case to validate this optimization for correctness. >>> >> b. Simplest use case to validate this optimization for performance. >>> >> >>> >> Would prefer something like opusdec that can be executed on command >>> >>

>> >> a. Simplest use case to validate this optimization for correctness. >> >> b. Simplest use case to validate this optimization for performance. >> >> >> >> Would prefer something like opusdec that can be executed on command >> >> line. >> > >> > >> > The easiest thing to use is probably opus_demo (opusdec

Hi everyone, We finally made it! Opus is now standardized by the IETF as RFC 6716 (http://tools.ietf.org/html/rfc6716). See the announcements at: https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/ http://www.xiph.org/press/2012/rfc-6716/ Feel free to spread those around :-) We're also releasing both 1.0.0 (same code as the RFC) and 1.0.1, which is a

Hi everyone, We finally made it! Opus is now standardized by the IETF as RFC 6716 (http://tools.ietf.org/html/rfc6716). See the announcements at: https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/ http://www.xiph.org/press/2012/rfc-6716/ Feel free to spread those around :-) We're also releasing both 1.0.0 (same code as the RFC) and 1.0.1, which is a

Mark and Ed received word today that the long-awaited RFC for IAX2 has been approved by the IETF, and is now published: http://www.rfc-editor.org/authors/rfc5456.txt Thanks to Ed Guy, Mark Spencer, Brian Capouch, Frank Miller, and Kenny Shumard! Lots of revisions and discussions have paid off. JT --- John Todd email:jtodd at digium.com Digium, Inc. | Asterisk Open

FYI, the Opus RTP payload format is now RFC7587: https://tools.ietf.org/html/rfc7587 Cheers, Jean-Marc -------- Forwarded Message -------- Subject: [payload] RFC 7587 on RTP Payload Format for the Opus Speech and Audio Codec Date: Tue, 30 Jun 2015 16:33:17 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: drafts-update-ref at

Hi, FYI, I'm proposing the following update to the Opus spec to improve low-bitrate hybrid quality. If you'd like to comment, you can reply to this email: https://www.ietf.org/mail-archive/web/codec/current/msg03247.html Cheers, Jean-Marc -------- Forwarded Message -------- Subject: [codec] Last proposal for the update draft Date: Fri, 17 Jun 2016 08:26:04 -0400 From: Jean-Marc Valin

Hello Jean-Marc, Thanks for the quick reply and comments. On Thu, May 26, 2016 at 5:41 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Michael, > > Here's some more minor comments below. As long as you address the two > comments from my previous email (254 -> 2 and the draft name), the draft > is good for submitting as initial version on the IETF website (even

Hello Jean-Marc, Assuming that a 48KHz, 20ms 8-bit linear PCM data which is 960 bytes is compressed to 64 bytes (for assumption). The with the Oggs header (4 byte) + 1 segment entry (which is the size of the segment itself) + 64 bytes will amount to (4+1)/(4+1+64) = ~7.2%. This when compared with the original Oggs container itself for the same data payload size (26+1)/(26+1+64) = ~29.6%. Even if

Hello Jean-Marc, I suspected the answer to be No. For HMI panels, except for the capture pattern and a single page segment entry, other fields are not important, and which results in almost 7% overhead for a 20ms raw frame encoded with Opus. At the same time the file processing complexity is way too less considering that CRC's do not not need to be considered (programmer pods ensure that)

The format you're describing here actually has *more* overhead than Ogg, not less. It's also unseakable, not robust errors, and without support for metadata. I'm not sure why you would want that. It's not like you're forced to include much data in the Ogg metadata (which seems to be the source of all the overhead you're seeing). Jean-Marc On 05/12/2016 11:51 AM, Amit

Hi Julien, Quote from : http://dspguru.com/dsp/faqs/multirate/resampling "The problem is that for resampling factors close to 1.0, the interpolation factor can be quite large. For example, in the case described above of changing from the sampling rate from 48 kHz to 44.1 kHz, the ratio is only 0.91875, yet the interpolation factor is 147!" My guess is that Opus would perform similar to

Hi, another question on the same topic Speex resampler at 44.1kHz seems to be very CPU intensive on Android (even more than the Opus encoder) While Speex at 48kHz is just fine. I wonder any alternate solutions or ideas ? Improve it, look for alternate solution ... I am guessing the NEON optimization are still used for both, etc. On Thu, Apr 2, 2015 at 4:46 PM, Jean-Marc Valin <jmvalin at

Hi Amit, I'm not sure what you're trying to ask, but the reserved space in the header is an optional thing. Encoders are free to do it, but are not required to do so. Jean-Marc On 05/11/2016 01:32 PM, Amit Ashara wrote: > Hello Jean-Marc, > > So for the moment we can assume that this method is also OK to use? > > On Embedded Systems, both SRAM and Flash can be a