From: Jonathan H. <jon...@ho...> - 2007-02-17 23:01:29
|
Hi, In general, the slowest part of the process appears to be the last step: applying motion compensation, the FFT and converting YUV to RGB. I believe that this is mainly because of the array access speeds in Java - with C you can just take a pointer, Java has a lot of overhead. Other stupid mistakes I made (and that probably applies to the MP3 codec) is to use float rather than integer arithmetic. Floating point calculations are slow on x86 because the standard FPU instructions do not match the JVM specifications At the end of the day, I haven't been doing too much by way of optimisation and profiling. I simply bought a faster computer :). As with all Open Source software, everyone has different requirements. If you manage to get some good speed ups, then please post back some patches to this mailing list for other people to use. JH Pan steven wrote: Dear Sirs: Recently i wish to use jffmpeg's mp3 plugin to replace the Jlayer's mp3 player in my application. however, some mp3s broken while playing. i am not familiar with these codes, does anyone could give me some clue( e.g. known problems)? I plan to spend some time to fix it , is possible. By the way, the pure java divx decode seems take a lot of CPU usage compared with a native divx player. In my P4 machine, native player(VLC) plays a 320x256 divx video only use 2-5% CPU time. While the pure java decoder use around 12-18% CPU time. From my expericene , for simple algorithm programs, java's speed is just as fast as C++( e.g. no object, only array, data, common mathematica operation). Then what's the cause of the slowness in java divx decoder? is it caused by the native code's Intel MMX code? Or are there any other reason? If could be solved, i wish i can improve it a bit. Could somebody give me some hints? _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ |