多くの J2ME 電話の (非常に厄介な) 制限により、オーディオ ファイルは完全にダウンロードされるまで再生できません。そのため、ライブ ストリームを再生するには、一度にチャンクをダウンロードしてByteArrayInputStream
s を作成し、それを Player にフィードする必要があります。
これはうまく機能しますが、ストリームが終了して新しいストリームが必要になるたびに約 1/4 秒の厄介なギャップがあることを除けば. この問題、または上記の問題を解決する方法はありますか?
J2ME JSR135 で長い (3 分以上の) トラックを適度に確実に再生する唯一の良い方法は、プレーヤーを作成するときに「file://」URL を使用することです。入力ストリームは実際には FileConnection から来ています。
最近の BlackBerry 電話は、利用可能な Java ヒープ メモリが大きい場合にのみ ByteArrayInputstream を使用できます。
Symbian オペレーティング システムで実行されている多くの電話では、同じ場所でトラックを再生しながら、J2ME アプリケーション用のプライベート エリアにファイルを置くことができます。
残念ながら、少なくとも私が試したどのデバイスでも、これらのギャップを取り除くことはできません. 本当に迷惑です。HTTP 経由でオーディオまたはビデオをストリーミングできないのは、仕様の一部です。
サーバーからストリーミングしたい場合、唯一の方法はRTSPサーバーを使用することですが、デバイスでこれがサポートされていることを確認する必要があります。
また、デバイス上のローカル サーバー (rtsp://localhost...) を使用して RTSP を偽装しても機能しません。私も試しました。
EDIT2: または、まさにあなたが望むものと思われるこれを見ることもできます: http://java.sun.com/javame/reference/apis/jsr135/javax/microedition/media/protocol/DataSource.html
2 つの Player クラスを作成し、再生を開始する前に十分な量のチャンクを受け取ったことを確認します。次に、プレーヤー 1 で最初のチャンクの再生を開始し、2 番目のチャンクをプレーヤー 2 にロードします。次に、TimeBase クラスを使用して経過時間を追跡し、最初のチャンクが終了することがわかったら (各チャンクの再生時間を知っておく必要があります)、2 番目のプレーヤーで 2 番目のチャンクの再生を開始し、再生するチャンクがなくなるまで、3 番目のチャンクを最初のチャンクにロードし、以下同様にロードします。
ここで重要なのは、TimeBase クラスを適切に使用して、いつ移行するかを知ることです。これでチャンク間の 1/4 秒のギャップ ベットが解消されると思います。私はそれがうまくいくことを願っています.
編集: Player.prefetch() は、ここでレイテンシを短縮するのにも役立ちます。