RZ/G1EでH.264のハードウェアデコードに対応させたい。 RZ/G1Eでは選択肢としてOpenMAXかGStreamer（gst-omx使用）があるようだが、

メモ: [Integrating Video Processing Hardware

HWデコーダーを使うには、カーネルモジュールをいくつか追加でロードする必要があるようだ mmngr mmn

以下のデモ用レシピで、上記のカーネルモジュールをロードするinitスクリプトが提供されている。 <a href="https://git

gst-launch-1.0 playbin uri=file:///path/to/movie-file.mp4 <p dir="aut

Firefox側については、現状ではビルド時にGStreamerを無効化している。 <a href="https://github.co

omxh264dec自体はI420の出力に対応しているようだが <a href="https://github.com/renesas-

参考までに、gst-launch-1.0で再生したときのpipelineを貼り付けておく。 <a target="_blank" rel

RZ/G1E: H.264ハードウェアデコードのサポート,about webdino/gecko-embedded

Comments (42)

ashie commented on June 2, 2024

メモ:

[Integrating Video Processing
Hardware into
GStreamer

a case study of the
Renesas
R
CarE1 platform](http://elinux.org/images/e/ea/Gstreamer121207cewgjamboree43.pdf)

from gecko-embedded.

ashie commented on June 2, 2024

HWデコーダーを使うには、カーネルモジュールをいくつか追加でロードする必要があるようだ

mmngr
mmngrbuf
s3ctl
uvcs_cmn
vspm
fdpm

Waylandでは以下のコマンドで一応再生できた。

gst-launch-1.0 playbin uri=file:///path/to/movie-file.mp4

ただし、再生ウィンドウ上部に緑色の帯が出てしまう。
また、再生終了時に必ずSEGVが発生する。

from gecko-embedded.

ashie commented on June 2, 2024

以下のデモ用レシピで、上記のカーネルモジュールをロードするinitスクリプトが提供されている。

https://github.com/renesas-rz/meta-rzg-demos/tree/master/meta_rzg1/common

デモ用レシピと言いつつ、ベースのBSPにも結構手を入れているようだ。

from gecko-embedded.

ashie commented on June 2, 2024

gst-launch-1.0 playbin uri=file:///path/to/movie-file.mp4

ただし、再生ウィンドウ上部に緑色の帯が出てしまう。

waylandsinkでは上記の通りだが、以下のQtのデモでは特に問題無い。ひとまずこれを参考にすれば良いか?

https://github.com/renesas-rz/meta-rzg-demos/tree/master/meta_rzg1/common/recipes-qt/qt

あと、素のBSPでは音声が出ないが、以下のパッチをカーネルに当てれば、一応再生できるようになる（このパッチを当てても挙動が怪しいが無いよりはマシ）。

https://github.com/renesas-rz/meta-rzg-demos/blob/master/meta_rzg1/common/recipes-kernel/linux-renesas/0002-audio-fix-non-audio-at-boot-up-randomly.patch

from gecko-embedded.

ashie commented on June 2, 2024

Firefox側については、現状ではビルド時にGStreamerを無効化している。

https://github.com/mozilla-japan/meta-browser/blob/89755d6bea16e2894390ee6cfa16bc4d7e259d9f/recipes-mozilla/firefox/firefox/mozconfig-45esr#L32

上記を--enable-gstreamer=1.0に変えてビルドし、以下のライブラリを入れておくと、GStreamerを使えるようになる。

libgstreamer
libgstapp
libgstvideo

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:

from gecko-embedded.

ashie commented on June 2, 2024

以上でH.264が認識されるようになるが、映像は表示されない。

AAC音声は（上記のカーネルパッチと組み合わせれば）再生される。

from gecko-embedded.

ashie commented on June 2, 2024

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

from gecko-embedded.

ashie commented on June 2, 2024

omxh264dec自体はI420の出力に対応しているようだが

https://github.com/renesas-rz/meta-renesas/blob/master/meta-rzg1/recipes-multimedia/gstreamer/gstreamer1.0-omx/0004-omxvideodec-change-supported-color-formats-list-crea.patch#L37

パイプラインの途中に挟まるvspfilter（色空間変換とスケーリング）が、CapabilitiesではI420に対応していると報告しているのに実際にはI420に対応していないようだ。

https://github.com/renesas-rz/meta-renesas/blob/master/meta-rzg1/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/wayland/0002-vspfilter-Add-a-new-plugin-converting-colorspace-and.patch#L215

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ほどでは無いが)。また、再生が最初の数秒で止まってしまう。

from gecko-embedded.

ashie commented on June 2, 2024

参考までに、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()を実行。

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-GstInfo.html#GST-DEBUG-BIN-TO-DOT-FILE:CAPS

from gecko-embedded.

ashie commented on June 2, 2024

meta-rzg-demoレイヤの方にvspmfilterというのもあるが、これを挟んでもI420では出力できていない。全体的にNV12以外はあまりテストされてなさそう?

from gecko-embedded.

ashie commented on June 2, 2024

が、まだ微妙に色がおかしい(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

from gecko-embedded.

ashie commented on June 2, 2024

Mozilla側でGST_PLAY_FLAG_NATIVE_VIDEOをセットしてvideoconvertを外してやれば、omxh264decが出力したI420データを直接受け取ることができるので、絵は出るようになる

この状態のパイプラインも一応採取したので貼り付けておく

from gecko-embedded.

ashie commented on June 2, 2024

Buzillaにもbugを立てた: Bug 1306529

GStreamerの復活の目はやはり無さそうなので、このまま進めても不毛か。OpenMAXでいく場合、基本的にはOmxPlatformLayerとOmxPromiseLayer::BufferDataを実装すれば良いようだ。

from gecko-embedded.

dynamis commented on June 2, 2024

it's fundamentally incompatible with HTML5 media source extension

ってのはそうか、そう来たか、って思いましたね。そういう意味では Chromium ベースで EME 対応したってやつの実装をどうしているのかとか (いますぐ EME 対応したいわけじゃないにしてもそこまで想定していく上では) 何か参考になるかも

http://www.linaro.org/blog/engineering-update-16-04/

from gecko-embedded.

ashie commented on June 2, 2024

GStreamerの復活の目はやはり無さそうなので、このまま進めても不毛か。OpenMAXでいく場合、基本的にはOmxPlatformLayerとOmxPromiseLayer::BufferDataを実装すれば良いようだ。

Firefox 45時点では音声にしか対応していないので、dom/media/platform/omxのコードを最新のに更新する必要がある。

from gecko-embedded.

ashie commented on June 2, 2024

当面の作業は以下のブランチで進める

https://github.com/mozilla-japan/gecko-dev/tree/esr45-omx-linux

from gecko-embedded.

ashie commented on June 2, 2024

手元でOpenMAXコンポーネントのインスタンス作成までは動くようになったが、AACデコーダのコンポーネント（"OMX.RENESAS.AUDIO.DECODER.AAC"）が作成できない。

gst-inspect-1.0ではomxaacdecが見つかるので、てっきりOpenMAXのAACデコーダが提供されているものと思っていたが、インストールされているOpenMAX関係のライブラリを調べても確かに該当するものが無さそうだ。また、

この状態のパイプラインも一応採取したので貼り付けておく

これを見ても、omxaacdecではなくfaadが使われている。

from gecko-embedded.

ashie commented on June 2, 2024

当面の作業は以下のブランチで進める

https://github.com/mozilla-japan/gecko-dev/tree/esr45-omx-linux

単純にWapper関数を繋いでいって、バッファも単純にコピーしているが、とりあえず絵はでるようになった。絵は綺麗に出ているものの、再生がスローモーション(1/3くらい?)。CPU負荷は5%程度。

from gecko-embedded.

ashie commented on June 2, 2024

再生がスローモーション(1/3くらい?)。CPU負荷は5%程度。

テストに使用しているのは例によって以下のサイトなのだが、なぜかWebMやOggでも同じ現象が発生する。

http://www.quirksmode.org/html5/tests/video.html

で、一度WebMかOggを再生すると、なぜかH.264の再生が正常化する。
正常に再生されているときのCPU負荷は30%ほど。FFmpegよりは明らかに負荷が下がっており、Qtと較べても同程度。

from gecko-embedded.

ashie commented on June 2, 2024

http://www.adobe.com/inspire-apps/video_effects_part2_examples-1113/examples_part2.html

上記は初めからまともなフレームレートで再生される。
エフェクトがソフトウェア再生のときより明らかに速くなった。
が、ブロックノイズが目立つ。

from gecko-embedded.

ashie commented on June 2, 2024

テストに使用しているのは例によって以下のサイトなのだが、なぜかWebMやOggでも同じ現象が発生する。

そういえばこの現象は今回の実装を入れる前から発生していたのだった。
なんで再生スピードが落ちるのか不思議に思うことがよくあった。
1ページに複数動画があると発生する?

from gecko-embedded.

ashie commented on June 2, 2024

なお、AACデコーダはOpenMAXでは提供されていないので、FFmpegも有効化してそちらでAACをデコードできるようにしておかないと再生できない。

local.conf:

IMAGE_INSTALL_append = " libav x264 "

prefs.js:

user_pref("media.ffmpeg.enabled", false);

音声を再生できるかどうかはまだ確認していない。#8 の問題があるので、たぶんちゃんと再生できないのでは無いか? 再生スピードの問題はこれが絡んでいる可能性も考えられるので、確認用に音声だけBlankDecoderを有効化できるようにしておくと良いかもしれない（今のコードで有効化すると映像までブランクになる）。

from gecko-embedded.

ashie commented on June 2, 2024

メモ: なお、映像デコーダだけ存在して音声デコーダが存在しないと、初期化処理と終了処理が連続して走り、OmxPromiseLayer::SendCommand()の以下で引っかかって落ちる。

    // It doesn't support another flush commands before previous one is completed.                                         
    MOZ_RELEASE_ASSERT(!mFlushCommands.Length());

from gecko-embedded.

ashie commented on June 2, 2024

音声を再生できるかどうかはまだ確認していない。#8 の問題があるので、たぶんちゃんと再生できないのでは無いか? 再生スピードの問題はこれが絡んでいる可能性も考えられるので、確認用に音声だけBlankDecoderを有効化できるようにしておくと良いかもしれない

直接的な原因かそれとも間接的な原因かはまだ切り分けできていないが、音声をBlankDecoderにすれば再生スピードが改善するかも、というのはビンゴだった。きちんと再生されるようになった。

from gecko-embedded.

ashie commented on June 2, 2024

メモ: 再生終了後に再度再生するとクラッシュする。

from gecko-embedded.

ashie commented on June 2, 2024

メモ: 再生終了後に再度再生するとクラッシュする。

いや、これは手元の実験コードの問題で、githubにpushしてあるコードでは発生しない。

from gecko-embedded.

ashie commented on June 2, 2024

というわけで映像についてはある程度動きそうなので、ここまでの成果をいったんレシピに投入する。
次の目標は

OMX_UseEGLImage()でのゼロコピーの検討
#8 の調査、および本Issueとの関連の調査

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

from gecko-embedded.

ashie commented on June 2, 2024

#8 の調査、および本Issueとの関連の調査

iWaveのボードだと、

直接的な原因かそれとも間接的な原因かはまだ切り分けできていないが、音声をBlankDecoderにすれば再生スピードが改善するかも、というのはビンゴだった。きちんと再生されるようになった。

相変わらず発生する。本コーデックを入れる以前から、またWebMやOggでも発生するので、#8 とも本コーデックとも関係無い別個の問題として扱った方が良さそう。

from gecko-embedded.

ashie commented on June 2, 2024

OMX_UseEGLImage()でのゼロコピーの検討

OMX_ErrorNotImplementedが返ってくるので実装されていない。終了。

from gecko-embedded.

ashie commented on June 2, 2024

OMX_ErrorNotImplementedが返ってくるので実装されていない。終了。

あとで余裕が出来たらラズパイ向けに試そうと思っているので、そのときにまた検討する。

from gecko-embedded.

ashie commented on June 2, 2024

iWaveのボードで再生が遅い件については、そもそもaplayでwavファイルを再生しても妙に遅い。
サウンドドライバを殺すなどしてサウンドを出力しないようにすると、映像側の再生は問題無くなる。

from gecko-embedded.

ashie commented on June 2, 2024

状況からサウンドドライバを疑ったが、ブートイメージ自体をクリーンビルドすると発生しない。
そこで /var/lib/alsa/asound.state を破棄してみたところ、

aplayで音声を再生できない、再生速度が狂う
Firefoxで再生速度が狂う

といった問題は解消した。
おかしな状態で設定が保存されていたようだ。

ただし、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

from gecko-embedded.

ashie commented on June 2, 2024

再生を繰り返しているとクラッシュすることがある。
以下、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

from gecko-embedded.

ashie commented on June 2, 2024

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

from gecko-embedded.

ashie commented on June 2, 2024

OMX_UseEGLImage()でのゼロコピーの検討

gst-omxのルネサス実装を確認したところ、RZ/Gの場合、mmngrbufというカーネルモジュール & ライブラリでDMAを提供しているようだ。現状のバッファコピーの実装では、oprofileで見ると当然ながらmemcpy()の負荷が非常に高いので、gst-omxの実装を参考に実装する。

from gecko-embedded.

ashie commented on June 2, 2024

クラッシュの問題については、もう少しcoreを収集してみたところ、上記のEmptyBufferDoneやFillThisBufferDone以外にもEventHandlerでも落ちていることが分かった。要はすべてOpenMAXのコールバック関数で落ちている。
これを受けて改めてコードを確認してみたところ、この辺りのマルチスレッド対応はOmxPlatformLayer側で考慮しないといけなさそうだった。TaskQueueを使うように変更したところ、StarterKit上では今のところクラッシュは発生していない。

from gecko-embedded.

ashie commented on June 2, 2024

ただし、昨日から新しく使用し始めたiWaveのRZ/G1Eのボード（ http://www.iwavejapan.co.jp/product/renesas%20rz-g1e-sodimm-som2.html ）ではまだクラッシュが発生している。こちらはクラッシュ時にカーネルがエラーを吐いており、別問題かもしれない。

from gecko-embedded.

ashie commented on June 2, 2024

終了時にpromiseが解決されずにプロセスが残ったままになる問題が発覚したので修正した。
ここまでの修正をいったんレシピに投入する。
クラッシュはまだ発生するかもしれないが、以前よりはだいぶ安定性が向上したはず。

from gecko-embedded.

ashie commented on June 2, 2024

メモ: なお、映像デコーダだけ存在して音声デコーダが存在しないと、初期化処理と終了処理が連続して走り、OmxPromiseLayer::SendCommand()の以下で引っかかって落ちる。

この問題もここまでの修正で直ったようだ。
音声デコーダが無くてもクラッシュはしなくなった（再生はできないが）。

from gecko-embedded.

ashie commented on June 2, 2024

コミットが増えてきたので、いったんsquashした以下のブランチで作業を続ける

https://github.com/mozilla-japan/gecko-dev/tree/esr45-omx-linux-2

from gecko-embedded.

ashie commented on June 2, 2024

ただし、昨日から新しく使用し始めたiWaveのRZ/G1Eのボード（ http://www.iwavejapan.co.jp/product/renesas%20rz-g1e-sodimm-som2.html ）ではまだクラッシュが発生している。

現状のコードで改めてテストしてみたところ、現象が再現しなくなっていた。
前回までは

終了時にpromiseが解決されずにプロセスが残ったままになる問題が発覚したので修正した。

が入ってなかったので、これが効いた?

from gecko-embedded.

ashie commented on June 2, 2024

全てのRZ/Gボードで安定動作を確認した。
まだあれこれ課題はあるが、長くなってきたのでそれらは別issueにすることにして、本issueはいったんクローズする。

from gecko-embedded.

RZ/G1E: H.264ハードウェアデコードのサポート about gecko-embedded HOT 42 CLOSED

Comments (42)

[Integrating Video Processing
Hardware into
GStreamer

a case study of the
Renesas
R

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

Comments (42)

[Integrating Video Processing Hardware into GStreamer

a case study of the Renesas R

Related Issues (20)

Recommend Projects

Recommend Topics

Recommend Org

[Integrating Video Processing
Hardware into
GStreamer

a case study of the
Renesas
R