53

Android MediaPlayer がさまざまなストリームでのライブ ストリーム再生の準備にかかる時間に大きな違いがあることを発見しました。

ハードデータ

prepareAsync() と onPrepared(MediaPlayer mp) コールバックの間にログを追加し、複数のストリームをそれぞれ数回テストしました。各ストリームの時間は非常に一貫しており (+/- 1 秒)、結果は次のとおりです。

  1. MPR ニュース ストリーム: 27 秒 (http://newsstream1.publicradio.org:80/)
  2. MPR クラシック音楽ストリーム: 15 秒 (http://classicalstream1.publicradio.org:80/)
  3. MPR 現在のストリーム: 7 秒 (http://currentstream1.publicradio.org:80/)
  4. PRI ストリーム: 52 秒 (http://pri-ice.streamguys.biz/pri1)

テストは、3G 接続 (~1100 Kbps) 上の Android 2.3.4 を搭載した Nexus S で実行されました。

非ストリーミング MP3 オーディオ ファイルの再生は問題ありません。

ストリームを再生する方法のスニペットを次に示します。

MediaPlayer を準備します。

...
mediaPlayer.setDataSource(playUrl);
mediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC);
mediaPlayer.prepareAsync();
...

次に、onPrepared(MediaPlayer mp) で:

mediaPlayer.start();

一部のストリームを準備するのに時間がかかり、他のストリームを準備できないのはなぜですか? 上記のデータは、バッファリングされたオーディオ コンテンツの長さではなく、バッファリングされたデータの量に基づいている可能性があることを示唆しているようです。これは本当にありえますか？

更新: Android 1.6、2.2、および 2.3.4 を搭載した物理デバイスと、1.6、2.1、2.2、2.3.1、および 2.3.3 を搭載したエミュレーターでライブ ストリーミングをテストしました。2.3.3 と 2.3.4 でのみ長い遅延が見られます。古いバージョンは 5 秒以内に再生を開始します。

4

6 に答える 6

26

一定時間ではなく一定量のデータをバッファリングしているようです。さまざまなタイプの NPR ストリームのビットレートを頭のてっぺんから知らない人のために、データは次のようになります。

  1. MPR ニュース ストリーム: 27 秒 ( http://newsstream1.publicradio.org:80/ )、64 kbps
  2. MPR クラシック音楽ストリーム: 15 秒 ( http://classicalstream1.publicradio.org:80/ )、128 kbps
  3. MPR 現在のストリーム: 7 秒 ( http://currentstream1.publicradio.org:80/ )、128 kbps
  4. PRI ストリーム: 52 秒 ( http://pri-ice.streamguys.biz/pri1 )、32 kbps

2 つの 128 kbps ストリーム間の不一致は別として、ビットレートとバッファリング時間の間には非常に良い相関関係があります。

いずれにせよ、Android はオープンソースなので、いつでも Androidの動作を確認できます。残念ながら、prepareAsync()とprepare()はネイティブ メソッドであり、バッファ関連のイベントもネイティブ プロセスからディスパッチされるようです。

を MediaPlayer にアタッチしOnBufferingUpdateListenerて、バッファ状態に関するより細かい更新を取得しようとしましたか? イベントが配信される速度と、さまざまなストリームの各イベントでバッファーが占める割合を比較することは興味深いかもしれません。ストリームのビットレートと相互参照できます。32 kbps での 4 秒間のバッファリングで、128 kbps での 1 秒間のバッファリングと同じ割合でバッファがいっぱいになる場合は、答えが見つかると思います。

于 2011-07-05T13:16:44.957 に答える
8

FFmpegMediaPlayerMediaPlayerによる切り替えは、ストリームをテストしたい場合は、ストリームが持っているデモを通じて行うことができるよりもはるかにうまく機能し ます。MediaPlayer

于 2015-05-27T23:36:12.157 に答える
5

最近、ストリーミングオーディオプロバイダーでこの同じ問題をデバッグしました。この問題は、32kbps以下のstagefrightおよびストリーミングソースに関連しています。24、32、48、64、および128kbpsでの応答時間を測定する同じストリーミングをステップ実行しました。

  • ストリーミングを開始するのに24->46秒
  • ストリーミングを開始するための32->24秒
  • ストリーミングを開始するのに48->2秒
  • 64->ストリーミングを開始するのに2秒
  • 128->ストリーミングを開始するのに2秒

これは、各ビットレートで平均10回の試行で一貫したワイヤレス接続によるものです。Travisが指摘したように、重要なのは、stagefrightがオーディオをバッファリングする時間を把握できないことでした。「エラー：1、-21492389」などのメッセージが表示されることがあります。これは、ステージ恐怖症のプレーヤーを黙ってクラッシュさせたようです。私はこれを追跡しようとしましたが、最終的に、非常に遅いストリーム（24 kbps未満）は、デバイスがオーディオストリームのスペースを使い果たすまでバッファリングするため、バッファオーバーフローを引き起こしているように見えるという結論に達しました。

OnBufferingUpdateListenerこのテスト全体を通して、まったく発火しなかったことを付け加えたいと思いました。何のためにあるのかわかりません。読み込みがどのように行われているかを知る唯一の方法は、上記のNPRアプリと同様に、読み込みをプロキシすることだと思います。

于 2012-10-12T01:22:40.873 に答える
2

私はこれを10個のデータポイントで試しました.3つは速く、7つは遅いです。それは一貫しています。つまり、速いストリームは速く、遅いストリームは常に遅いということです。

サーバーが配信した「コンテンツの長さ」に関連していると思います。コンテンツの長さが適切に指定されていない場合、Androidはバッファする量を認識しません。

間違っている可能性があります。ワイヤーシャーキングまでは行きませんでした。

于 2011-12-07T18:28:48.293 に答える