jfurukawa
2024年7月30日 18時10分
お世話になっております。
情報が少ない中で申し訳ございませんが、１台のArmadillo-IoT G4で何台のカメラ映像を配信できるかという検証を行っております。
H.265コーデックのカメラで配信を行った場合は、８台を超えたあたりからカメラの映像が配信先の方で表示されなくなりますがCPU、メモリの使用率等に問題があるわけではないためどの部分を確認すればよいか、Armadillo１台あたりに最大何台までカメラを接続できるのか判断がしづらい状況です。
こちらに関して、なにか参考にできる情報がありましたらご提供いただきたく投稿させていただきました。
使用している環境は以下の通りです。不足している情報がありましたらご連絡よろしくお願いいたします。
・カメラ：IPカメラ(ArmadilloにはLANケーブル経由で接続し、RTSPコマンドを使用して映像を取得)
・配信の際に、H.265→H.264に変換するためにvpuenc_h264を使用
・言語：C++
・配信サービス：Amazon Kinesis Video Streams WebRTC
https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c
コメント
jfurukawa
> jfurukawaさん
>
>
> 参考になるか分かりませんが、添付した vivtop プログラムで VPU の処理能力を確認できますので、おそらくカメラ8台を越えると Busy time が 100% になって処理が間に合ってないと思います。
>
>
> # パッケージのインストール > # このフォーラムで apk ファイルを添付できないため tar に包んでいます > armadillo:~# mount /dev/sda1 /mnt > armadillo:~# cd /mnt > armadillo:/mnt# tar xvf vivtop-0.1-r0.apk.tar > vivtop-0.1-r0.apk > armadillo:/mnt# apk add ./vivtop-0.1-r0.apk > (1/1) Installing vivtop (0.1-r0) > Executing busybox-1.36.1-r2.trigger > OK: 232 MiB in 235 packages > > # 実行例。1秒毎に VPU の使用率を表示しています > # 使い終わったら ctrl-C で停止してください。 > armadillo:/mnt# vivtop > pid total reserved contiguous nonpaged command > - 19134041 18552409 581632 0 Used total > 17560 1237248 655616 581632 0 /usr/bin/weston > 17568 17896793 17896793 0 0 /vol_app/factory_signage_app > - 249301415 - - - Free > Busy time: unknown > > - 19134041 18552409 581632 0 Used total > 17560 1237248 655616 581632 0 /usr/bin/weston > 17568 17896793 17896793 0 0 /vol_app/factory_signage_app > - 249301415 - - - Free > Busy time: 26% > > - 19134041 18552409 581632 0 Used total > 17560 1237248 655616 581632 0 /usr/bin/weston > 17568 17896793 17896793 0 0 /vol_app/factory_signage_app > - 249301415 - - - Free > Busy time: 15% > > ^C >
>
> よろしくお願いします。
マルティネ様
お世話になっております。確認用のプログラムをご展開いただきありがとうございます。
こちらを使って確認してみます。
jfurukawa
at_dominique.m…
jfurukawaさん
ご確認ありがとうございます。
> ご提供いただいたプログラムを使って確認しましたが、映像が表示されなくなった前後もbusyTimeが100%になることはありませんでした。
> 他に何か原因が考えられましたらご教示いただけますと幸いです。
処理能力だけではなく VPU が使用可能なメモリの消費も原因になっている可能性がありますので、お手数ですが表示されなくなった前後の出力を提供いただけますでしょうか（こちらでも再現できると思いますが、ある情報で分かればはやく回答できますのでお願いします）
VPU を使うプロセスが10を越えた場合にツールが把握しない可能性もありますので、念のため vivtop -n 100 で実行してみてください
また、CPU/メモリで問題なさそうということですが、念のため問題が発生している再に以下のコマンドの出力もお願いします：
* 「busybox top -n 1 |head -n 3」
* 「free -m」
* 「cat /sys/class/block/zram0/mm_stat」
よろしくお願いします。
jfurukawa
> jfurukawaさん
>
> ご確認ありがとうございます。
>
> > ご提供いただいたプログラムを使って確認しましたが、映像が表示されなくなった前後もbusyTimeが100%になることはありませんでした。
> > 他に何か原因が考えられましたらご教示いただけますと幸いです。
>
> 処理能力だけではなく VPU が使用可能なメモリの消費も原因になっている可能性がありますので、お手数ですが表示されなくなった前後の出力を提供いただけますでしょうか（こちらでも再現できると思いますが、ある情報で分かればはやく回答できますのでお願いします）
> VPU を使うプロセスが10を越えた場合にツールが把握しない可能性もありますので、念のため vivtop -n 100 で実行してみてください
>
> また、CPU/メモリで問題なさそうということですが、念のため問題が発生している再に以下のコマンドの出力もお願いします：
> * 「busybox top -n 1 |head -n 3」
> * 「free -m」
> * 「cat /sys/class/block/zram0/mm_stat」
>
> よろしくお願いします。
>
マルティネ様
お世話になっております。
現象が起きたときのコマンド実行結果を添付ファイルで送付いたします。
ご確認のほどよろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| memory_vpu.txt | |
| vivtop.txt |
at_dominique.m…
jfurukawaさん
> 現象が起きたときのコマンド実行結果を添付ファイルで送付いたします。
> ご確認のほどよろしくお願いいたします。
ログありがとうございます。
一つ気になりなりましたが、vivtop.txt では左の pid の欄が数秒で変更されます（flutter_app も消えているサンプルもあります）
一定の処理能力を越えた場合にアプリがクラッシュして、podman のコンテナ設定で (デフォルト set_restart on-failure)繰り返し起動されているように見えます。
「podman logs [コンテナ名]」 で何かのエラーが表示されてますでしょうか？アプリ再起動直前に停止の理由を書いているかもしれません。
また、完全に停止されますので、処理が間に合わないよりはメモリ不足の可能性が高いと思いますが、Busy time の値について注意点があります。
プロセスの寿命が短いと NXP からいただいてるインターフェースでは処理時間を図れないので、 0/unknown の値をあまり信用できません。
すでに確認の上かもしれませんが、正常に表示されている 6 と 7 カメラでの Busy time の値を比べて、その差を1回や2回にまた足すと 100% を越えていないかを確認した方が確実です。
ひとまずは podman logs の確認をお願いします
よろしくお願いします。
jfurukawa
at_dominique.m…
jfurukawaさん
マルティネです。
> ご返信が遅くなり申し訳ありません。
> podman logsコマンドを使用して確認してみましたがそれらしきlogは見当たりませんでした。
>
> 他に確認方法があればご教示いただけますと幸いです。
コンテナのリスタートの理由によりますので確実な方法はありません。
podman logs でエラーメッセージがなくとも、コンテナの再起動自体は確認できましたか？例えば、コンテナの起動時にメッセージが表示されていた場合に podman logs で何回か表示されていますか。
その場合はログが残らなくても必ず停止の原因がありますので、理由を調べるしかないです。デフォルトの 「set_restart on-failure」では set_command として設定されているコマンドが 0 意外のコードで停止されていますので、プログラムが exit() を読んでいるか、abort や segmentation fault を考えれます。
後者の場合にログがあるはずですので、何かのエラーでログせずに exit() を呼んでしまうのが一番厄介ですね…
その場合はいくつかのツールがありますが、使い方が難しいですので exit しそうなところに printf を追加した方がはやいかもしれません。
また、今の回答とは関係ないですが、他のアイデアとして：
* gstreamer のアプリケーションだと思いますので GST_DEBUG=3 等でログを増やしてみると何か分かるかもしれません
* 別の確認方法になりますが8本のストリームでエラーになることの確認がすでにできている場合は 7本のストリームで設定して、別のコンテナで１本のダミーストリームを配信すればどういう動きしているかなどの確認がとりやすいかもしれません。
お手数ですがよろしくお願いします。
jfurukawa
マルティネ様
お世話になっております。
現象の確認、ログの解析に時間がかかりご返信が遅くなりました。申し訳ございません。
GST_DEBUG=3 に設定後
上限数を超えてカメラを接続した場合(今回のケースだと9台)に、怪しいログがありましたので
添付ファイルにて送付させていただきます。
ログ名：VCEncInit: ERROR Initialization failed
こちら今回の原因のものかご確認をいただけますでしょうか。恐れ入りますがよろしくお願いいたします。
| ファイル | ファイルの説明 |
|---|---|
| Error_Play_9Camera_h265.txt |
at_dominique.m…
jfurukawaさん
お世話になっています、
マルティネです。
> 現象の確認、ログの解析に時間がかかりご返信が遅くなりました。申し訳ございません。
長い解析お疲れさまです。
> GST_DEBUG=3 に設定後
> 上限数を超えてカメラを接続した場合(今回のケースだと9台)に、怪しいログがありましたので
> 添付ファイルにて送付させていただきます。
>
> ログ名：VCEncInit: ERROR Initialization failed
間違いなく原因ですね。
その文字列を検索した結果、NXP からいただいたバイナリ（/opt/firmware/usr/lib/aarch64-linux-gnu/libhantro_vc8000e.so.1）に発生したエラーになりますので、詳しい失敗の原因は解析しにくい状態です。
（そのバイナリは ATDE で make-imxlibpkg を実行すると NXP のサーバーからダウンロードする物で、ソースを持ち合わせていません…）
細かい解析はライセンス上できないと思いますが、メモリの制限でなければ単純にハードウェアとして 8 本のストリーム以上を同時に処理できない可能性がありますね…関心なところで力になれずに申し訳ございません。
一方、その次の行「vpuenc gstvpuenc.c:882:gst_vpu_enc_open_vpu:[00m opening new VPU handle failed: failure」でしたら https://github.com/nxp-imx/imx-gst1.0-plugin の plugins/vpu/gstvpuenc.c で VPU_EncOpenSimp() が失敗した再に出力されてますが、それで gstreamer が encoding できなくなることで間違いないと思います。
今更ですが、本件は IP カメラをロカールネットワークから別のネットワークに転送したいで間違いないですね？その decoding/encoding の処理を armadillo で行う必要がありますでしょうか？ IP カメラのストリームをそのまま転送すれば数を増やせるかもしれませんがいかがでしょうか。（今度はネットワークの出力スピード制限に当たるかもしれません…）
よろしくお願いします
jfurukawa
マルティネ様
お忙しいところご確認・ご回答いただきありがとうございます。
> 間違いなく原因ですね。
> その文字列を検索した結果、NXP からいただいたバイナリ（/opt/firmware/usr/lib/aarch64-linux-gnu/libhantro_vc8000e.so.1）に発生したエラーになりますので、詳しい失敗の原因は解析しにくい状態です。
> （そのバイナリは ATDE で make-imxlibpkg を実行すると NXP のサーバーからダウンロードする物で、ソースを持ち合わせていません…）
> 今更ですが、本件は IP カメラをロカールネットワークから別のネットワークに転送したいで間違いないですね？その decoding/encoding の処理を armadillo で行う必要がありますでしょうか？ IP カメラのストリームをそのまま転送すれば数を増やせるかもしれませんがいかがでしょうか。（今度はネットワークの出力スピード制限に当たる>かもしれません…）
複数のIPカメラをストリームするときに
一律のFPS、解像度でストリームすること。
H.265のカメラ映像をH.264にdecode/encodeするという要望があるので難しいかもしれません...
ひとまず、同じ条件のときに8台以上のIPカメラは配信できないようにアプリ側で制限を行うなどで対処をしていくように検討をしていきたいと思います。
ご確認いただきありがとうございました。
at_dominique.m…
2024年7月31日 9時47分
jfurukawaさん
> 情報が少ない中で申し訳ございませんが、１台のArmadillo-IoT G4で何台のカメラ映像を配信できるかという検証を行っております。
> H.265コーデックのカメラで配信を行った場合は、８台を超えたあたりからカメラの映像が配信先の方で表示されなくなりますがCPU、メモリの使用率等に問題があるわけではないためどの部分を確認すればよいか、Armadillo１台あたりに最大何台までカメラを接続できるのか判断がしづらい状況です。
>
> こちらに関して、なにか参考にできる情報がありましたらご提供いただきたく投稿させていただきました。
参考になるか分かりませんが、添付した vivtop プログラムで VPU の処理能力を確認できますので、おそらくカメラ8台を越えると Busy time が 100% になって処理が間に合ってないと思います。
# パッケージのインストール # このフォーラムで apk ファイルを添付できないため tar に包んでいます armadillo:~# mount /dev/sda1 /mnt armadillo:~# cd /mnt armadillo:/mnt# tar xvf vivtop-0.1-r0.apk.tar vivtop-0.1-r0.apk armadillo:/mnt# apk add ./vivtop-0.1-r0.apk (1/1) Installing vivtop (0.1-r0) Executing busybox-1.36.1-r2.trigger OK: 232 MiB in 235 packages # 実行例。1秒毎に VPU の使用率を表示しています # 使い終わったら ctrl-C で停止してください。 armadillo:/mnt# vivtop pid total reserved contiguous nonpaged command - 19134041 18552409 581632 0 Used total 17560 1237248 655616 581632 0 /usr/bin/weston 17568 17896793 17896793 0 0 /vol_app/factory_signage_app - 249301415 - - - Free Busy time: unknown - 19134041 18552409 581632 0 Used total 17560 1237248 655616 581632 0 /usr/bin/weston 17568 17896793 17896793 0 0 /vol_app/factory_signage_app - 249301415 - - - Free Busy time: 26% - 19134041 18552409 581632 0 Used total 17560 1237248 655616 581632 0 /usr/bin/weston 17568 17896793 17896793 0 0 /vol_app/factory_signage_app - 249301415 - - - Free Busy time: 15% ^Cよろしくお願いします。