search for: rfc6716

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 minor update on that c...

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 minor update on that c...

...rnet 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 RFC 6716 ( https://tools.ietf.org/html/rfc6716#section-3.2.1) is not clear enough for me to understand why "" The maximum representable length is 255*4+255=1275 bytes "" is the Frame length useful only to calculate the bitrate but not the packet size ? the OPUS coded data is compressed. Is it not possible because of this...

...list of conditions, and disclaimer when submitting this document, with or without modification, to the IETF. --> <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'> <!ENTITY rfc7845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7845.xml'> ]> <?rfc toc="yes" symrefs="yes" ?> <rfc ipr="t...

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,

...list of conditions, and disclaimer when submitting this document, with or without modification, to the IETF. --> <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'> <!ENTITY rfc6716 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6716.xml'> <!ENTITY rfc7845 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7845.xml'> ]> <?rfc toc="yes" symrefs="yes" ?> <rfc ipr="t...

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

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:

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 number of reasons... e.g. the overhead is already negligible by 120ms and the larger the amount of audio in a packet the more mem...

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 values are specified but does not give any information o...

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)

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?

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?

ly or Hybrid frames for 40 or 60ms packet, respectively. That is based on = concatenating 20ms frames, right? Is 60ms the largest packet opus_encode() can generate? In order to get pac= kets of up to 120 ms by combining multiple frames as described in RFC6716 c= lause 2.1.4 one would need to use the "repacketizer". That is if I want to= have a 120 ms packet, I would need to take two 60 ms packets generated by= opus_encode(), extract out the compressed frames from each packet, concate= nate them and put on a new TOC with frame count code &q...

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 decoder operates properly. Is there any test...

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..."

Dear all, in chapter 2 of http://jmvalin.ca/papers/aes135_opus_celt.pdf it is mentioned, that encoder and decoder has an algorithmic delay of 6.5 ms (lookahead and resampling delay). In Table 54 of https://tools.ietf.org/html/rfc6716 different delays for the resampler of the SILK encoder are given. However, I measure the same round trip delay for opus encoder->decoder regardless which maxplaybackrate I use. The round trip delay corresponds to the 6.5 ms. Therefore my question: How is this 6.5 ms algorithmic delay distribut...

...ecified in https://tools.ietf.org/html/rfc7845.html > 3) is there any information OPUS payload has(except TOC(first byte))??? The first several bytes define how the audio is split into frames, the duration, audio bandwidth, and the coding mode. This is described in https://tools.ietf.org/html/rfc6716#section-3.1 > 4) I have RAW opus packets now, I want to convert it to representable > files, integer, float any method?? or any help (decoder)?? You need to call `opus_decoder_create` to set up a decoder instance, and then pass each successive payload buffer to `opus_decode` or `opus_decod...

Hi All, I have taken ITU standard 48KHz female voice file and Encoded using opus_demo by giving follwoing arguments. opus_demo -e audio 48000 1 32000 female1.pcm female1frame.opus And using repacketiser tried to pack 6frames/packet(6*20msec=120msec). While packing I observed below error for 3 times. Error: opus_repacketizer_cat() failed: corrupted stream when i inspect the encoded file, it

I encode with opus 20ms.The datalen is 24 bytes, but according the rfc6716 the length is 0d . Can anybody explain this? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20170302/25194cdc/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed......