1

ビデオの再生でフレーム ドロップの問題が発生しています。ICS から KK4.4 に移行しました。ビデオは非常に小さい 320x240 解像度です。物事を簡単にするためのオーディオはありません。

Systrace は次の場所にあります: https://www.dropbox.com/s/bee6xymg3kpn4ft/mytrace2.html?dl=0

トリプル バッファリングを有効にしましたが、hwcomposer が SurfaceFlinger に対して偽の vsync を生成しています。

次の問題が見られます。

  1. videodecoder が 7 つのバッファ キューを割り当てるため、トリプル バッファリングが適切に有効化されていません。TimedEventQueue(OnVideoEvent) からキューに入れられる各フレームに対してトリプル バッファリングが正常に機能していた場合、キューから取り出されるバッファは 2 スロット遅れているはずです。例: buf 4 をキューに入れると、buf 2 をデキューする必要がありますが、デキューされるのは直前のバッファであり、Surfaceflinger は次回実行する機会を得たときにのみ解放されます。したがって、遅延により、ビデオのキャンセルバッファが追いつくことになります。

  2. SurfaceFlinger 自体が完了するまでに時間がかかります。

  3. 30 fps ビデオの場合、33 ミリ秒ごとなど、適切なタイミングで Vsync がオンにならない。HWComposer の vsync 生成ロジックに関する問題、または実際のバッファーがキューに入れられていないため、eventControl によって vsync が有効にされていませんか?

私が行った以下のコメントからの更新: 私が指摘したその他のことは、async フラグと mDequeueBufferCannotBlock フラグが両方とも false であるため、getMinUndequeuedBufferCount() が 1 を返すため、2 スロット遅れたバッファーではなく、直前のバッファーがデキューを要求されていることがわかります。 . 上記の理解に穴がある場合はお知らせください。そして、これを回避するために私ができることは何でも

どんな助けでも大歓迎です。

4

1 に答える 1

1

  1. ビデオ コーデックは、必要なバッファ数を決定します。BufferQueue 構成はネゴシエーションです。

  2. SurfaceFlinger が終了するまでに時間がかかっている場所がわかりません。ラインを見てください/system/bin/surfaceflinger- それは速く動いています。

  3. やるべき仕事がないときに目を覚まして仕事をしても意味がないので、何も起こらない場合は VSYNC がオフになります。後者の仮定は正しいです。SurfaceView行を見ると、SurfaceFlinger で利用可能なバッファがないこととウェイクアップがないことの間に相関関係があることがわかります。

BufferQueue にフレームが到着するまでにSurfaceView180 ミリ秒ありますが、これは約 5.5 fps です。mediaserver プロセスには長いonVideoEventセクションがあります。使用しているコーデックは何ですか?

これを「フレーム ドロップ」の問題と説明しましたが、どのプレーヤーを使用していますか?

于 2015-09-16T17:57:50.353 に答える