jfurukawa
2025年6月13日 11時56分
==========
製品型番：AX2210-C00Z
Debian/ABOSバージョン：v3.21.3-at.7
カーネルバージョン：5.10.236-cip55
3G/LTE モジュール情報 (Debianのみ)：なし
その他：imxlib_version 2.2.0
==========
お世話になっております。
Armadillo X2を使用して、カメラ映像の
①AWS KinesisVideoStreamsへの配信
②録画
③画像撮影
を行っておりますがセグメンテーションフォルトが発生すると、i.MX8のハードウェアが不安定になる問題があるようです。
再起動すれば一応回復しますが、できれば再起動以外の解決策を見つけたいと考えています。
コンソールから実行しているテストコマンドは以下の通りです。
gst-launch-1.0 -e \
rtspsrc location=rtsp://admin:1234@192.168.1.100/Ch1 latency=200 ! \
rtph265depay ! \
vpudec output-format=NV12 ! \
vpuenc_h264 bitrate=2000 ! \
h264parse ! \
splitmuxsink \
muxer=mp4mux \
location=record_%05d.mp4 \
max-size-time=10000000000
セグメンテーションフォルトが発生する前までは問題なく動作しますが、一度発生するとその後は正常に動かなくなります。
現状、プログラムを段階的に確認していったところ、vpuenc_h264 のところでストリームが止まっているのを確認しました。
こちらに関して、設定誤りなどありましたらご返信いただければと存じます。
コメント
jfurukawa
> jfurukawaさん
>
> お世話になっています、
> マルティネです。
>
> 去年は vpudec でも苦戦してましたが、vpuenc でも問題は発生しますね…
>
> > コンソールから実行しているテストコマンドは以下の通りです。
> >
> > gst-launch-1.0 -e \
> > rtspsrc location=rtsp://admin:1234@192.168.1.100/Ch1 latency=200 ! \
> > rtph265depay ! \
> > vpudec output-format=NV12 ! \
> > vpuenc_h264 bitrate=2000 ! \
> > h264parse ! \
> > splitmuxsink \
> > muxer=mp4mux \
> > location=record_%05d.mp4 \
> > max-size-time=10000000000
> >
> > セグメンテーションフォルトが発生する前までは問題なく動作しますが、一度発生するとその後は正常に動かなくなります。
>
> vpuenc ではないですが、以前こちらも「vpu でエラーした後に vpu を利用できなくなる」問題は確認しました。
> そのため、vpudec でエラーしてもその後に vpuenc を利用できないなども十分ありえると思います。
>
> 再起動以外の回復方法を当時深くに調べてないですが、セグメンテーションフォルトの方を修正すればこちらの問題はなくなりますのでそちらの方向で解析を進みたいと思います。
>
>
> お手数ですが、いくつかを確認させてください：
> * こちらの問題は上記の gst-launch-1.0 コマンド単体（他のアプリケーションすべて停止状態）でも発生していますか？どれぐらいの頻度で発生しているか等の情報が分かれば教えていただければ幸いです。
> * 正直なところこちらで再現できないと segfault の修正は難しいと思いますので、こちらで再現できるために受信した h265 ストリームを保存してファイルからの再生で再現を目指したいと思います。
> 全く未確認ですが、以下の２つのコマンドでファイルの保存・ファイルからの再生はできると思いますが、それで再現できますでしょうか？
>
> # 保存 > gst-launch-1.0 -e \ > rtspsrc location=rtsp://admin:1234@192.168.1.100/Ch1 latency=200 ! \ > rtph265depay ! \ > mpegtsmux ! \ > filesink location=file.ts > > # 無限の再現 (h265parse ではなく tsdemux が必要かもしれません？） > gst-launch-1.0 -e \ > multifilesrc location=file.ts loop=true ! \ > h265parse ! \ > vpudec output-format=NV12 ! \ > vpuenc_h264 bitrate=2000 ! \ > h264parse ! \ > splitmuxsink \ > muxer=mp4mux \ > location=record_%05d.mp4 \ > max-size-time=10000000000 >
>
> これで再現できたファイルを作成できれば、提供していただければ解析します。
>
> よろしくお願いします
マルティネ様
お世話になっております。迅速なご返信ありがとうございます。
再現成功しました。マルチチャンネル環境で使用すると、20分以内に確実に発生します。
再現時の内容とデバッグログを添付しましたのでご確認のほどよろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| vpudec Debug log.txt |
at_dominique.m…
マルティネです。
> 再現成功しました。マルチチャンネル環境で使用すると、20分以内に確実に発生します。
マルチチャンネルというのはログに入ってるコマンドを別のチャンネルで何回か実行していることでしょうか？
ストリームを src/vrawtee/enctee/arawtee で分裂していることだけでしょうか？
> 再現時の内容とデバッグログを添付しましたのでご確認のほどよろしくお願いいたします。
バックトレースありがとうございます。libfslvpuwrap.so.3 の decoding 処理で失敗していますね…
/opt/firmware の中の so ファイルのデバッグ symbol はないので、すみませんがやっぱり自分が再現できるようにするか、デバッグ用ファームウェアパーティションを準備してインストールしていただきたいです。
（幸いなことに、こちらのライブラリはソースがありますのでデバグビルドはできます）
ひとまずの確認は https://github.com/NXP/imx-vpuwrap.git と https://github.com/nxp-imx/imx-gst1.0-plugin に関係ありそうな修正がないかを確認しましたが、なさそうです（頭の関数に変更なかったです）
再現できそうなファイルを取得できれば一番だと思いますがひとまずデバグ情報の分かる imx_lib.img をビルドしましたので、個別で送らせていただきます。
使い方は、imx_lib.img ファイルを dd 等で /dev/mmcblk2p4 に書き込んで、コンテナ上で deb ファイルをインストールすれば再現した際にライン情報やローカル変数を取得できるはずです。
よろしくお願いします
jfurukawa
> マルティネです。
>
> > 再現成功しました。マルチチャンネル環境で使用すると、20分以内に確実に発生します。
>
> マルチチャンネルというのはログに入ってるコマンドを別のチャンネルで何回か実行していることでしょうか？
> ストリームを src/vrawtee/enctee/arawtee で分裂していることだけでしょうか？
>
> > 再現時の内容とデバッグログを添付しましたのでご確認のほどよろしくお願いいたします。
>
> バックトレースありがとうございます。libfslvpuwrap.so.3 の decoding 処理で失敗していますね…
> /opt/firmware の中の so ファイルのデバッグ symbol はないので、すみませんがやっぱり自分が再現できるようにするか、デバッグ用ファームウェアパーティションを準備してインストールしていただきたいです。
> （幸いなことに、こちらのライブラリはソースがありますのでデバグビルドはできます）
>
> ひとまずの確認は https://github.com/NXP/imx-vpuwrap.git と https://github.com/nxp-imx/imx-gst1.0-plugin に関係ありそうな修正がないかを確認しましたが、なさそうです（頭の関数に変更なかったです）
>
> 再現できそうなファイルを取得できれば一番だと思いますがひとまずデバグ情報の分かる imx_lib.img をビルドしましたので、個別で送らせていただきます。
> 使い方は、imx_lib.img ファイルを dd 等で /dev/mmcblk2p4 に書き込んで、コンテナ上で deb ファイルをインストールすれば再現した際にライン情報やローカル変数を取得できるはずです。
>
> よろしくお願いします
マルティネ様
お世話になっております。
別件対応のため、返信が滞っておりました大変申し訳ございません。
こちらのimgファイルですが添付ファイルに見当たらないようですが認識あっておりますでしょうか？
認識があっている場合大変恐れ入りますが、再度imgファイルを添付いただけますと幸いです。
martinetd
マルティネです。
> こちらのimgファイルですが添付ファイルに見当たらないようですが認識あっておりますでしょうか？
> 認識があっている場合大変恐れ入りますが、再度imgファイルを添付いただけますと幸いです。
img ファイルの再配布はライセンス上曖昧なところになっていて（できるはずですが別の目的で利用されると責められる可能性があります）、個別メールで送ってました。
（６月１３日の「filesend-noreply@atmark-techno.com」からのメールだったはずです）
ダウンロードリンクの有効期限がちょうど切れて明日また送りますが、フォーラムのアカウントに登録されているメールアドレスに問題がないかを確認していただければ幸いです。
よろしくお願いします
jfurukawa
jfurukawa
マルティネ様
お世話になっております。
昨日、メールいただいたimgファイルでログを取得しましたので添付にて送らせていただきます。(vpudec Debug log.txt)
ご確認のほどよろしくお願いします。
また、こちらの問題に関して臨時対応として対応を行った内容も添付させていただきます。
対処内容として問題がないか合わせてご確認いただけますと幸いです。(vpudec Deubg 問題分析と臨時対応.txt)
| ファイル | ファイルの説明 |
|---|---|
| vpudec Debug log.txt | ログファイル |
| vpudec Deubg 問題分析と臨時対応.txt |
jfurukawa
> マルティネ様
>
> お世話になっております。
> 昨日、メールいただいたimgファイルでログを取得しましたので添付にて送らせていただきます。(vpudec Debug log.txt)
> ご確認のほどよろしくお願いします。
>
> また、こちらの問題に関して臨時対応として対応を行った内容も添付させていただきます。
> 対処内容として問題がないか合わせてご確認いただけますと幸いです。(vpudec Deubg 問題分析と臨時対応.txt)
マルティネ様
お世話になっております。
大変恐れ入りますが、こちらの進展いかがでしょうか。
まずは、vpudec Deubg 問題分析と臨時対応.txtの内容に問題がないかご判断可能でしたらご回答いただけますと幸いです。
何卒よろしくお願い申し上げます。
at_dominique.m…
jfurukawaさん
> 大変恐れ入りますが、こちらの進展いかがでしょうか。
> まずは、vpudec Deubg 問題分析と臨時対応.txtの内容に問題がないかご判断可能でしたらご回答いただけますと幸いです。
返事が遅くなってすみません、確認に時間かかりました。
tee の問題、または imxvideoconvert_g2d による対策はいいと思います。
segfault 箇所が違いますが、ロカールファイルでほとんどの処理を省けてもクラッシュを数秒で再現できるようになりました
(glib のなかでクラッシュします…)
gst-launch-1.0 multifilesrc location=h265.mkv loop=true name=src ! matroskademux ! h265parse ! vpudec ! tee name=tee ! queue name=a ! fakesink tee. ! queue name=b max-size-buffers=1 leaky=2 ! fakesink
# https://www.libde265.org/downloads-videos/ の tos-1720x720-cfg01.mkv を利用しました
vpudec 直後に imxvideoconvert_g2d を利用するか、 queue b の leaky=2 パラメターを省くと全く再現しなくなります。
回避方法はできたので解析の優先度を少し下がりますが、７月中に時間を作って調べたいと思います。
大変お手数ですがよろしくお願いします。
jfurukawa
> 返事が遅くなってすみません、確認に時間かかりました。
> tee の問題、または imxvideoconvert_g2d による対策はいいと思います。
>
> segfault 箇所が違いますが、ロカールファイルでほとんどの処理を省けてもクラッシュを数秒で再現できるようになりました
> (glib のなかでクラッシュします…)
>
> gst-launch-1.0 multifilesrc location=h265.mkv loop=true name=src ! matroskademux ! h265parse ! vpudec ! tee name=tee ! queue name=a ! fakesink tee. ! queue name=b max-size-buffers=1 leaky=2 ! fakesink >
> # https://www.libde265.org/downloads-videos/ の tos-1720x720-cfg01.mkv を利用しました
>
> vpudec 直後に imxvideoconvert_g2d を利用するか、 queue b の leaky=2 パラメターを省くと全く再現しなくなります。
>
> 回避方法はできたので解析の優先度を少し下がりますが、７月中に時間を作って調べたいと思います。
>
> 大変お手数ですがよろしくお願いします。
マルティネ様
お世話になっております。
解決方法のご教示ありがとうございます。
一旦、ご教示いただいた方法で対処を行いたいと存じます。
at_dominique.m…
2025年6月13日 12時45分
jfurukawaさん
お世話になっています、
マルティネです。
去年は vpudec でも苦戦してましたが、vpuenc でも問題は発生しますね…
> コンソールから実行しているテストコマンドは以下の通りです。
>
> gst-launch-1.0 -e \
> rtspsrc location=rtsp://admin:1234@192.168.1.100/Ch1 latency=200 ! \
> rtph265depay ! \
> vpudec output-format=NV12 ! \
> vpuenc_h264 bitrate=2000 ! \
> h264parse ! \
> splitmuxsink \
> muxer=mp4mux \
> location=record_%05d.mp4 \
> max-size-time=10000000000
>
> セグメンテーションフォルトが発生する前までは問題なく動作しますが、一度発生するとその後は正常に動かなくなります。
vpuenc ではないですが、以前こちらも「vpu でエラーした後に vpu を利用できなくなる」問題は確認しました。
そのため、vpudec でエラーしてもその後に vpuenc を利用できないなども十分ありえると思います。
再起動以外の回復方法を当時深くに調べてないですが、セグメンテーションフォルトの方を修正すればこちらの問題はなくなりますのでそちらの方向で解析を進みたいと思います。
お手数ですが、いくつかを確認させてください：
* こちらの問題は上記の gst-launch-1.0 コマンド単体（他のアプリケーションすべて停止状態）でも発生していますか？どれぐらいの頻度で発生しているか等の情報が分かれば教えていただければ幸いです。
* 正直なところこちらで再現できないと segfault の修正は難しいと思いますので、こちらで再現できるために受信した h265 ストリームを保存してファイルからの再生で再現を目指したいと思います。
全く未確認ですが、以下の２つのコマンドでファイルの保存・ファイルからの再生はできると思いますが、それで再現できますでしょうか？
# 保存 gst-launch-1.0 -e \ rtspsrc location=rtsp://admin:1234@192.168.1.100/Ch1 latency=200 ! \ rtph265depay ! \ mpegtsmux ! \ filesink location=file.ts # 無限の再現 (h265parse ではなく tsdemux が必要かもしれません？） gst-launch-1.0 -e \ multifilesrc location=file.ts loop=true ! \ h265parse ! \ vpudec output-format=NV12 ! \ vpuenc_h264 bitrate=2000 ! \ h264parse ! \ splitmuxsink \ muxer=mp4mux \ location=record_%05d.mp4 \ max-size-time=10000000000これで再現できたファイルを作成できれば、提供していただければ解析します。
よろしくお願いします