similar to: [PATCH]

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

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

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

> 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

Hi I am trying to build a new decoder in Java, I know there are a couple of java decoders already but they don't implement the bit of the spec I am having questions on Question 1) In section 8.6.2 it mentions "However, it is also possible to set [residue_begin] and [residue_end] to specify a range partially or wholly beyond the maximum vector size. Before beginning residue decode,

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.

Also some missing _src()s and cosmetic changes. --- src/gallium/programs/galliumut/Makefile | 5 + .../programs/galliumut/gen_uureg_opcodes.sh | 29 +++ src/gallium/programs/galliumut/uureg.h | 196 ++++---------------- 3 files changed, 71 insertions(+), 159 deletions(-) create mode 100644 src/gallium/programs/galliumut/gen_uureg_opcodes.sh diff --git

Hi, This patch adds Altivec-optimized implementations of oc_enc_frag_sad and oc_enc_frag_ssd. This patch is against the latest svn revision of theora-ptalarbvorm. Speeds up encode on a plant stop-motion clip on a 1 GHz PPC 7447 by ~3%, timewise. Time spent in oc_enc_frag_sad is reduced from 4.2% to 2.3% and oc_enc_frag_ssd from 1.2% to 1.0%, as reported by Shark. Currently this is only

With virtio-1, we support more than 32 feature bits. Let's extend both host and guest features to 64, which should suffice for a while. vhost and migration have been ignored for now. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 2 +- hw/char/virtio-serial-bus.c | 2 +-

With virtio-1, we support more than 32 feature bits. Let's extend both host and guest features to 64, which should suffice for a while. vhost and migration have been ignored for now. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 2 +- hw/char/virtio-serial-bus.c | 2 +-

With virtio-1, we support more than 32 feature bits. Let's extend both host and guest features to 64, which should suffice for a while. vhost and migration have been ignored for now. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 2 +- hw/char/virtio-serial-bus.c | 2 +-

With virtio-1, we support more than 32 feature bits. Let's extend both host and guest features to 64, which should suffice for a while. vhost and migration have been ignored for now. Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- hw/9pfs/virtio-9p-device.c | 2 +- hw/block/virtio-blk.c | 2 +- hw/char/virtio-serial-bus.c | 2 +-

Old qemu versions required that 1st s/g entry is the header. My recent patchset titled "virtio-net: iovec handling cleanup" removed this limitation but a feature bit is needed so guests know it's safe to lay out header differently. This patch applies on top and adds such a feature bit. virtio net header inline with the data is beneficial for latency and small packet bandwidth.

Old qemu versions required that 1st s/g entry is the header. My recent patchset titled "virtio-net: iovec handling cleanup" removed this limitation but a feature bit is needed so guests know it's safe to lay out header differently. This patch applies on top and adds such a feature bit. virtio net header inline with the data is beneficial for latency and small packet bandwidth.

Hi. I?m trying to use the speex library in c#, everything seems to works right, when I call the speex_encode_int function it always return 0, any help would be appreciated. Here?s the sequence of calls: //Initialization _Mode = speex_lib_get_mode(0); _State = speex_encoder_init(_Mode); fixed (int* __FrameSize = &_FrameSize, __Complexity =

From: Amos Kong <akong at redhat.com> In virtio-net guest driver, currently we write MAC address to pci config space byte by byte, this means that we have an intermediate step where mac is wrong. This patch introduced a new control command to set MAC address, it's atomic. VIRTIO_NET_F_CTRL_MAC_ADDR is a new feature bit for compatibility. "mac" field will be set to read-only

From: Amos Kong <akong at redhat.com> In virtio-net guest driver, currently we write MAC address to pci config space byte by byte, this means that we have an intermediate step where mac is wrong. This patch introduced a new control command to set MAC address, it's atomic. VIRTIO_NET_F_CTRL_MAC_ADDR is a new feature bit for compatibility. "mac" field will be set to read-only