Closed ashie closed 7 years ago
メモ:
CarE1 platform](http://elinux.org/images/e/ea/Gstreamer121207cewgjamboree43.pdf)
HWデコーダーを使うには、カーネルモジュールをいくつか追加でロードする必要があるようだ
Waylandでは以下のコマンドで一応再生できた。
gst-launch-1.0 playbin uri=file:///path/to/movie-file.mp4
ただし、再生ウィンドウ上部に緑色の帯が出てしまう。 また、再生終了時に必ずSEGVが発生する。
以下のデモ用レシピで、上記のカーネルモジュールをロードするinitスクリプトが提供されている。
https://github.com/renesas-rz/meta-rzg-demos/tree/master/meta_rzg1/common
デモ用レシピと言いつつ、ベースのBSPにも結構手を入れているようだ。
gst-launch-1.0 playbin uri=file:///path/to/movie-file.mp4
ただし、再生ウィンドウ上部に緑色の帯が出てしまう。
waylandsinkでは上記の通りだが、以下のQtのデモでは特に問題無い。ひとまずこれを参考にすれば良いか?
あと、素のBSPでは音声が出ないが、以下のパッチをカーネルに当てれば、一応再生できるようになる(このパッチを当てても挙動が怪しいが無いよりはマシ)。
Firefox側については、現状ではビルド時にGStreamerを無効化している。
上記を--enable-gstreamer=1.0
に変えてビルドし、以下のライブラリを入れておくと、GStreamerを使えるようになる。
libgstappは現状のcore-image-westonではインストールされないので、自分で追加インストールする必要がある。もうちょっと簡単にGStreamer対応付きでビルドできるようにPACKAGECONFIGを用意しておくべきか。
以上でH.264が認識されるようになるが、映像は表示されない。
NSPR_LOG_MODULES="all:3"
では以下のログが出ていた。
-1812302768[a1933a00]: GStreamerReader(94805000) read metadata error: Internal data stream error.: gstomxvideodec.c(2236): gst_omx_video_dec_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstOMXH264Dec-omxh264dec:omxh264dec-omxh264dec0:
-1813875632[945190c0]: GStreamerReader(94805000) ReadAndPushData push ret flushing(-2)
-1812302768[a1933a00]: GStreamerReader(94805000) read metadata error: Internal data stream error.: gstomxvideodec.c(2236): gst_omx_video_dec_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin1/GstOMXH264Dec-omxh264dec:omxh264dec-omxh264dec1:
以上でH.264が認識されるようになるが、映像は表示されない。
AAC音声は(上記のカーネルパッチと組み合わせれば)再生される。
FirefoxでH.264を開いた時のエラーログ(環境変数GST_DEBUG=5 GST_DEBUG_FILE=/path/to/log/file
を与えて実行)
0:00:06.867938834 1752 0xa7325880 DEBUG vspfilter gstvspfilter.c:291:gst_vsp_filter_fixate_caps:<conv> caps video/x-raw, format=(string)I420, width=(int)640, height=(int)360, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, framerate=(fraction)24/1
0:00:06.868067942 1752 0xa7325880 DEBUG vspfilter gstvspfilter.c:292:gst_vsp_filter_fixate_caps:<conv> othercaps video/x-raw, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, framerate=(fraction)24/1, format=(string)I420
0:00:06.868313173 1752 0xa7325880 ERROR vspfilter gstvspfilter.c:226:gst_vsp_filter_is_caps_format_supported_for_vsp:<conv> set_colorspace() failed
0:00:06.868487050 1752 0xa7325880 ERROR vspfilter gstvspfilter.c:324:gst_vsp_filter_fixate_caps:<conv> Unsupported caps format for vsp
gst-launchでH.264映像を表示できているときの同処理
0:00:02.724611571 1850 0xb5601ac0 DEBUG vspfilter gstvspfilter.c:291:gst_vsp_filter_fixate_caps:<vdconv> caps video/x-raw, format=(string)NV12, width=(int)640, height=(int)360, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)bt601, framerate=(fraction)24/1
0:00:02.724775540 1850 0xb5601ac0 DEBUG vspfilter gstvspfilter.c:292:gst_vsp_filter_fixate_caps:<vdconv> othercaps video/x-raw, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, framerate=(fraction)24/1, format=(string){ I420, YV12, YUY2, UYVY, AYUV, RGBx, BGRx, xRGB, xBGR, RGBA, BGRA, ARGB, ABGR, RGB, BGR, Y41B, Y42B, YVYU, Y444, v210, v216, NV12, NV21, NV16, NV24, GRAY8, GRAY16_BE, GRAY16_LE, v308, RGB16, BGR16, RGB15, BGR15, UYVP, A420, RGB8P, YUV9, YVU9, IYU1, ARGB64, AYUV64, r210, I420_10LE, I420_10BE, I422_10LE, I422_10BE, Y444_10LE, Y444_10BE, GBR, GBR_10LE, GBR_10BE }
0:00:02.725190094 1850 0xb5601ac0 DEBUG vspfilter gstvspfilter.c:328:gst_vsp_filter_fixate_caps:<vdconv> result caps video/x-raw, width=(int)640, height=(int)360, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, framerate=(fraction)24/1, format=(string)NV12, colorimetry=(string)bt601
omxh264dec自体はI420の出力に対応しているようだが
パイプラインの途中に挟まるvspfilter(色空間変換とスケーリング)が、CapabilitiesではI420に対応していると報告しているのに実際にはI420に対応していないようだ。
Mozilla側でGST_PLAY_FLAG_NATIVE_VIDEO
をセットしてvideoconvertを外してやれば、omxh264decが出力したI420データを直接受け取ることができるので、絵は出るようになる(NV12で出力してMozilla側でlibyuv::NV12ToI420()
を通しても出るだろうが試していない)。
https://dxr.mozilla.org/mozilla-esr45/source/dom/media/gstreamer/GStreamerReader.cpp#387
が、まだ微妙に色がおかしい(gst-launch + waylandsinkほどでは無いが)。また、再生が最初の数秒で止まってしまう。
参考までに、gst-launch-1.0で再生したときのpipelineを貼り付けておく。
出力方法は、以下でdotファイルを出力し
$ GST_DEBUG_DUMP_DOT_DIR=/path/to/directory playbin uri=file:///path/to/video.mp4
PCでdotファイルをPNGファイルに変換。Ubuntuの場合は以下:
$ sudo apt-get install graphviz
$ dot -Kdot -Tpng /path/to/dotfile.dot -o pipeline.png
Mozillaの場合のパイプラインを取得するには、上記の環境変数は効かないのでコードを1,2行差し込む必要がある。具体的には、パイプラインが生成された後にGST_DEBUG_BIN_TO_DOT_FILE()を実行。
meta-rzg-demoレイヤの方にvspmfilterというのもあるが、これを挟んでもI420では出力できていない。全体的にNV12以外はあまりテストされてなさそう?
が、まだ微妙に色がおかしい(gst-launch + waylandsinkほどでは無いが)。また、再生が最初の数秒で止まってしまう。
このときCPU使用率が50%程度になっている(1コアをほぼ消費し尽している)ので、oprofileでプロファイルを取ってみた。排他制御に問題がありそう? この状態になると、ウィンドウを閉じてもプロセスが残ったままになっていることもある。
CPU: CPU with timer interrupt, speed 1e+06 MHz (estimated)
Profiling through timer interrupt
vma samples % image name app name symbol name
00000000 21116 52.9422 no-vmlinux no-vmlinux /no-vmlinux
000094e4 3152 7.9027 libpthread-2.19.so libpthread-2.19.so pthread_mutex_lock
0000a830 2683 6.7268 libpthread-2.19.so libpthread-2.19.so __pthread_mutex_unlock_usercnt
0000c30c 2318 5.8117 libpthread-2.19.so libpthread-2.19.so pthread_cond_signal@@GLIBC_2.4
0001e364 2200 5.5159 libnspr4.so libnspr4.so PR_ExitMonitor
0001e264 1133 2.8407 libnspr4.so libnspr4.so PR_DestroyMonitor
0000a990 803 2.0133 libpthread-2.19.so libpthread-2.19.so pthread_mutex_unlock
0001e2f8 450 1.1282 libnspr4.so libnspr4.so PR_EnterMonitor
000087f4 279 0.6995 libpthread-2.19.so libpthread-2.19.so pthread_self
015c21b4 254 0.6368 libxul.so libxul.so mozilla::GStreamerReader::DecodeVideoFrame(bo
ol&, long long)
014c4c40 228 0.5716 libxul.so libxul.so mozilla::MediaDecoderReader::RequestVideoData
(bool, long long)
00080780 213 0.5340 libc-2.19.so libc-2.19.so memcpy
00031f88 199 0.4989 libc-2.19.so libc-2.19.so msort_with_tmp.part.0
0042febc 159 0.3986 libxul.so libxul.so mozilla::ReentrantMonitorAutoEnter::~Reentran
tMonitorAutoEnter()
014d4260 152 0.3811 libxul.so libxul.so mozilla::MediaDecoderReader::VideoQueue()
00000000 124 0.3109 libGLESv2.so libGLESv2.so /usr/lib/libGLESv2.so
0007ada0 120 0.3009 libc-2.19.so libc-2.19.so memset
...
参考までに、libav(ffmpeg)で再生したときのプロファイルも取得した。CPU使用率は40%ほど(1コアを80%程度)。
CPU: CPU with timer interrupt, speed 1e+06 MHz (estimated)
Profiling through timer interrupt
vma samples % image name app name symbol name
00000000 12459 59.0194 no-vmlinux no-vmlinux /no-vmlinux
00000000 817 3.8702 libGLESv2.so libGLESv2.so /usr/lib/libGLESv2.so
00080780 491 2.3259 libc-2.19.so libc-2.19.so memcpy
0007ada0 220 1.0422 libc-2.19.so libc-2.19.so memset
00031f88 197 0.9332 libc-2.19.so libc-2.19.so msort_with_tmp.part.0
00208218 187 0.8858 libavcodec.so.53.35.0 libavcodec.so.53.35.0 ff_h264_decode_mb_cavlc
00089920 143 0.6774 libavcodec.so.53.35.0 libavcodec.so.53.35.0 ff_prefetch_arm
000094e4 128 0.6063 libpthread-2.19.so libpthread-2.19.so pthread_mutex_lock
001b9f1c 126 0.5969 libavcodec.so.53.35.0 libavcodec.so.53.35.0 ff_h264_hl_decode_mb
00173938 118 0.5590 libavcodec.so.53.35.0 libavcodec.so.53.35.0 loop_filter
00002374 114 0.5400 libz.so.1.2.8 libz.so.1.2.8 longest_match
00206f70 106 0.5021 libavcodec.so.53.35.0 libavcodec.so.53.35.0 decode_residual
0020f7f0 102 0.4832 libavcodec.so.53.35.0 libavcodec.so.53.35.0 ff_h264_filter_mb
0000a830 92 0.4358 libpthread-2.19.so libpthread-2.19.so __pthread_mutex_unlock_usercnt
0001c85c 79 0.3742 firefox firefox arena_dalloc
00205d78 79 0.3742 libavcodec.so.53.35.0 libavcodec.so.53.35.0 fill_decode_caches
0001dc34 75 0.3553 firefox firefox arena_malloc
0008ead8 68 0.3221 libavcodec.so.53.35.0 libavcodec.so.53.35.0 ff_put_h264_chroma_mc8_neon
01fda5ac 51 0.2416 libxul.so libxul.so alsa_run_thread
00032430 46 0.2179 libfreebl3.so libfreebl3.so s_mpv_mul_d_add_prop
00000000 46 0.2179 libsrv_um.so libsrv_um.so /usr/lib/libsrv_um.so
02563730 45 0.2132 libxul.so libxul.so Interpret(JSContext*, js::RunState&)
00175a14 44 0.2084 libavcodec.so.53.35.0 libavcodec.so.53.35.0 await_references
0008fb88 44 0.2084 libavcodec.so.53.35.0 libavcodec.so.53.35.0 ff_h264_h_loop_filter_luma_neon
0008c5f0 40 0.1895 libavcodec.so.53.35.0 libavcodec.so.53.35.0 ff_put_pixels16_neon
...
取得方法は、以下の手順でデバッグ用イメージを作成し
https://github.com/mozilla-japan/meta-browser/wiki/Debug-RZ-G1E
初期化: 以下のようなスクリプトを実行
#!/bin/sh
opcontrol --deinit
/sbin/modprobe oprofile timer=1
opcontrol --no-vmlinux
opcontrol --reset
プロファイル取得: 以下のようなスクリプトを実行 (ブラウザは着目する操作だけを行ってすぐに終了させる)
#/bin/sh
opcontrol --start
/usr/bin/firefox file:///path/to/movie.html
opcontrol --stop
opreport -lw > /path/to/opreport.log
Mozilla側でGST_PLAY_FLAG_NATIVE_VIDEOをセットしてvideoconvertを外してやれば、omxh264decが出力したI420データを直接受け取ることができるので、絵は出るようになる
この状態のパイプラインも一応採取したので貼り付けておく
Buzillaにもbugを立てた: Bug 1306529
GStreamerの復活の目はやはり無さそうなので、このまま進めても不毛か。OpenMAXでいく場合、基本的にはOmxPlatformLayerとOmxPromiseLayer::BufferDataを実装すれば良いようだ。
it's fundamentally incompatible with HTML5 media source extension
ってのはそうか、そう来たか、って思いましたね。そういう意味では Chromium ベースで EME 対応したってやつの実装をどうしているのかとか (いますぐ EME 対応したいわけじゃないにしてもそこまで想定していく上では) 何か参考になるかも
GStreamerの復活の目はやはり無さそうなので、このまま進めても不毛か。OpenMAXでいく場合、基本的にはOmxPlatformLayerとOmxPromiseLayer::BufferDataを実装すれば良いようだ。
Firefox 45時点では音声にしか対応していないので、dom/media/platform/omxのコードを最新のに更新する必要がある。
当面の作業は以下のブランチで進める
https://github.com/mozilla-japan/gecko-dev/tree/esr45-omx-linux
手元でOpenMAXコンポーネントのインスタンス作成までは動くようになったが、AACデコーダのコンポーネント("OMX.RENESAS.AUDIO.DECODER.AAC")が作成できない。
gst-inspect-1.0
ではomxaacdec
が見つかるので、てっきりOpenMAXのAACデコーダが提供されているものと思っていたが、インストールされているOpenMAX関係のライブラリを調べても確かに該当するものが無さそうだ。また、
この状態のパイプラインも一応採取したので貼り付けておく
これを見ても、omxaacdec
ではなくfaad
が使われている。
当面の作業は以下のブランチで進める
https://github.com/mozilla-japan/gecko-dev/tree/esr45-omx-linux
単純にWapper関数を繋いでいって、バッファも単純にコピーしているが、とりあえず絵はでるようになった。絵は綺麗に出ているものの、再生がスローモーション(1/3くらい?)。CPU負荷は5%程度。
再生がスローモーション(1/3くらい?)。CPU負荷は5%程度。
テストに使用しているのは例によって以下のサイトなのだが、なぜかWebMやOggでも同じ現象が発生する。
http://www.quirksmode.org/html5/tests/video.html
で、一度WebMかOggを再生すると、なぜかH.264の再生が正常化する。 正常に再生されているときのCPU負荷は30%ほど。FFmpegよりは明らかに負荷が下がっており、Qtと較べても同程度。
http://www.adobe.com/inspire-apps/video_effects_part2_examples-1113/examples_part2.html
上記は初めからまともなフレームレートで再生される。 エフェクトがソフトウェア再生のときより明らかに速くなった。 が、ブロックノイズが目立つ。
テストに使用しているのは例によって以下のサイトなのだが、なぜかWebMやOggでも同じ現象が発生する。
そういえばこの現象は今回の実装を入れる前から発生していたのだった。 なんで再生スピードが落ちるのか不思議に思うことがよくあった。 1ページに複数動画があると発生する?
なお、AACデコーダはOpenMAXでは提供されていないので、FFmpegも有効化してそちらでAACをデコードできるようにしておかないと再生できない。
local.conf:
IMAGE_INSTALL_append = " libav x264 "
prefs.js:
user_pref("media.ffmpeg.enabled", false);
音声を再生できるかどうかはまだ確認していない。#8 の問題があるので、たぶんちゃんと再生できないのでは無いか? 再生スピードの問題はこれが絡んでいる可能性も考えられるので、確認用に音声だけBlankDecoderを有効化できるようにしておくと良いかもしれない(今のコードで有効化すると映像までブランクになる)。
メモ: なお、映像デコーダだけ存在して音声デコーダが存在しないと、初期化処理と終了処理が連続して走り、OmxPromiseLayer::SendCommand()の以下で引っかかって落ちる。
// It doesn't support another flush commands before previous one is completed.
MOZ_RELEASE_ASSERT(!mFlushCommands.Length());
音声を再生できるかどうかはまだ確認していない。#8 の問題があるので、たぶんちゃんと再生できないのでは無いか? 再生スピードの問題はこれが絡んでいる可能性も考えられるので、確認用に音声だけBlankDecoderを有効化できるようにしておくと良いかもしれない
直接的な原因かそれとも間接的な原因かはまだ切り分けできていないが、音声をBlankDecoderにすれば再生スピードが改善するかも、というのはビンゴだった。きちんと再生されるようになった。
メモ: 再生終了後に再度再生するとクラッシュする。
メモ: 再生終了後に再度再生するとクラッシュする。
いや、これは手元の実験コードの問題で、githubにpushしてあるコードでは発生しない。
というわけで映像についてはある程度動きそうなので、ここまでの成果をいったんレシピに投入する。 次の目標は
OMX_UseEGLImage()については、そもそもサポートしているかどうかから調査。gst-omxのコードを参考にしようと思っていたが、よく見たら実装されていなかったのでRZ/GのBSPの中には多分参考になるコードは無い。
参考: https://www.khronos.org/registry/omxil/specs/OpenMAX_IL_1_1_2_Specification.pdf の3.2.2.19
8 の調査、および本Issueとの関連の調査
iWaveのボードだと、
直接的な原因かそれとも間接的な原因かはまだ切り分けできていないが、音声をBlankDecoderにすれば再生スピードが改善するかも、というのはビンゴだった。きちんと再生されるようになった。
相変わらず発生する。本コーデックを入れる以前から、またWebMやOggでも発生するので、#8 とも本コーデックとも関係無い別個の問題として扱った方が良さそう。
- OMX_UseEGLImage()でのゼロコピーの検討
OMX_ErrorNotImplemented
が返ってくるので実装されていない。終了。
OMX_ErrorNotImplemented
が返ってくるので実装されていない。終了。
あとで余裕が出来たらラズパイ向けに試そうと思っているので、そのときにまた検討する。
iWaveのボードで再生が遅い件については、そもそもaplayでwavファイルを再生しても妙に遅い。 サウンドドライバを殺すなどしてサウンドを出力しないようにすると、映像側の再生は問題無くなる。
状況からサウンドドライバを疑ったが、ブートイメージ自体をクリーンビルドすると発生しない。 そこで /var/lib/alsa/asound.state を破棄してみたところ、
といった問題は解消した。 おかしな状態で設定が保存されていたようだ。
ただし、Firefoxで音声が出力されていないことを確認した。 H.264だけでなく、WebMやOggでも出力されていない。 aplayやspeaker-testでは出力されている。
$ amixer cset name='Headphone Playback Volume' 100
$ amixer cset name='DVC Out Playback Volume' 100
$ aplay -D plughw:0,0 asano.wav
$ speaker-test -twav
再生を繰り返しているとクラッシュすることがある。 以下、coreファイルから取得したスタックトレース。
#0 0xb6f2c1ac in raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1 0xb456a570 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) ()
from ./usr/lib/firefox-45.4.0/libxul.so
#2 <signal handler called>
#3 0xb3b49e5c in RefPtr<mozilla::MediaRawData>::~RefPtr() () from ./usr/lib/firefox-45.4.0/libxul.so
#4 0xb3c00808 in mozilla::OmxPromiseLayer::FindAndRemoveRawData(long long) ()
from ./usr/lib/firefox-45.4.0/libxul.so
#5 0xb3c03f24 in mozilla::OmxPromiseLayer::EmptyFillBufferDone(OMX_DIRTYPE, mozilla::OmxPromiseLayer::BufferData*)
() from ./usr/lib/firefox-45.4.0/libxul.so
#6 0xb3c0413c in mozilla::PureOmxPlatformLayer::FillBufferDone(OMX_BUFFERHEADERTYPE*) ()
from ./usr/lib/firefox-45.4.0/libxul.so
#7 0x9352fe94 in OmxrMcClientInterface_CallbackHandler () from ./usr/local/lib/libomxr_mc_cmn.so.2
#8 0x9352fe94 in OmxrMcClientInterface_CallbackHandler () from ./usr/local/lib/libomxr_mc_cmn.so.2
RZ/G1Eでのログ
スタックトレース:
#0 raise (sig=11) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:39
#1 0xb46b5e98 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) ()
from ./usr/lib/firefox-45.4.0/libxul.so
#2 <signal handler called>
#3 0xb2bf1720 in mozilla::OffTheBooksMutex::Lock() () from ./usr/lib/firefox-45.4.0/libxul.so
#4 0xb3d50114 in mozilla::OmxPromiseLayer::EmptyFillBufferDone(OMX_DIRTYPE, mozilla::OmxPromiseLayer::BufferData*)
() from ./usr/lib/firefox-45.4.0/libxul.so
#5 0xb3d50280 in mozilla::PureOmxPlatformLayer::EmptyBufferDone(OMX_BUFFERHEADERTYPE*) ()
from ./usr/lib/firefox-45.4.0/libxul.so
#6 0x91d57e40 in OmxrMcClientInterface_CallbackHandler () from ./usr/local/lib/libomxr_mc_cmn.so.2
#7 0x91d57e40 in OmxrMcClientInterface_CallbackHandler () from ./usr/local/lib/libomxr_mc_cmn.so.2
このときのコンソール出力:
ts:1478239395.473527 level:0x10000 func:OmxrMcApiProxy_EmptyThisBuffer(1138) tid:1574 mes:eError =
H'80001008
PDMのログ:
-1887439792[972c5a80]: OmxDataDecoder(9be37c80)::NotifyError: NotifyError -2147479544 at EmptyBufferFailure
-1868401584[972c5b40]: OmxPromiseLayer(9bb4ce00)::EmptyFillBufferDone: type 1, buffer 983cb460
-1868401584[972c5b40]: PureOmxPlatformLayer(9c07e260)::EmptyBufferDone: PortDirection: 0
-1868401584[972c5b40]: OmxPromiseLayer(9bb4ce00)::EmptyFillBufferDone: type 0, buffer 983cb340
OMX_EmptyThisBuffer()でエラーが返った際の処理の問題か?
エラーコード0x80001008はOMX_ErrorOverflow
:
OMX_ErrorOverflow The buffer was not available when it was needed
- OMX_UseEGLImage()でのゼロコピーの検討
gst-omxのルネサス実装を確認したところ、RZ/Gの場合、mmngrbufというカーネルモジュール & ライブラリでDMAを提供しているようだ。現状のバッファコピーの実装では、oprofileで見ると当然ながらmemcpy()の負荷が非常に高いので、gst-omxの実装を参考に実装する。
クラッシュの問題については、もう少しcoreを収集してみたところ、上記のEmptyBufferDoneやFillThisBufferDone以外にもEventHandlerでも落ちていることが分かった。要はすべてOpenMAXのコールバック関数で落ちている。 これを受けて改めてコードを確認してみたところ、この辺りのマルチスレッド対応はOmxPlatformLayer側で考慮しないといけなさそうだった。TaskQueueを使うように変更したところ、StarterKit上では今のところクラッシュは発生していない。
ただし、昨日から新しく使用し始めたiWaveのRZ/G1Eのボード( http://www.iwavejapan.co.jp/product/renesas%20rz-g1e-sodimm-som2.html )ではまだクラッシュが発生している。こちらはクラッシュ時にカーネルがエラーを吐いており、別問題かもしれない。
終了時にpromiseが解決されずにプロセスが残ったままになる問題が発覚したので修正した。 ここまでの修正をいったんレシピに投入する。 クラッシュはまだ発生するかもしれないが、以前よりはだいぶ安定性が向上したはず。
メモ: なお、映像デコーダだけ存在して音声デコーダが存在しないと、初期化処理と終了処理が連続して走り、OmxPromiseLayer::SendCommand()の以下で引っかかって落ちる。
この問題もここまでの修正で直ったようだ。 音声デコーダが無くてもクラッシュはしなくなった(再生はできないが)。
コミットが増えてきたので、いったんsquashした以下のブランチで作業を続ける
https://github.com/mozilla-japan/gecko-dev/tree/esr45-omx-linux-2
ただし、昨日から新しく使用し始めたiWaveのRZ/G1Eのボード( http://www.iwavejapan.co.jp/product/renesas%20rz-g1e-sodimm-som2.html )ではまだクラッシュが発生している。
現状のコードで改めてテストしてみたところ、現象が再現しなくなっていた。 前回までは
終了時にpromiseが解決されずにプロセスが残ったままになる問題が発覚したので修正した。
が入ってなかったので、これが効いた?
全てのRZ/Gボードで安定動作を確認した。 まだあれこれ課題はあるが、長くなってきたのでそれらは別issueにすることにして、本issueはいったんクローズする。
RZ/G1EでH.264のハードウェアデコードに対応させたい。 RZ/G1Eでは選択肢としてOpenMAXかGStreamer(gst-omx使用)があるようだが、Firefox側の事情として最新版ではGStreamerサポートがドロップされている。Firefox 45ESRではまだGStreamerを使えるものの、将来性を考えるとOpenMAXを使った方が良さそう。OpenMAXは現状ではAndroid版Firefoxでしか使えないようだが、Linuxで有効化できるか調査する。
あるいは根本的な方向性として
などを考慮した方が良いという意見があれば、そちらも検討する。