similar to: [Fwd: Re: Theora mcomp tuning...]

Hi there. This patch changes the block selection to quantify error based on the sum of the squared differences of the pixel values rather than the sum of the absolute differences, the former conventionally and statistically seeming like the preferable thing to do. The patch also const'ifies some parameters (which doesn't affect code quality on recent GCCs but might help on older/ other

Hi all, I am trying to build the mmx version of the theora and the encoderwin is throwing the following errors. 1>------ Build started: Project: encoderwin, Configuration: Debug Win32 ------ 1>Linking... 1> Creating library encoderwin.lib and object encoderwin.exp 1>LINK : warning LNK4098: defaultlib 'LIBCMTD' conflicts with use of other libs; use /NODEFAULTLIB:library

I have tried to add a plunging to the "libtheora-1.0beta2" (network bandwidth measuring component was added) and Got it success for some far now the problem is when it is added the encoding process get extremely slow (around 20 seconds delay). I think that the problem is with my modified Makefile (some flag may have missed). the following is my modified Makefile.am which is in the

Hello, attached is a gzipped patch file to the lib/mcomp.c source file of theora (as of AnonCVS current version) that implements MMX and extended-MMX optimizations in the most frequently used functions of the encoder (as shown by gprof). This is more a proof of concept than a real request for inclusion into the source tree. My personal intent was more to look deeper into the MMX instruction set

Here is a patch that gets the theora_static.dsp project for VC6 building again. Aaron -------------- next part -------------- Index: win32/theora_static.dsp =================================================================== --- win32/theora_static.dsp (revision 13945) +++ win32/theora_static.dsp (working copy) @@ -41,7 +41,7 @@ # PROP Intermediate_Dir "Static_Release" # PROP

I would like to merge two parts of words to get a name of the data. First M3$N (invariable) and second is a number from 0001 to 3003 - M3$N0001,M3$N0002,...,M3$N3003. For example if I do it like this: my.data <- paste("M3$N",2456,sep="") I get > my.data [1] "M3$N2456" But I want to get something equivalent to my.data<- M3$N2456 Is there any way to do it?

Hello Carl, Can you send me libspeex compilated in eVC. And can you describe where and how set the FIXED_POINT flag in eVC. Thanks you. Regards. Rodrigo. <p>----- Mensaje original ----- De: "Carl Douglas"<CarlD@itouchmobility.com> Env.: 15/01/04 17:43:43 Para: "speex-dev@xiph.org"<speex-dev@xiph.org> Asunto: RE: [speex-dev]

v1.0 of the forecasting bundle of packages is now on CRAN and will propagate to mirrors shortly. The forecasting bundle of R packages provides new forecasting methods, and graphical tools for displaying and analysing forecasts. It comprises the following packages: * forecast: Functions and methods for forecasting. * fma: All data sets from Makridakis, Wheelwright and Hyndman

v1.0 of the forecasting bundle of packages is now on CRAN and will propagate to mirrors shortly. The forecasting bundle of R packages provides new forecasting methods, and graphical tools for displaying and analysing forecasts. It comprises the following packages: * forecast: Functions and methods for forecasting. * fma: All data sets from Makridakis, Wheelwright and Hyndman

R gurus, I've exhausted my search of online help. This is my last resort. We're running R-2.1.1. I've been told by one of the R users here that we cannot upgrade to the lastest version because of some python rpy wrapper dependency that hasn't caught up to the latest version of R. The software is running on Solaris 10 x86. Gcc version is 3.4.1. R is installed in

Anyone know of a company that makes a pass through ATA? By pass through I mean have an Ethernet switch built into the ATA, like most desktop phones have. All of the dual ethernet ATA's I have seen have WAN/LAN ports, not two LAN ports. I fooled around with DMZ etc...but it just doesn't work as well. Thermal -------------- next part -------------- An HTML attachment was scrubbed... URL:

The one I got was the download on the download page, the svn version seems to be working just fine On Tue, Apr 26, 2011 at 12:00 PM, <theora-dev-request at xiph.org> wrote: > Send theora-dev mailing list submissions to > theora-dev at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/theora-dev >

I have tried to add a plunging to the "libtheora-1.0beta2" (network bandwidth measuring component was added) and Got it success for some far now the problem is when it is added the encoding process get extremely slow (around 20 seconds delay). I think that the problem is with my modified Makefile (some flag may have missed). the following is my modified Makefile.am which is in the

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

>Paul E Wrote [snip] >Windows 2000 (although it's the same for all of them) doesn't read in >any mime-type to correctly identify a file, it just uses the extension. [snip] What if, at least for Windows, someone wrote a simple application which when associated with .ogg files and an .ogg file was opened simply read enough of the ogg stream to identify the type of content and then

On 11/09/2017 01:58 PM, Drew Allen wrote: > Attached is a quick patch that addresses a bug when exporting the matrix > from the encoder. Actually, I don't see what your encoder change is supposed to do. Are there cases where demixing_matrix->rows != nb_output_streams ? Cheers, Jean-Marc > Cheers, > Drew > > On Wed, Nov 8, 2017 at 4:44 PM Drew Allen <bitllama at

Hi Drew, Your ambisonics patch is already merged. Can you send a patch that applies to master? Jean-Marc On 11/08/2017 07:05 PM, Drew Allen wrote: > Hey Jean-Marc, > > I found a bug regarding exporting the matrix that wasn't always grabbing > the correct values, causing incorrect mixing behavior. This patch > resolves that issue. > > Cheers, > Drew > > On

Hi all, Attached is a quick patch that addresses a bug when exporting the matrix from the encoder. Cheers, Drew On Wed, Nov 8, 2017 at 4:44 PM Drew Allen <bitllama at google.com> wrote: > Sure, ill send that asap > On Wed, Nov 8, 2017 at 4:44 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > >> Hi Drew, >> >> Your ambisonics patch is already merged. Can

Hi Drew, Thanks for the update. Your patch is now in master. Now, it would be good if you could think of a way to reduce the stack usage as we discussed. Cheers, Jean-Marc On 11/07/2017 04:28 PM, Drew Allen wrote: > Here's another patch. Cheers! > > On Mon, Nov 6, 2017 at 10:08 AM Drew Allen <bitllama at google.com > <mailto:bitllama at google.com>> wrote: >

On 25 February 2015 at 19:54, Timothy B. Terriberry <tterribe at xiph.org> wrote: > 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. > > >