similar to: opus repacketizer

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

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

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?

Hello, I had talked earlier with 'Timothy B. Terriberry' <tterribe at xiph.org>, about adding support for AVX instructions in Opus, but since he appears to be busy I would like to resend this on the mailing list. I've created a pull request https://github.com/xiph/opus/pull/5 to add the testing infrastructure for the changes before adding the actual code. A draft for the rest

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,

If anyone is integrating Opus audio into a web or JavaScript application, I wrote a WebAssembly Opus decoder that uses libopusfile to decode Opus files in chunks using the JavaScript Streams API. This decoder can begin decoding after receiving the Opus headers and first audio data page: https://github.com/AnthumChris/opus-stream-decoder All thoughts and contributions are welcome, and I'm

Hi all, I have already added support for scaled forward non-power-of-2 floating-point FFT: https://github.com/projectNe10/Ne10/commit/79c3d787302f8d74b9bcfe6545d487cdf1b101d9 Two flags are added to cfg structure: is_forward_scaled and is_backward_scaled. By setting is_forward_scaled to anything but zero, ne10_fft_c2c_1d_float32_neon will scale the output. So we can remove need for one buffer on

Yes those instructions exist, although they're a bit slower than the basic 16x16->32 with 32-bit accumulation (SMLABB). So I'd be surprised if the function with 64 bit accumulation would run as fast as the current code. Don't know how much we care about 16-bit platforms. And accuracy should not matter. On the other hand, a 64-bit implementation is much cleaner/shorter, which is

Thanks Jean-Marc and Benjamin for the answers. One follow-up question. If I use a repacketizer as Jean-Marc suggested by combining two 60ms frames to form a 120ms frame, without extracting individual frames and using a new TOC, I would need to have a "de-packetizer" that does the exact opposite of repacketizer. De-packetizer would need to separate this 120ms frame into two 60ms frames

> I don't believe this is an actual error. If it's truly possible for > these areas to overlap (I don't think it is), then something much more > serious than using memmove instead of memcpy needs to be done about it. In the C# version of this code, these two copy regions are stored in separate arrays entirely. I agree that there should be no normal way to have the memcpy

Ralph, for Mac OS you should download either the Unarchiver which is free, or Entrophy which is what I use, but it costs like $15 I believe, both support decompressing .7z and Entrophy supports compressing TO .7z On Mon, May 6, 2013 at 3:00 PM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or

Hi Jean-Marc, Thanks so much for your review. Attached are my comments and an updated patch. On Mon, Oct 30, 2017 at 5:48 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I've had some time to dig more deeply into your patch. Here's some more > in-depth comments: > > 1) I note that your OpusMSEncoder struct in private.h adds a > subframe_mem[]

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

Dear all, I have been going through below mentioned update. http://web.mit.edu/xiphmont/Public/theora/demo.html I found this line- Timothy Terriberry estimates a simple self-training range-coding backend could be reasonably expected to decrease bit usage overhead by 15-20%. Is it really true? I found one implementation.... http://svn.xiph.org/trunk/ghost/libentcode/ Did anyone verified this

Hello, I am new to opus and C, so please forgive my basic question. I am trying to trim a file to remove an extract at a specified starting and ending time -- an example would be to save an excerpt from a song as a ringtone. What is the best way to accomplish this? I have been trying to use op_pcm_seek, and the documentation for op_pcm_seek says "Seek to the specified PCM offset, such that

Viswanath Puttagunta wrote: > What should we do for power-of-2? I really want to avoid putting > runtime checks if nfft is power of 2 in opus_fft_float_neon. Given the tests that had to be disabled for NE10, I suspect we will not really be able to use it for CUSTOM_MODES, which should be the only time nfft is a power of 2. So I'd suggest just disabling the support when CUSTOM_MODES

Viswanath Puttagunta wrote: > Can we please have review on RFCv2? We have quite a few optimizations > (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward > etc) that are in my pipeline that depend on this patch series being > accepted. So, trying to make progress on this... On an armv7l board running Ubuntu, you've broken the build with just --enable-intrinsics

It seems there still isn't a tool (at least not a Xiph one) for modifying Opus comments from the command line. I've had a go at adding support in liboggz (which is fairly trivial, since it just means adding recognition for the Opus stream). That certainly works for comment editing, but I'm not sure if it's is good enough to commit back, because timing gets reported back slightly

It seems there still isn't a tool (at least not a Xiph one) for modifying Opus comments from the command line. I've had a go at adding support in liboggz (which is fairly trivial, since it just means adding recognition for the Opus stream). That certainly works for comment editing, but I'm not sure if it's is good enough to commit back, because timing gets reported back slightly

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