車輪の再発見みたいな？

GitHubで公開している、UVCカメラへのアクセス用ライブラリ＆サンプルプロジェクト、UVCCameraに含まれるサンプルUSBCameraTest3についての追加記事です。
最初の公開時にUSBCameraTest3のMainActivityのstartRecordingにコメントとして、プライベートスレッドで実行した方が良いよと書いていましたが、プライベートスレッドで実行するように変更したので、ちょびっと解説を。

何でプライベートスレッドやねん？

そうそう、これが大事なんです。MediaCodec+MediaMuxerを使う今までのサンプルにも書いて来ましたが、特にMediaMuxerを使う場合において、プライベートスレッドで実行するのが結構大事なのです。

1. MediaCodecの初期化処理は結構重い
2. MediaCodecの終了処理も結構重い
3. MediaMuxerの終了処理も結構重い・・・しかもいつ終わるかわからない

と言う事で、エンコーダー周りのスレッド構成はこんな感じになっています。以前の記事音＆動画の同時キャプチャがした〜い(その１)からの流用です。
USBCameraTest3についてもエンコーダー周りは同じように実装してあります。
それだったら既にプライベートスレッドで動いてるんやないん？って思ったそこのあなた、エンコーダー周りについてはその通りです。

でもUSBCameraTest3では少なくともあと２つばかりプライベートスレッドで実行した方が良い処理があったのです。

１つ目は簡単に想像付くと思いますが、カメラ(open/close、プレビュー表示開始/停止など)の処理
２つ目は今までのサンプルでは知らなかった事にして実装していなかった処理(笑)

カメラの処理

１つ目のカメラの処理は説明するまでも無いとは思いますが、２つの理由があります。

処理に時間がかかる
逐次的に処理をしないといけない。例えばカメラをopenする前にプレビュー表示開始してはいけません。

つまり、時間のかかる処理を待機しないといけないと言うことになるのですが、UIスレッドで待機するとANRになってしまいます。今までのサンプルでは、手動のボタン操作で開始指示してThreadPoolで単発処理していたので問題無いように見えていましたが、流石に処理が複雑になってきたので、そろそろ真面目に実装すべきでしょうね。
逐次的に処理・・・処理のシリアライズが必要ってことですが、オブジェクトのシリアライズと混ぜこぜにしてしまう頑固なJava使いも多いようなので、シーケンシャルに処理って言いましょう(笑)意味的にはオブジェクトのシリアライズの方が異端な気がしますけどね。
で、そのシーケンシャルに実行する方法はいくつもあるので好きな方法でいいのですが、Android＆プライベートスレッド＆シーケンシャル実行となると、定番はHandlerを使ったメッセージベースの方法ですね。FIFOのメッセージキューを使うことで勝手にシーケンシャル実行になります。このブログでも過去に何度も登場していますので、詳細は省略です。

知らなかった事にして実装していなかった処理

そして２つ目、「知らなかった事にして実装していなかった処理」です。この処理自体はプライベートスレッドで実行しなくてもいいのですが、MediaMuxerを使う場合はプライベートスレッドから呼び出すほうが楽になることがあります。

一体何のことか判りましたか？じゃじゃ〜ん。それは、メディアスキャン処理です(もちろん知らなかった訳では無く単に実装するのが面倒だっただけ)。Android特有の事情でメディアスキャン処理をしてあげないと、せっかく静止画や動画と保存しても、例えばGalleryアプリやPhotoアプリで見ることが出来ないのです(少なくとも端末を再起動すれば見れるようになります)。ファイラー系のアプリでは見えるのに、Galleryアプリでは見えない・・・それはメディアスキャン処理を行ってないからなのです。

メディアスキャン処理はいくつか方法が有ります。

• 一番簡単なのはMediaScannerConnection#scanFileを使う方法だと思います。
• 一番詳細にコントロールできるのは、ContentResolver経由で必要な情報をMediaStoreへ登録する方法
• 昔は出来たけど確か今は通常のアプリからは出来なくなったのが、ACTION_MEDIA_MOUNTEDをブロードキャストする方法

今回は、一番簡単なMediaScannerConnection#scanFileを使います。

でも、MediaScannerConnectionでの処理は静止画や動画のファイルが出来てからでないと行うことが出来ません。静止画の方はファイルへの出力までほぼ自前でコントロールして行うので、ファイルへ書き出しが終わったタイミングでMediaScannerConnection#scanFileを呼び出せばいいのですが、問題は動画です。
最初の方で書きましたが、「MediaMuxerの終了処理も結構重い・・・しかもいつ終わるかわからない」のです。しかも、MediaScannerConnectionの処理はContextが必要なのです。別にActivityのコンテキストである必要は無くて、アプリケーションコンテキストで十分なのですが。
通常はMediaMuxerへ終了指示を出してから大体においては１〜数秒後には終わりますが、その時点でアクティビティやアプリが生きているかどうかもわからないのです。例えば録画中にバックキーを押してアプリを終了してしまった時、あるいは、録画終了指示を出した直後にアプリ終了した時など、MediaMuxerの処理が完了している保証は誰にも出来ません。この、MediaMuxer終了時に「アプリが生きているかどうかもわからない」ってのが曲者で色々手をかけてあげなければいけません。

例えば、MediaMuxerへの強参照をいつ破棄するかが問題になります。強参照が無くなってしばらくすると処理中であっても強制的にGCに抹殺されてしまうので、MediaMuxerが処理を終了するのに十分なだけ強参照で保持してあげないといけません。元々のUSBCameraTest3の実装だと機種によってはMediaMuxerが処理完了する前にGCに抹殺される場合がありました。
１つ前のサンプルUSBCameraTest2の場合は使っているMediaCodec/MediaMuxerが映像用の１つだけだったので、エンコーダー用のスレッドでコントロールすれば良かったのですが、USBCameraTest3ではMediaCodecが音声用と映像用の２つあって、それぞれが独立してMediaMuxerへ書き込みに行くので、誰かが別に音頭を取って破棄のタイミングを図る必要あるのです。

そしてそのMediaMuxerが処理を終了してからMediaScannerConnectionを呼び出せるようにコンテキストを参照可能な状態で保持しないといけないのですが、こちらは気を付けないととリークする可能性があります(破棄されるべきオブジェクトが破棄されずに残ってしまう状態)。
USBCameraTest3では、MediaCodec/MediaMuxer周りの処理をMediaMuxerWrapper内のスレッドで実行しているので、そこに組み込んでもいいのですが、

• どのみちカメラ操作用のスレッドを作らないといけない
• MediaMuxerWrapperへコンテキストを渡さないといけなくなる
• メディアスキャン処理は、エンコード処理と直接関係ない・・・どちらかと言うと上位で呼び出す方が良い処理

とかの理由で、MainActivity内に別スレッドの処理を追加実装しました。

と言う事でソースです。わっはっは、説明が面倒になってきたのでソースで誤魔化そう。長くなってきたので、そろそろソースに行きましょう。

1 2