search for: terriberri

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

It's not that hard to repackage it, is it? Here you go: www.icer.nl/misc_stuff/flac.xcodeproj .zip On 06-05-13 23:37, Marcus Johnson wrote: > 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

Am 04.02.2015 um 12:31 schrieb Timothy B. Terriberry: > M. Pabis wrote: >> 1. Each thread deals with frames from intra frame up to next intra frame >> - 1; > > This works if you know where the intra frames are. Could this information be gathered by having one thread encode a downsampled version of the input video sequence, or would this be a bad predictor? Who knows,

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

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

Linfeng Zhang wrote: > +#ifdef SMALL_FOOTPRINT > + for (i=0;i<N-7;i+=8) > + { > [snip over 80 lines of complicated NEON intrinsics code] > + } > +#else So, one of the points of SMALL_FOOTPRINT is to reduce the code size on targets where this matters (even if it means running slower), but this is an awful lot of code. I think it makes much more sense to expose the

> 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

Many people have run opus on small embedded devices. It may be the case that your VLA support isn't providing enough stack. You may want to try using the pseudostack mode which will instead put that memory on the heap and give you better control over making sure you have enough available. On Tue, Jun 4, 2024 at 10:28?AM Leonid Shigris <LeonidS at riscogroup.com> wrote: > > Hi

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

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

On 5/5/2013 09:03, Timothy B. Terriberry wrote: > Robert Kausch wrote: >> The _lseeki64 patch probably is a little more controversial. The problem >> is that fseeki64 and ftelli64 are not available in Windows XP - at least >> not without installing extra MSVC runtime libraries. I changed compat.h >> and replaced them with calls to _lseeki64, which was available at least

On 30 January 2015 at 02:41, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Zhongwei Yao wrote: >> Hi, all, >> >> Does Opus need celt_pitch_xcorr? s fixed point version for ARM aarch64 >> architecture? If yes, which version does Opus prefer: assembly or >> instrinsics? > > It would be nice to have one. I don't have a lot of experience with

I'm trying to get these cleaned up and landed, but I'm running into some trouble with this patch. Using commit a08b29d88e3c (July 21) of Ne10, I'm seeing test failures for 60-point FFTs: nfft=60 inverse=0,snr = -3.312408 ** poor snr: -3.312408 ** nfft=60 inverse=1,snr = -16.079597 ** poor snr: -16.079597 ** All other sizes tested appear to work fine (84 to 140 dB of SNR). This

On Tue, Apr 19, 2016 at 10:20 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > So the important question is "can an existing decoder (assuming it knows > about the ambisonics channel mapping) decode your file?". If the answer > is yes, then it's just an encoder-only change and it's easy to add to > the code base. If the answer is no, then it's actually a

On 29 April 2015 at 17:22, Timothy B. Terriberry <tterribe at xiph.org> wrote: > > Viswanath Puttagunta wrote: >> >> This patch series is follow up on work I posted on [1]. >> In addition to what was posted on [1], this patch series mainly >> integrates Fixed point FFT implementations in NE10 library into opus. >> You can view my opus wip code at [2]. >

Thank, Timothy! I add this stages. About RLE: I have one more unresolved stage. Mike Melanson wrote in "VP3 Bitstream Format..." about RLE using: "* Zigzag Ordering: After transforming and quantizing a block of samples, the samples are not in an optimal order for run length encoding. Zigzag ordering rearranges the samples to put more zeros between non-zero samples." If we pass

Hi, thanks for some On Wed, Feb 4, 2015 at 5:17 AM, Timothy B. Terriberry <tterribe at vt.edu> wrote: I don't believe anyone has been working on this for some years. There are > two basic approaches. > > One is threading within a single frame, which does not require any API > behavior changes. In theory you can scale to a fairly decent number of > threads everywhere

On 5.5.2013 18:02, Timothy B. Terriberry wrote: > > Instead I've attached a patch that uses fgetpos/fsetpos. This is > totally untested (I haven't even checked it compiles), but the idea > should work. > You people do realize these hacks would only be required for 10+ year old obsolete compilers?

Timothy B. Terriberry wrote: > Instead I've attached a patch that uses fgetpos/fsetpos. This is > totally untested (I haven't even checked it compiles), but the idea > should work. MSDN says "The pos value is stored in an internal format and is intended for use only by *fgetpos* and *fsetpos*." (http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx), so

Ozkan Sezer wrote: > On 8/21/13, lvqcl <lvqcl.mail at gmail.com> wrote: > > 1) Some time ago all project files for MSVC 6 were removed; it makes sense > > to remove the code that is necessary only for MSVC 6 and older compilers. > > > > One may still compile using command line instead of a project file. Does > it really hurt keeping such code? Its crufty old