Slashdot Mirror
Theora Codec Ported to Java
fons writes "These guys have ported the Theora codec to Java. This means that ANY Java-capable browser can now be used to watch video streams on the net (clients don't have to download a player!). You can watch a demo showing some boring guys sitting in the office. At least the music is ok :) On their site you can find a link to an interesting interview with the
boss, and it looks like more cool stuff is coming soon."
For Real and Apple to reimplement and promote their own codecs the same way. Well, if we really want it - because Theora really does well.
BTW, I did not realize that mine was the usual FP!!
Cb..
For some reason it seems to load faster than realplayer, quicktime or windows media player.
.Net apps like RSS Bandit! Its actually a real option for anyone wanting to stream video.
/.
I am using Java 5 RC which for me GUI program feel faster than
Also, please note I do feel dirty calling it Java 5...
And nice work putting a video stream on the front page! Thats nice and considerate
Don't discount the business value of these open formats - for a hardware or tools vendor it is one less license to pay.
Clients still have to download the player, it's just that the player is now in a form which is downloaded with less effort.
[
I'm sure that doing the whole thing in ActiveX would be cake.
This can just be the web page embedded client for non-windows machines.
There are no trails. There are no trees out here.
Since there's a port to Java, is there anybody willing to port to .NET or Mono?
So you think with Flash you will be able to develop new codecs like this without updating flash plugin in your computer? You are confusing things badly dude..
I just tried it in both Firefox and IE. It looks great (sounds good too) and it loads really quickly! I hope sites start switching to this rather than using real media or WMV streams for windows media player.
I'm getting about 15% processor utilization on my P4 2.4Ghz. Loads really quickly and the video quality seems pretty good.
I'd bet that a lot of the CPU utilization comes from the fact that it wouldn't be using direct draw like most players would rather than any codec issues.
Wonder if jdk 1.5 would make a difference in CPU.
The fact is that faster computers have not really resulted in us running the same programs faster. It's resulted in us running bigger, fancier programs at the same speed we always have.
It took about 3 minutes for my 20 Mhz 286 to boot up. It takes about that long for my 2 Ghz Athlon to do the same.
What's the difference? Go on back and USE that 80286 AT for a while, and tell me what that software "bloat" really got you...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Ok, so where are the JVM exploits?
Javascript is NOT java, so saying "Javascript is vulnerable, so Java must be" is pointless.
I'm not necesarily saying that java isn't a security hole, I'm just asking that if you're making the claim, then make sure the evidence you provide is relevant.
as for 2, what you said there applies to all media players.
WMP, Quick Time, Real One, they all eat memory and processor cycles.
Have you actually tried it? I don't think that you can claim that it will bog down the machine and be worthless until you try it yourself.
I haven't tried it either, so I can't say that you're wrong, but there is nothing in your post that gives any real evidence as to why this codec is worthless. Speculation is not evidence.
Advanced users are users too!
Lots of people have built Java applet video players. Fluendo isn't claiming to be the first; they're claiming to have the first Theora Java player.
Do you have the source to your software available for all to use, free of charge? No? Didn't think so.
These guys aren't claiming to have invented a java media player, they simply ported an open source codec to a different platform. And they're doing it for free, for anyone to benefit.
everyday is another shooter.
That's a claim which is unproven. There are applications where gcj provides a significant speed-up, and there are others where Sun's JIT-VM runs faster. But it's not necessarily a fair comparison: Sun has spent a lot of resources on a smart and highly-tuned implementation, but there has been comparitively little work on Java-specific optimizations in GCJ. (Most of the effort has focused on functionality, especially the libraries.)
It is also worth noting that pre-compiled applications start up faster (and people are working on improving this further).
1. JVM != Java. See gcj. Or mips2java. Of course, because the JVM architecture is optimized for Java code, C/C++ code doesn't get as efficiently compiled into JVM code. This is no advantage of Java, it is a poor design of the JVM.
You should write "VM" in that case. Virtual Machine. Not JAVA Virtual Machine.
And gcj does have a java virtual machine as well. You don't have to compile to native.
Precompiling does offer advantages, at least at this point:
While there are almost always "exceptions to the rule", it's been proven out in the real world that precompiled Java generally doesn't offer performance advantages over non-precompiled Java using modern JVMs such as Sun's and IBM's, with some exceptions such as startup time.
1) More efficient binary code. Seriously, if you think you can make Java generate more efficient code than the Intel C compiler in a general purpose situation, you be my guest but you are going to lose. Intel has an extremely efficient compiler for the precompiled world and in general precompiled stuff, even on just an ok compiler, is faster than JIT.
Except we're not talking about C, we're talking about Java.
2) Access to native resources. Java abstracts everything by necessity to pull cross platform compatibility. Fine, but there is a reason for things like DirectDraw, ASIO, OpenGL, etc to exist. For video, using DirectDraw is a major performance boost. You can do it C++, you can't do it in Java.
Except we're not talking about DirectDraw, ASIO, OpenGL, etc. We're talking about Java.
Now neither of these are things that are necessiary perminant truths. It is, in theory, possible to make a JIT compiler generate as or more efficient code to a precomiler. It is also possible, in theory, to modify Java such that it can directly access accelerated OS features.
However the theoritical future has nothing to do with now. At this point, precomiled code is more efficient (in some cases quite a lot) and Java does not provide access to accelerated features. There is a REASON that Doom 3, UT 2004, etc are written in a language that precomiles to native code. Both seek to be cross platform (and UT 2004 is to an amazing extent) however Java is NOT the right tool for them at this time.
So while I certianly think something like this is cool and valuable, and am glad to see it implemented, don't think that it'll be as fast or efficient as a native player compiled with ICC.
The OP was theorizing about precompiling Java to achieve better performance. Not about using the Intel C compiler, or Java's ability (or lack thereof) to call APIs such as DirectDraw, etc.