search for: terriberry

...at > flac-dev-owner at xiph.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of flac-dev digest..." > > Today's Topics: > > 1. Re: Bug fix and compatibility patches for 1.3.0pre4 > (Timothy B. Terriberry) > 2. Re: Bug fix and compatibility patches for 1.3.0pre4 > (Robert Kausch) > 3. Re: Bug fix and compatibility patches for 1.3.0pre4 > (Robert Kausch) > 4. Re: Bug fix and compatibility patches for 1.3.0pre4 > (Robert Kausch) > 5. Re: Bug fix and c...

...v-owner at xiph.org> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of flac-dev digest..." > > Today's Topics: > > 1. Re: Bug fix and compatibility patches for 1.3.0pre4 > (Timothy B. Terriberry) > 2. Re: Bug fix and compatibility patches for 1.3.0pre4 > (Robert Kausch) > 3. Re: Bug fix and compatibility patches for 1.3.0pre4 > (Robert Kausch) > 4. Re: Bug fix and compatibility patches for 1.3.0pre4 > (Robert Kausch) >...

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

...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 always a good argument :-) All in all, no strong preference from my side. koen. On Fri, Jun 20, 2014 at 12:40 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > KOEN VOS wrote: > >> current implementation is faster on a 32 or 16 bit processor. If you >> would find the opposite to be true (ie that a 64 bit implementation is >> faster on, say, a 32 bit ARM CPU) then perhaps we should reconsider....

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 gain? How much is the exact gain? Regards, hrishi

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

...t; than "Re: Contents of opus digest..." > > > Today's Topics: > > 1. [PATCH] SILK: use silk_memmove for potentially overlapping > areas (Tristan Matthews) > 2. Re: [PATCH] SILK: use silk_memmove for potentially > overlapping areas (Timothy B. Terriberry) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 4 Jul 2016 09:18:12 -0400 > From: Tristan Matthews <tmatth at videolan.org> > To: opus at xiph.org > Cc: Tristan Matthews <tmatth at videolan.org> > S...

...P IMXRT1060? By using opus_demo code (decoding part)? > > > Pls advise, > > Kind Regards, > Leonid Shigris > RT Engineer > > Email: LeonidS at riscogroup.com > > > -----Original Message----- > From: opus <opus-bounces at xiph.org> On Behalf Of Timothy B. Terriberry > Sent: Tuesday, 4 June 2024 13:17 > To: opus at xiph.org > Subject: Re: [opus] opus library issues > > [You don't often get email from tterribe at xiph.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > Leonid Shigris wrote: > > I...

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

...0968b31d74e54c2a Best Regards, Phil Wang > Date: Fri, 30 Jan 2015 17:41:22 -0600 > From: Viswanath Puttagunta <viswanath.puttagunta at linaro.org> > Subject: Re: [opus] [RFC PATCH v1 2/2] armv7(float): Optimize encode > usecase using NE10 library > To: "Timothy B. Terriberry" <tterribe at xiph.org> > Cc: "opus at xiph.org" <opus at xiph.org> > Message-ID: > <CAE+8thixRitZx8XBpQJZSHTOHDA-F4tQ7kR- > uANHghGdRHhUCQ at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 30 January 2015 at 02:38, Timot...

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

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

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

...an adaptive pre/post transform had to send side information, would it also need to go through the IETF process? > The first step is definitely to add a new channel mapping for ambisonics. Great, I'll write up something precise and send it out. On Tue, Apr 19, 2016 at 10:19 AM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > I'm assuming that the pre/post transform would be something like a > decorrelating transform on the channels, and the actual core parts of Opus > would not change. For that, I think an extra channel mapping is a reasonable > approach, without re...

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

...h.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of theora-dev digest..." > > > Today's Topics: > > 1. FPGA encode stages flow diagram (digital design) > 2. Re: FPGA encode stages flow diagram (Timothy B. Terriberry) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Mar 2011 20:42:59 +0300 > From: digital design <developer.fpga at gmail.com> > Subject: [theora-dev] FPGA encode stages flow diagram > To: theora-dev at xiph...

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 &g...

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*.&q...

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