3

Java ベースのビデオ プレーヤーを探していましたが、必要ありません。Java ビデオ プレーヤーがあるかどうか、およびその数を確認するだけです。驚いたことに、何も見つかりませんでした。少なくとも、VLC、WMP などの一般的なものはありません。これらのプレイヤーには Java の代替手段がいくつかあると思いました。

明らかに、Java はプレーヤーにとって遅すぎるという多くのステートメントを見つけました。そして、私が読んだことから、それは2つのサブ問題に分けることができます:

まず、ビデオのデコードには Java が遅すぎると書いている人がいます。しかし、Java を使い始めて以来、Java の速度は実際にはかなり優れているといつも思っていました。JVM が C++ で書かれたプログラムとほぼ同じように動作するとき、多くのベンチマークが見つかりました。本当によく似ています。これらのベンチマークアルゴリズムは小さく、反復的だったので、JVMはコンパイルされたコードを準備し、そこから高速だったからだと思いました。おそらく、より大きなプログラムでは、動的コンパイルのために実際にははるかに遅くなります。よくわかりません。しかし、Java は JVM によってネイティブ コードにコンパイルされるため、実際に速度で問題になるのは、コードの量とプリコンパイルの速度だけです。もちろん他にも違いはありますが、最大の違いは実際のコンパイルです。

次に、C++ で記述されたビデオ デコーダーがあり、JNI を介して画像データを取得していると書いている人がいます。しかし、彼らは、Java は遅すぎて、これらの 30 FPS でさえ HD 対応の画像を描画できないと言っています。しかし、なぜ?私は常に、JVM は OS でウィンドウを取得するために利用可能な最速の方法を使用し、そのコンテンツを内部で操作するよりも優れていると考えていました。また、JVM が「ウォーミング」されているときに Java が十分に高速である (つまり C++ のように) と私が主張する場合、画像の表示に関する問題はどこにあるのでしょうか? その場合、JVMがしなければならないのは、OS固有の表示出力に配列を書き込むことだけですよね?

では、Java は本当に遅いのでしょうか、それとも何か足りないのでしょうか? Pure Java でフル スピード (またはほぼフル スピード) のビデオ プレーヤーを作成することは可能でしょうか? そうでない場合、なぜですか?ありがとう。

4

2 に答える 2

4

「ビデオ再生 Java」の 3 番目の Google ヒットは関連しているようです: http://blog.pirelenito.org/2008/08/java-movie-playback-jogl-fobs4jmf/

私はこの件について明確な答えを出すほど詳しくはありませんが、あなたが提起した特定の点について詳しく説明することができます:

しかし、Java は JVM によってネイティブ コードにコンパイルされるため、実際に速度で問題になるのは、コードの量とプリコンパイルの速度だけです。もちろん他にも違いはありますが、最大の違いは実際のコンパイルです。

手放せないポイントがいくつかあります。1 つには、Java 仕様では、配列要素へのすべてのアクセスの前に、ランタイムがインデックスが有効であること、つまり0 <= index && index < array.length. ビデオのデコードには配列が多用されるので、Java 配列はそのタスクには最適ではないかもしれません。

しかし、彼らは、Java は遅すぎて、これらの 30 FPS でさえ HD 対応の画像を描画できないと言っています。しかし、なぜ?私は常に、JVM は OS でウィンドウを取得するために利用可能な最速の方法を使用し、そのコンテンツを内部で操作するよりも優れていると考えていました。また、JVM が「ウォーミング」されているときに Java が十分に高速である (つまり C++ のように) と私が主張する場合、画像の表示に関する問題はどこにあるのでしょうか? その場合、JVMがしなければならないのは、OS固有の表示出力に配列を書き込むことだけですよね?

咳... Java 2D APIのデフォルトレンダラーは効率的とは言えません。少なくとも私のコンピューターでは、JOGL を介した Open GL の直接呼び出しは、JDK によって提供される API を使用するよりもはるかに効率的です (約 10 倍)。ソフトウェアとハ​​ードウェアのレンダリングの違いは機能しているのではないかと思います...しかし、それは主に言語のせいではなく、その標準ライブラリのせいです。プログラミング言語に関係なく、ハードウェア アクセラレーションなしで高性能グラフィックスを実行できる人は、正気ではありません。

また、レンダリングは通常、配列をコピーするだけではありません。たとえば、ズーム、色空間の変換、バッファリング (テアリングを避けるため) などです。

結論: Java でビデオを再生することは可能だと思いますが、ハードウェア アクセラレーションにアクセスするにはネイティブ ライブラリを使用する必要があり、おそらく純粋なネイティブ ソリューションよりも効率が悪いでしょう。

于 2011-06-19T22:46:04.080 に答える
1

特別な目的のビデオ プレーヤーが作成されました。たとえば、古い出版物についてはhttp://groups.csail.mit.edu/graphics/pubs/spie3528-26.pdfを参照してください。

現在のハードウェアはビデオのエンコード/デコードをサポートしているため、汎用ライブラリは広く使用されていません。これらの拡張機能は、ほとんどの状況で JIT によって使用されません。

多くの目的のために、手作業で作成されたアセンブラ コードが今も書かれています。このタスクは、現在のコンパイラでは確立できないため、JIT では確立できません。一部のグラフィックス ハードウェアは、デコードを高速化することもできます。これも JIT では利用できません (少なくとも現在の実装では)。したがって、高度に最適化されたコードと比較して、Java を使用した場合のビデオのデコードは非常に遅くなります (一部のビデオ プレーヤーは、異なる CPU に対して同じコードの異なるバージョンを出荷しています)。

これらの詳細は、i386-Platform 用に作成されています。ハードウェアで Java を実行しているプラ​​ットフォーム (組み込みシステムなど) では、もはや有効ではない可能性があります。

于 2011-06-19T22:37:18.860 に答える