我一直在寻找基于Java的视频播放器，不，我不需要它。只是为了看看是否有多少Java视频播放器。令我惊讶的是，我没有找到。至少没有任何流行的，如VLC，WMP等。我认为这些玩家有一些Java选择。
显然，我发现许多声明认为Java对于玩家来说太慢了。从我读到的内容可以分为两个子问题：
首先，关于Java beeing的文章写作对视频解码来说太慢了。但是自从我开始使用Java以来，我一直认为它的速度实际上非常好。当温暖的JVM几乎和C ++编写的程序一样好时，我发现了许多基准测试。真的很好。我认为这是因为那些基准测试算法很小而且具有重复性，因此JVM准备了那些编译好的代码并且从那里开始很快。也许在更大的程序中，由于动态编译，它实际上会慢得多。我真的不知道。但是由于Java被JVM编译成本机代码，因此速度真正重要的是代码的多少以及预编译的速度，对吧？当然还有其他差异，但最大的差异是实际编译。
第二，人们写道他们有用C ++编写的视频解码器并通过JNI获取图片数据。但是他们说Java甚至无法绘制30张FPS甚至HD Ready图像。但为什么？我一直认为JVM使用最快的方法在OS中获取其窗口，而不是在内部操纵其内容。如果我在JVM“加热”时压缩Java足够快（意思是C ++），那么显示图像的问题在哪里？在这种情况下，JVM必须做的就是将数组写入OS特定的显示输出，对吧？
那么，Java真的很慢，还是我错过了什么？是否可以使用纯Java编写全速（或几乎全速）视频播放器？如果没有，为什么？谢谢。
答案 0 :(得分：4)
第三次谷歌搜索“视频播放java”似乎相关： http://blog.pirelenito.org/2008/08/java-movie-playback-jogl-fobs4jmf/
我对该主题不够熟悉，无法给出明确答案，但我可以扩展您提出的某些观点：
但是由于Java被JVM编译成本机代码，因此速度真正重要的是代码的多少以及预编译的速度，对吧？当然还有其他差异，但最大的差异是实际编译。
有几点我不会失控。首先，Java规范要求在每次访问数组元素之前，运行时必须检查索引是否有效，即0 <= index && index < array.length。我认为视频解码将大量使用数组，因此Java数组可能不适合该任务。
但是他们说Java甚至无法绘制30张FPS甚至HD Ready图像。但为什么？我一直认为JVM使用最快的方法在OS中获取其窗口，而不是在内部操纵其内容。如果我在JVM“加热”时压缩Java足够快（意思是C ++），那么显示图像的问题在哪里？在这种情况下，JVM必须做的就是将数组写入OS特定的显示输出，对吗？
咳嗽......我不会高效地调用Java 2D API的默认渲染器。至少在我的计算机上，通过JOGL直接Open GL调用使用JDK提供的API是非常有效的（大约10倍）。我怀疑工作中软件和硬件渲染之间的区别......但这主要不是语言的错误，而是标准库的错误。无论编程语言如何，如果没有硬件加速，没有人能够做出高性能的图形。
此外，渲染通常不仅仅是复制数组，例如缩放，颜色空间转换和缓冲（以避免撕裂）。
结论：我认为可以用Java进行视频播放，但很可能需要使用本机库来访问硬件加速，并且可能比纯本机解决方案效率低一些。
答案 1 :(得分：1)
已创建专用视频播放器，例如http://groups.csail.mit.edu/graphics/pubs/spie3528-26.pdf用于某些较旧的出版物。
通用库未广泛使用，因为当前硬件支持视频编码/解码。在大多数情况下，JIT不使用这些扩展。
出于许多目的，仍然编写手工制作的汇编程序代码。当前编译器无法建立此任务，因此JIT也无法建立此任务。一些图形硬件也能够加速解码。这也不适用于JIT（至少在其当前实现中）。因此，与高度优化的代码相比，使用Java的视频解码要慢得多（一些视频播放器为不同的CPU提供不同版本的相同代码）。
这些详细说明是针对i386-Platform进行的。对于在硬件中运行java的平台（例如嵌入式系统），它们可能不再有效。