similar to: Opus is now RFC 6716, plus stable releases

Hi Everbody, i am not so good with codecs and a lot of terms in RFC 6716 of OPUS are not so familiar for me. I work in VoIP domain (Internet telephony) and try to support OPUS codec throughout our network. Therefore, I am trying actully to calculate or estimate the biggest possible size of the RTP OPUS Packet in case of WB or FB. Unfortunately, The "Frame Length Coding" paragraph of

Hello Tim and others, Thanks for your help explaining this process on IRC. I wrote out a first draft in the RFC xml format. I have attached the xml (labeled as xml.txt so it will appear inline) and the rendered txt files. Please let me know where I can make improvements. I will upload this draft to the IETF datatracker and send it out to codec@ after addressing your comments. -------------- next

Hello, I understand the encoder provides an option for FEC to provide some protection against packet loss, but I don't understand the details of this arrangement. I'd appreciate answers to the following: * Adding FEC seems to change the encoded audio bit-stream itself, i.e., it doesn't just add additional protection bits, but also changes the encoded bits. This is easy to show by

Hi, I have application, where I am reciving the RTP packets, which has OPUS payload. >From the RTP packets I got following information: (12 byes Header) tells about the version, payload time, time stamp, srsc, etc. The rest of the packet is OPUS payload (raw format), The TOC byte from OPUS payload tells its 20ms frame, even the time stamp different of 960 means 20 msec frame. Questions: 1)

Tim, Would you mind giving me a more specific example of the sort of document that you think this should look like? I'd like to write up something that is somewhat final. On Mon, May 2, 2016 at 9:30 PM, Michael Graczyk <mgraczyk at google.com> wrote: > On Fri, Apr 29, 2016 at 4:32 PM, Timothy B. Terriberry > <tterribe at xiph.org> wrote: > > As a general point,

Is there a reason why opus_repacketier_cat is limited to 120ms packets? It seems 120ms frames can only be combination frames, that is, only constructed by combining smaller frames of the same config. If this is true, then why stop at 120ms and not support longer packets? Regards, -- Daniel. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Jean-Marc, A simpler question. How does opus_encode() generate packets of 20ms (SILK-only or Hybrid)? Concatenating two 10ms frames or doing it straight with just one 20ms frame?

On Fri, Dec 19, 2014 at 9:03 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Daniel K wrote: >> true, then why stop at 120ms and not support longer packets? > > https://tools.ietf.org/html/rfc6716#section-3.2.5 > > "...the audio duration contained within a packet MUST NOT exceed 120 ms..." If you're wondering why the limit exists, there are a

opusdec -V opusdec opus-tools f2a2e88 (using libopus unknown) I've got an opus file encoded from a .wav off a cd, 44100Hz: opusinfo 2-24-Overture_in_C_\(In_Memoriam\).opus Processing file "2-24-Overture_in_C_(In_Memoriam).opus"... New logical stream (#1, serial: 38134f1f): type opus Encoded with libopus unknown User comments section follows... ENCODER=opusenc from opus-tools

Hi Jean The problem is that for using this package I need to use all the libs like ogg, even Speex?, no, and also where i can find an easy example like opus_demo.c to create the .opus file Greetings Toni 2013/10/28 Jean-Marc Valin <jmvalin at jmvalin.ca> > Hi Toni, > > The package you want is opus-tools. You can get it from the download > section. For file distribution,

Hi all, I am a developer for embedded system and totally new to Opus and open source audio codec. I'm now using Microchip dsPIC33 to develop a decoder for Opus. I am now using sources of libopus. The first question is for calling opus_decode(), do I need to skip the header bytes of an opus file before I can input the file data to opus_decode()? Or will libopus handle this automatically?

Hello All When sending the Opus Packet in RTP Payload, the compressed frame is the output of the encoder? Also the config value as given in the RFC6716, 16...19 | CELT-only | NB | 2.5, 5, 10, 20 ms 16 corresponds to 2.5 ms 17 corresponds to 5 ms 18 corresponds to 10 ms 19 corresponds to 20 ms Is this correct representation of the data? Also in the RFC3551 the payload

Thanks for all the amazing work with ambisonics Drew et al. We're looking forward to the 1.3 final release and have already been successfully using the ambisonic work in production code. Varun -- Engineering Manager Facebook Audio ---------------------------------------------------------------------- Message: 1 Date: Sun, 3 Jun 2018 13:02:18 +0100 From: Peter Robinson

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

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

Hello Jean-Marc, As an example, I am using the output of opus encoder to store the file as the following format and read back the same during decode process, without having much overhead. (Thought it would be useful to put a picture rather than running text) [image: Inline image 2] Regards Amit On Thu, May 12, 2016 at 10:47 AM, Amit Ashara <ashara.amit at gmail.com> wrote: > Hello

Right that I had completely missed, I have added the files and verified that it builds with CMake from the tar on Linux (out of the git repo) I am parsing the package_version file from the tarball if it exists so it should maintain the version info. //Marcus ________________________________ From: Jean-Marc Valin <jmvalin at jmvalin.ca> Sent: Tuesday, April 2, 2019 11:38 To: Marcus

The overhead of Ogg (in file size) is pretty small and it's efficient enough for most applications (and uses far less CPU than the codec anyway). If anything, you might want to look at optimizing the existing Ogg implementation (e.g. like Tremor did in the context of Vorbis). Of course, you're always free to design a new container, but I doubt it's worth it and it's a lot of work

Jean-Marc, Thanks for the response and the helpful info. I am trying to get the library to build without using the pseudostack define, and use either VAR_ARRAYS or ALLOC, but it seems the global stack is not defined. Where do can I define this in my example? VR -----Original Message----- From: Jean-Marc Valin [mailto:jmvalin at jmvalin.ca] Sent: Tuesday, February 20, 2018 5:40 PM To:

On 05/12/2016 10:35 AM, Amit Ashara wrote: > 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. I'm not sure how you get a 7% overhead. In most uses I've seen, the overhead is more around 1%. > At the same time the > file