jfurukawa
2024年5月22日 18時35分
以下、サンプルコードをコーデックH.265のカメラをRTSP経由で取得した際に、CPU使用率が200％を超える現象が発生しているのですが
ソフトウェアエンコード・デコード処理で処理負荷が大きくなっていることが原因と考えております。
これまでに同様の構成で実績がございましたら対処方法をご教示いただけますと幸いです。
Kinesis Video Streams WebRTCサンプル(https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/tr…)
コメント
jfurukawa
2024年5月23日 12時09分
> > ソフトウェアエンコード・デコード処理で
> H.265カメラから受信するのであれば、エンコードの必要な無さそうですが、
> どのサンプルを動かしている場合の話か、議論を絞り込むことはできるでしょうか。
ご返信ありがとうございます。
以下のURLに示すサンプルを実行している認識です。
https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/bl…
sendGstreamerAudioVideo関数
case RTSP_SOURCEの場合
at_ohsawa
2024年5月23日 14時08分
> https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/bl…
> sendGstreamerAudioVideo関数
> case RTSP_SOURCEの場合
ここでuridecodebinでざっくりなんでもデコードしてみて、
https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/bl…
ここでh264エンコードするということですね。
https://github.com/awslabs/amazon-kinesis-video-streams-webrtc-sdk-c/bl…
uridecodebinについては自動選択するdecodebinなので、rtspのunpackからパイプラインを書き直さないといけないので、
ちょっとアドバイスできるものがないのですが、
エンコードについては
"x264enc name=sampleVideoEncoder bframes=0 speed-preset=veryfast bitrate=512 byte-stream=TRUE tune=zerolatency ! "
この部分を
"vpuenc_h264 name=sampleVideoEncoder bitrate=512 !"
に書き換えてみてください。エンコーダー側はハードウェアエンコーダーが動くと思います。
jfurukawa
2024年5月23日 20時46分
> エンコードについては
> "x264enc name=sampleVideoEncoder bframes=0 speed-preset=veryfast bitrate=512 byte-stream=TRUE tune=zerolatency ! "
> この部分を
> "vpuenc_h264 name=sampleVideoEncoder bitrate=512 !"
> に書き換えてみてください。エンコーダー側はハードウェアエンコーダーが動くと思います。
ご回答いただきありがとうございます。
ご教示いただいた”vpuenc_h264"ですがgst-inspect-1.0コマンドを使用しましたが利用できないようです。
お手数ですが、G4で該当コマンドを使用する方法についてご教示いただけますでしょうか。
以下、gst-inspect-1.0の実行結果も記載させていただきます。
# gst-inspect-1.0 vpuenc_h264
No such element or plugin 'vpuenc_h264
at_ohsawa
2024年5月24日 9時50分
> ご教示いただいた”vpuenc_h264"ですがgst-inspect-1.0コマンドを使用しましたが利用できないようです。
> お手数ですが、G4で該当コマンドを使用する方法についてご教示いただけますでしょうか。
製品マニュアル
6.11. マルチメディアデータを扱う
に従ってat-debian-image(debian bullseyeサンプルコンテナ)をベースにしたコンテナを構築してください。
https://armadillo.atmark-techno.com/resources/software/armadillo-iot-g4…
(ファーウェアライブラリとgstreamerのバージョンの都合この環境以外でのVPU動作は対応していないので
ご注意ください。)
構築のポイントはコンテナの起動設定に
add_devices /dev/mxc_hantro /dev/mxc_hantro_vc8000e
add_volumes /opt/firmware:/opt/firmware:ro
が設定されていることと、
パッケージgstreamer1.0-imx gstreamer1.0-imx-toolsがインストールされていることです。
ファームウェアとコマンドの両方が絡むので切り分けのため、セットアップしたら、
一旦マニュアル通りのコマンドでgstreamerのハードウェアエンコーダーの動作を
確認しておくのが良いと思います。
jfurukawa
2024年5月24日 18時02分
> 製品マニュアル
> 6.11. マルチメディアデータを扱う
> に従ってat-debian-image(debian bullseyeサンプルコンテナ)をベースにしたコンテナを構築してください。
> https://armadillo.atmark-techno.com/resources/software/armadillo-iot-g4…
> (ファーウェアライブラリとgstreamerのバージョンの都合この環境以外でのVPU動作は対応していないので
> ご注意ください。)
>
> 構築のポイントはコンテナの起動設定に
> add_devices /dev/mxc_hantro /dev/mxc_hantro_vc8000e
> add_volumes /opt/firmware:/opt/firmware:ro
> が設定されていることと、
> パッケージgstreamer1.0-imx gstreamer1.0-imx-toolsがインストールされていることです。
>
> ファームウェアとコマンドの両方が絡むので切り分けのため、セットアップしたら、
> 一旦マニュアル通りのコマンドでgstreamerのハードウェアエンコーダーの動作を
> 確認しておくのが良いと思います。
お世話になっております。
ご返信が遅くなりまして申し訳ございません。
先ほど、ご連絡いただいた手順通りに実施してCPU使用率が大幅に減少していることを確認できました。
詳細にご教示いただいたこと心より感謝申し上げます。
at_ohsawa
2024年5月24日 18時34分
jfurukawa
2024年5月28日 14時43分
> ご報告ありがとうございます。
> 一旦、評価いただけるレベルに負荷が落ち着いて良かったです。
>
> (尚、カメラ実機ベースで試行錯誤すればh.265のdecodeの方もvpudec化できるとは思いますが、
> uridecodebinが柔軟性が高すぎるので、ちょっと同等にするには開発いただく必要があるかも
> しれません。カメラの仕様を固定できれば多少簡略化できる可能性はあります.。)
追加の情報をご展開いただきありがとうございます。
Gstreamer 、カメラの設定についてまだ理解が浅い部分がありますのでいただいた情報をもとに改善をしていきたいと思います。
引き続き何卒よろしくお願いいたします。
at_ohsawa
2024年5月22日 19時18分
とくに実績は無いのですが、見たところこのソースはハードウェアエンコーダーは使っていないようですね。
> ソフトウェアエンコード・デコード処理で
H.265カメラから受信するのであれば、エンコードの必要な無さそうですが、
どのサンプルを動かしている場合の話か、議論を絞り込むことはできるでしょうか。