コグノスケ

Androidのメディア再生処理

たまにはAndroidの話でも。Androidのメディア再生のデコード完了から出画までを見てみました。

Media | Android Open Source Project 辺りにあるように、Androidはlibstagefrightにメディアの処理を任せています。

図からはちょっと読み取りづらいですが、libstagefrightは動画、音声のデコードにOpenMAXというAPIを用います。図だとOMX Coreと書かれている部分です。

OpenMAXざっくり紹介

OpenMAXの各種デコーダ（※）は「コンポーネント」と呼ばれる部品になっています。

OpenMAXではデータの入力はEmptyThisBufferと呼びます。データの入力は非同期に行うことができます。コンポーネントは入力を処理し終えたら完了通知をコールバック（EmptyBufferDone）する仕組みになっています。

データの出力はFillThisBufferと呼びます。出力も非同期に行うことができます。コンポーネントはデータ出力の完了通知（FillBufferDone）をする仕組みになっています。

libstagefrightはOpenMAXのコンポーネントに対して、下記の処理を行います。他にも設定、フラッシュ、などややこしい処理がありますが、省略。

入力側はこんな感じです。

• 圧縮データが入ったバッファをEmptyThisBufferでコンポーネントに渡す
• （コンポーネント内でバッファのデータが処理される）
• 空になったバッファがEmptyBufferDoneで返ってくる

出力側もほぼ同じです。

• 空のバッファをFillThisBufferでコンポーネントに渡す
• （コンポーネント内でバッファにデコード済みデータが詰め込まれる）
• デコード済みデータが入ったバッファがFillBufferDoneで返ってくる

バッファが2つある場合も基本的には同じです。OpenMAXの特徴はバッファ1とバッファ2がお互いを気にしなくて良いことです。バッファ2が返ってきていようが返ってきていまいが、バッファ1はコンポーネントに渡して構いません。

例えばバッファ2にすごく時間が掛かって、こんな順になっても構いません（コロンの右側はコンポーネントに渡したが返ってきていないバッファの一覧）。

• start: なし
• FillThisBuffer 1: 1
• FillThisBuffer 2: 1, 2
• FillBufferDone 1: 2
• FillThisBuffer 1: 1, 2
• FillBufferDone 1: 2
• FillThisBuffer 1: 1, 2
• FillBufferDone 2: 1
• FillBufferDone 1: なし

特にデコーダの場合は、この例のように渡した順番と返ってくる順番が違う場合がほとんどです。

（※）OpenMAXの規格が定義するコンポーネントの機能は、デコーダだけではありません。しかしAndroidはデコーダコンポーネントしか使いません。