similar to: [PATCH] promised MMX patches rc1

Hello, Here is my first speedup patch. Like 10-11%. No IDCT yet. Please feel free to comment my code or even better think about improvements. :) I belive my routines are not so bad, maybe one day they will be even more faster. What needs to be optimized is the loop filter fuction. I have no ideas now how to do it. It does not leave much space for parallel stuff, copying memory from lot of

Hello, I'm attaching IDCT MMX patch. I reused IDCT from theora-a3-MMXd.zip. It should work on 64bit X86 platform too. Here is most used functions when playing video with jet aircrafts (gripen) Ogg logical stream 310b2968 is Theora 720x480 29.97 fps video Encoded frame content is 720x480 with 0x0 offset I can play this video with like 200-300 frame drops on Athlon XP 1700+ CPU load (with

Hello, As we discussed with derf some time ago, it seems it is not neccessary to enforce "forward" order of dct_coeffs. This patch gains .99366902855226196000% so approx 1% speedup. Meausurement method: time nice -n -19 ./dump /mnt/disc4/theora/unix/gripen.ogg > /dev/null Ogg logical stream 310b2968 is Theora 720x480 29.97 fps video Encoded frame content is 720x480 with 0x0 offset

Hello, I would like to announce the semi-optimized oc_state_loop_filter_frag_rows It gains like 7% speedup. Unfortunately it has some issues: 1) wont compile on 64bit (I will fix it later hopefully) 2) is not yet fully optimized (instruction stalls) Here are the results. CPU: Athlon, speed 1466.91 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask

Hi, I'm attempting to decode Theora videos on a PowerPC running a Linux 2.6.19 kernel. The version of GCC I'm cross-compiling from is 3.4.4. The software versions I'm running are: libogg-1.1.3 libpng-1.2.20 libtheora-1.0beta1 libvorbis-1.2.0 These are all the latest I was able to download. Here's a back trace I got while running "dump_video" under

Good morning in the Lord Regarding the port of libtheora1.1beta3 for OpenBSD for amd64 and the problem I described at: http://lists.xiph.org/pipermail/theora/2009-August/002640.html Attached is a patch for libtheora/patches/patch-lib_x86_mmxencfrag_c I can play videos with it. ?Does it work for you? Best regards -- Dios, gracias por tu amor infinito.

Hi all-- I tried building the ARM-optimized theora codec from the theorarm- merge-branch, and encountered the following compile and runtime problems before getting something to run. If there is another way to build it, it would be nice to know, but I got the sense that its current state in svn is incomplete. I'm using a gcc cross-compiler for ARM on an x86 Linux PC. After running

quite some speed improvement indeed. attached the updated patch to apply to svn/trunk. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora-mmx.patch.gz Type: application/x-gzip Size: 8648 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040824/5a5f2731/theora-mmx.patch-0001.bin

Hi. Has anyone tried http://svn.xiph.org/branches/theora-mmx this code on Win32 ? I can compile it with very small modification, 304c304 < ogg_int16_t *const temp= (ogg_int16_t*)align_tmp; --- > ogg_int16_t *const temp= (int16_t*)align_tmp; but outputs seem terribly broken. -> ex. http://mycomputer.cc/temp/mmx-out.ogg GCC version is 3.4.2. $ gcc --version gcc.exe (GCC) 3.4.2

(i hope this is correct m.list) Hi, there is a small compiling problem for mingw when compiling on libogg.. in include/ogg/os_types.h : ogg_int64_t, ogg_int32_t, etc are defined correctly on cygwin and MSVC/Borland but not on mingw... i have attached a patch that will fix this problem (i hope it attaches correctly) thx, Nehal --- os_types.h.old Fri Jul 19 02:25:52 2002 +++ os_types.h Tue

When using the IDCT routines, the C version [ lib/idct.c: oc_idct8x8_c(ogg_int16_t _y[64],int _last_zzi)] in libtheora 1.1.1, the decoded image is garbled. Is it functionally equivalent to the MMX optimized version [lib/x86/mmxidct.c: oc_idct8x8_mmx(ogg_int16_t _y[64],int _last_zzi)] ? I used some of the Theora video files from here: http://wiki.xiph.org/index.php/List_of_Theora_videos for

Hi The Theora specification states, in section 7.9.3 ("The 1D Inverse DCT") steps 14-16: 14. Assign T[5] the value T[4] - T[5]. 15. Truncate T[5] to a 16-bit representation by dropping any higher-order bits. 16. Assign T[5] the value C4 * (-T[5]) >> 16. However, the relevant section of code in the reference decoder (lib/dec/idct.c line 50) is:

> I put debug code in a function in C, > but the function oc_enc_fdct8x8() not called. > Why? There is no function oc_enc_fdct8x8. It's a macro, which usually calls a platform-specific version via _enc->opt_vtable.fdct8x8, though on some platforms, it will call a specific version directly (e.g., oc_enc_fdct8x8_x86_64sse2 on x86-64). All of the functions with platform-specific

[Repost, maybe it will get noticed with a better subject] So now beta 4 is out is there any chance you guys will have time to review some of my patches? Here's a simple one. It just adds the standard integer typedefs for EMX GCC. I've flattened the structure using #elif's so it doesn't get a level deeper for every platform added but the result should be the same. I realise

Hi all, Just a stupid question The IDctSlow function on file idct.c has this line : ip[0] = (ogg_int16_t)((_Gd + _Cd ) >> 0); The ip[0] , _Gd and _Cd are of type ogg_int32_t My question is: The result of (_Gd + _Cd) can be a number with more than 16 bits ? (yes, it can be because they are int32, but the algorithm could guarantee something about that... I dont know...) If

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

In order to compile the latest Vorbis library on the Macintosh, the change appended to this message needs to be made to os_types.h.in. Then, anyone who wants to actually build it must first copy os_types.h.in to os_types.h by hand, since MacOS does not include a command line and thus cannot run configure. It really bugs me that the whole "platforms which don't support configure

After I got the libshout problem taken care of, I tried installing installing ices. It gave the following error: metadata.c:55: error: 'fd_set' undeclared (first use in this function) I searched the internet for fd_set and found that select uses it, which needs sys/time.h, which wasn't included in metadata.c, so I added #include <sys/time.h> with the other includes, and it seems

Hello, I'm new to OGG and I must say than it's impressive. I plan to use it in my project (BASIC programming langage) but I use LccWin32 as main C compiler (free and very powerful) and OGG has some difficulties to compile. I would like to know if it was already reported. If not, here it is: - Inline ASM functions for vorbis_itoa() isn't ok for LCC (not the same syntax than VC). I

This is also pretty simple. Just a small patch to configure.in to set the right compiler flags and changes to os.h to (a) not have deeply nested ifdefs, making the file needlessly hard to read, (b) break up the sections by functionality and (c) don't assume that every non-Win32 has the floating versions of math library functions. -tim Index: configure.in