-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RZ/G1E: H.264ハードウェアデコードのサポート #3
Comments
メモ:
|
HWデコーダーを使うには、カーネルモジュールをいくつか追加でロードする必要があるようだ
Waylandでは以下のコマンドで一応再生できた。
ただし、再生ウィンドウ上部に緑色の帯が出てしまう。 |
以下のデモ用レシピで、上記のカーネルモジュールをロードするinitスクリプトが提供されている。 https://github.com/renesas-rz/meta-rzg-demos/tree/master/meta_rzg1/common デモ用レシピと言いつつ、ベースのBSPにも結構手を入れているようだ。 |
waylandsinkでは上記の通りだが、以下のQtのデモでは特に問題無い。ひとまずこれを参考にすれば良いか? あと、素のBSPでは音声が出ないが、以下のパッチをカーネルに当てれば、一応再生できるようになる(このパッチを当てても挙動が怪しいが無いよりはマシ)。 |
Firefox側については、現状ではビルド時にGStreamerを無効化している。 上記を
libgstappは現状のcore-image-westonではインストールされないので、自分で追加インストールする必要がある。もうちょっと簡単にGStreamer対応付きでビルドできるようにPACKAGECONFIGを用意しておくべきか。 以上でH.264が認識されるようになるが、映像は表示されない。
|
AAC音声は(上記のカーネルパッチと組み合わせれば)再生される。 |
FirefoxでH.264を開いた時のエラーログ(環境変数
gst-launchでH.264映像を表示できているときの同処理
|
omxh264dec自体はI420の出力に対応しているようだが パイプラインの途中に挟まるvspfilter(色空間変換とスケーリング)が、CapabilitiesではI420に対応していると報告しているのに実際にはI420に対応していないようだ。 Mozilla側で https://dxr.mozilla.org/mozilla-esr45/source/dom/media/gstreamer/GStreamerReader.cpp#387 が、まだ微妙に色がおかしい(gst-launch + waylandsinkほどでは無いが)。また、再生が最初の数秒で止まってしまう。 |
参考までに、gst-launch-1.0で再生したときのpipelineを貼り付けておく。 出力方法は、以下でdotファイルを出力し
PCでdotファイルをPNGファイルに変換。Ubuntuの場合は以下:
Mozillaの場合のパイプラインを取得するには、上記の環境変数は効かないのでコードを1,2行差し込む必要がある。具体的には、パイプラインが生成された後にGST_DEBUG_BIN_TO_DOT_FILE()を実行。 |
meta-rzg-demoレイヤの方にvspmfilterというのもあるが、これを挟んでもI420では出力できていない。全体的にNV12以外はあまりテストされてなさそう? |
このときCPU使用率が50%程度になっている(1コアをほぼ消費し尽している)ので、oprofileでプロファイルを取ってみた。排他制御に問題がありそう? この状態になると、ウィンドウを閉じてもプロセスが残ったままになっていることもある。
参考までに、libav(ffmpeg)で再生したときのプロファイルも取得した。CPU使用率は40%ほど(1コアを80%程度)。
取得方法は、以下の手順でデバッグ用イメージを作成し https://github.com/mozilla-japan/meta-browser/wiki/Debug-RZ-G1E 初期化: 以下のようなスクリプトを実行
プロファイル取得: 以下のようなスクリプトを実行
|
Buzillaにもbugを立てた: Bug 1306529 GStreamerの復活の目はやはり無さそうなので、このまま進めても不毛か。OpenMAXでいく場合、基本的にはOmxPlatformLayerとOmxPromiseLayer::BufferDataを実装すれば良いようだ。 |
ってのはそうか、そう来たか、って思いましたね。そういう意味では Chromium ベースで EME 対応したってやつの実装をどうしているのかとか (いますぐ EME 対応したいわけじゃないにしてもそこまで想定していく上では) 何か参考になるかも |
Firefox 45時点では音声にしか対応していないので、dom/media/platform/omxのコードを最新のに更新する必要がある。 |
当面の作業は以下のブランチで進める https://github.com/mozilla-japan/gecko-dev/tree/esr45-omx-linux |
単純にWapper関数を繋いでいって、バッファも単純にコピーしているが、とりあえず絵はでるようになった。絵は綺麗に出ているものの、再生がスローモーション(1/3くらい?)。CPU負荷は5%程度。 |
テストに使用しているのは例によって以下のサイトなのだが、なぜかWebMやOggでも同じ現象が発生する。 http://www.quirksmode.org/html5/tests/video.html で、一度WebMかOggを再生すると、なぜかH.264の再生が正常化する。 |
http://www.adobe.com/inspire-apps/video_effects_part2_examples-1113/examples_part2.html 上記は初めからまともなフレームレートで再生される。 |
そういえばこの現象は今回の実装を入れる前から発生していたのだった。 |
なお、AACデコーダはOpenMAXでは提供されていないので、FFmpegも有効化してそちらでAACをデコードできるようにしておかないと再生できない。 local.conf:
prefs.js:
音声を再生できるかどうかはまだ確認していない。#8 の問題があるので、たぶんちゃんと再生できないのでは無いか? 再生スピードの問題はこれが絡んでいる可能性も考えられるので、確認用に音声だけBlankDecoderを有効化できるようにしておくと良いかもしれない(今のコードで有効化すると映像までブランクになる)。 |
メモ: なお、映像デコーダだけ存在して音声デコーダが存在しないと、初期化処理と終了処理が連続して走り、OmxPromiseLayer::SendCommand()の以下で引っかかって落ちる。 // It doesn't support another flush commands before previous one is completed.
MOZ_RELEASE_ASSERT(!mFlushCommands.Length()); |
直接的な原因かそれとも間接的な原因かはまだ切り分けできていないが、音声をBlankDecoderにすれば再生スピードが改善するかも、というのはビンゴだった。きちんと再生されるようになった。 |
メモ: 再生終了後に再度再生するとクラッシュする。 |
いや、これは手元の実験コードの問題で、githubにpushしてあるコードでは発生しない。 |
というわけで映像についてはある程度動きそうなので、ここまでの成果をいったんレシピに投入する。
OMX_UseEGLImage()については、そもそもサポートしているかどうかから調査。gst-omxのコードを参考にしようと思っていたが、よく見たら実装されていなかったのでRZ/GのBSPの中には多分参考になるコードは無い。 参考: |
iWaveのボードだと、
相変わらず発生する。本コーデックを入れる以前から、またWebMやOggでも発生するので、#8 とも本コーデックとも関係無い別個の問題として扱った方が良さそう。 |
|
あとで余裕が出来たらラズパイ向けに試そうと思っているので、そのときにまた検討する。 |
iWaveのボードで再生が遅い件については、そもそもaplayでwavファイルを再生しても妙に遅い。 |
状況からサウンドドライバを疑ったが、ブートイメージ自体をクリーンビルドすると発生しない。
といった問題は解消した。 ただし、Firefoxで音声が出力されていないことを確認した。
|
再生を繰り返しているとクラッシュすることがある。
|
RZ/G1Eでのログ スタックトレース:
このときのコンソール出力:
PDMのログ:
OMX_EmptyThisBuffer()でエラーが返った際の処理の問題か? エラーコード0x80001008は
|
gst-omxのルネサス実装を確認したところ、RZ/Gの場合、mmngrbufというカーネルモジュール & ライブラリでDMAを提供しているようだ。現状のバッファコピーの実装では、oprofileで見ると当然ながらmemcpy()の負荷が非常に高いので、gst-omxの実装を参考に実装する。 |
クラッシュの問題については、もう少しcoreを収集してみたところ、上記のEmptyBufferDoneやFillThisBufferDone以外にもEventHandlerでも落ちていることが分かった。要はすべてOpenMAXのコールバック関数で落ちている。 |
ただし、昨日から新しく使用し始めたiWaveのRZ/G1Eのボード( http://www.iwavejapan.co.jp/product/renesas%20rz-g1e-sodimm-som2.html )ではまだクラッシュが発生している。こちらはクラッシュ時にカーネルがエラーを吐いており、別問題かもしれない。 |
終了時にpromiseが解決されずにプロセスが残ったままになる問題が発覚したので修正した。 |
この問題もここまでの修正で直ったようだ。 |
コミットが増えてきたので、いったんsquashした以下のブランチで作業を続ける https://github.com/mozilla-japan/gecko-dev/tree/esr45-omx-linux-2 |
現状のコードで改めてテストしてみたところ、現象が再現しなくなっていた。
が入ってなかったので、これが効いた? |
全てのRZ/Gボードで安定動作を確認した。 |
RZ/G1EでH.264のハードウェアデコードに対応させたい。
RZ/G1Eでは選択肢としてOpenMAXかGStreamer(gst-omx使用)があるようだが、Firefox側の事情として最新版ではGStreamerサポートがドロップされている。Firefox 45ESRではまだGStreamerを使えるものの、将来性を考えるとOpenMAXを使った方が良さそう。OpenMAXは現状ではAndroid版Firefoxでしか使えないようだが、Linuxで有効化できるか調査する。
あるいは根本的な方向性として
などを考慮した方が良いという意見があれば、そちらも検討する。
The text was updated successfully, but these errors were encountered: