I was looking for Java based video player, no, I don´t need it. Just to see if, and how many Java video players are there. To my big surprise, I found none. At least none any popular one, such as VLC,WMP and so. I thought there are some Java alternatives for those players.
Obviously I found instead many statements that Java is too slow for players. And from what I read it could be separated into 2 sub-problems:
First, poeple writing about Java beeing too slow for video decoding. But since I started with Java, I always thought its speed is actually pretty good. I found many benchmarks when warmed JVM did almost as well as C++ written program. Like really well. I thought it was becaouse those benchmarks algorhytms were small, and repetetive, so JVM prepared those code compiled and from there it was fast. Maybe in bigger program, it would be actually much slower becouse of dynamic compilation. I don´t really know. But since Java is compiled into native code by JVM, all it really matters with speed is how much code and how fast it precompiles, right? Of course there are other differences, but the biggest one would be the actuall compilation.
And second, people writing that they have video decoder written in C++ and getting pictures data thru JNI. But they say Java is too slow to even paint those 30 FPS even HD Ready images. But why? I always thought that JVM uses the fastest method available to get its window in OS, and than manipulating its content internally. And if I pressume Java is fast enough (meaning C++ like) when JVM is "warmed", where is the problem with displaying images? all JVM has to do in that case is to write array to OS specific display output, right?
So, is Java really slow, or am I missing something? Would it be posssible to have full speed (or almost full speed) video player written in pure Java? And if not, why? Thanks.
Third google hit for "video playback java" seems relevant: http://blog.pirelenito.org/2008/08/java-movie-playback-jogl-fobs4jmf/
I am not familiar enough with the subject to give a definite answer, but I can expand on certain points you raise:
But since Java is compiled into native code by JVM, all it really matters with speed is how much code and how fast it precompiles, right? Of course there are other differences, but the biggest one would be the actuall compilation.
There are a couple points I'd not dismiss out of hand. For one, the Java spec mandates that prior to every access to an array element, the runtime must check that the index is valid, i.e. that 0 <= index && index < array.length
. I imagine that video decoding will use arrays heavily, so Java arrays may not be the best fit for that task.
But they say Java is too slow to even paint those 30 FPS even HD Ready images. But why? I always thought that JVM uses the fastest method available to get its window in OS, and than manipulating its content internally. And if I pressume Java is fast enough (meaning C++ like) when JVM is "warmed", where is the problem with displaying images? all JVM has to do in that case is to write array to OS specific display output, right?
Cough ... I would not call the default renderer for the Java 2D API efficient. At least on my computer, direct Open GL calls through JOGL are a lot most efficient (roughly factor 10) that using the API provided by the JDK. I suspect that the difference between software and hardware rendering at work ... But that not mainly a fault of the language, but of its standard library. Nobody in their right mind would do high performance graphics without hardware acceleration, regardless of programming language.
Also, rendering is usually more than just copying an array, for instance zooming, color space transformations, and buffering (to avoid tearing).
Bottom line: I think it is possible to do video playback in Java, but it will most likely require to use a native library to access hardware acceleration, and probably be somewhat less efficient than a pure native solution.
Special purpose video players have been created, see e.g. http://groups.csail.mit.edu/graphics/pubs/spie3528-26.pdf for some older publication.
General purpose libraries are not in widespread use as current hardware supports video encoding / decoding. These extensions are not used by the JIT in most circumstances.
For many purposes hand crafted assembler code is still written. This task cannot be established by current compilers, and therefore not by the JIT. Some graphics hardware is also capable of accelerating the decoding. This is also not available to the JIT (at least in its current implementation). Therefore video-decoding is much slower using java compared to highly optimized code (some video players ship different versions of the same code for different CPUs).
These elaborations are taken for the i386-Platform. For platforms running java in hardware (e.g. embedded systems) they may not be valid any more.
精彩评论