r_kawai
2023年8月10日 12時23分
いつもお世話になっております。
標題の件について、gstreamer1.0-imx 4.6.0-3を使用して動画を再生すると映像がカクカクする現象が見えています。
1つ前のバージョンのgstreamer1.0-imx 4.6.0-2だと発生しておりません。
原因、対策についてわかりましたらご教示頂けませんでしょうか。
■背景
https://armadillo.atmark-techno.com/forum/armadillo/12741
でepiphanyでVPU使用する件について質問させて頂きましたが、この対応として昨年12月にpodmanイメージ(旧イメージ)を作成しました。
今年の7月頭にpodmanイメージをアップデートしたところ(新イメージ)、epiphany上でyoutubeやカメラ、mp4を再生時に映像がカクカクする現象が発生するようになりました。
新イメージにインストールされているパッケージ一覧はpackage_list.txtとなります。
旧イメージと新イメージとで映像に関連しそうなパッケージとして以下の差分があったので、試しにgstreamer1.0-imxとlibgstreamer-imxを4.6.0-2にダウングレードしてみたところ、現象が改善しました。
< ii gstreamer1.0-imx 4.6.0-2 arm64 Gstreamer freescale plugins > ii gstreamer1.0-imx 4.6.0-3 arm64 Gstreamer freescale plugins < ii libgstreamer-imx 4.6.0-2 arm64 Gstreamer freescale plugins > ii libgstreamer-imx 4.6.0-3 arm64 Gstreamer freescale plugins
また、
https://armadillo.atmark-techno.com/forum/armadillo/14322
でメモリリーク等の対応をされていたとのことでしたので、4.6.0-3での対応が影響している可能性があるのではないかと推測し、本件投稿させていただきました。
■その他ソフト構成
・rootfs：v3.17-at.7
・kernel：linux-at-x2-5.10.185-r0
・imx firmware：2.2.0
rootfs、kernelには弊社で一部対応を追加していますが、映像関連は変更していません。
■確認したこと
epiphanyでカクカクすることを確認した動画(youtubeやカメラ、mp4)は全てh264となります。他のコーデックは確認していません。
検証のために4.6.0-3環境で、epiphanyではなく以下のようにgst-launchで試してみましたが、同様に現象が発生しました。
gst-launch-1.0 -v filesrc location=/var/app/volumes/sample-30s.mp4 ! qtdemux ! h264parse ! vpudec ! waylandsink
使用した動画は以下となります。
https://download.samplelib.com/mp4/sample-30s.mp4
動画のFPSは30ですが、上記コマンドの出力を見ると、4.6.0-3環境では再生時のFPSは15程度となっているようでした。
Execution ended after 0:00:09.983135098 Setting pipeline to NULL ... Total showed frames (148), playing for (0:00:09.983077598), fps (14.825). Freeing pipeline ...
一方、4.6.0-2環境では30FPSで再生されているようでした。
割り込み: パイプラインを停止しています... Execution ended after 0:00:05.410085598 Setting pipeline to NULL ... Total showed frames (164), playing for (0:00:05.410049347), fps (30.314). Freeing pipeline ...
また、以下のようにgstreamerのログを有効にして、4.6.0-2、4.6.0-3のそれぞれでログを取得したのでそれぞれ貼付いたします。(gst_4.6.0-2.log、gst_4.6.0-3.log)
export GST_DEBUG="3" export GST_DEBUG_NO_COLOR=1
4.6.0-3の方のみ以下のようなログが出続けており、映像がカクカクする現象に何か関係しているのではないかと考えています。
0:00:00.347278832 242 0xaaaaf8d384c0 WARN vpu_dec_object gstvpudecobject.c:1050:gst_vpu_dec_object_send_output:<vpudecobject0> gst_video_decoder_get_frame failed. 0:00:00.352806623 242 0xaaaaf8d384c0 WARN vpu_dec_object gstvpudecobject.c:1050:gst_vpu_dec_object_send_output:<vpudecobject0> gst_video_decoder_get_frame failed. 0:00:00.382685346 242 0xaaaaf8d384c0 WARN vpu_dec_object gstvpudecobject.c:1050:gst_vpu_dec_object_send_output:<vpudecobject0> gst_video_decoder_get_frame failed. 0:00:00.388451888 242 0xaaaaf8d384c0 WARN vpu_dec_object gstvpudecobject.c:1050:gst_vpu_dec_object_send_output:<vpudecobject0> gst_video_decoder_get_frame failed. 0:00:00.395540441 242 0xaaaaf8d384c0 WARN vpu_dec_object gstvpudecobject.c:956:gst_vpu_dec_object_process_qos:<vpudecobject0> decoder can't catch up. need drop frame. 0:00:00.402751370 242 0xaaaaf8d384c0 WARN vpu_dec_object gstvpudecobject.c:975:gst_vpu_dec_object_process_qos:<vpudecobject0> decoder can catch up. needn't drop frame. diff: 227060214
| ファイル | ファイルの説明 |
|---|---|
| gst_4.6.0-2.log | gstreamer-imxプラグイン4.6.0-2のログ |
| gst_4.6.0-3.log | gstreamer-imxプラグイン4.6.0-3のログ |
| package_list.txt | 現象が発生するpodmanイメージにインストールされたパッケージ一覧 |
コメント
r_kawai
at_dominique.m…
r_kawaiさん
大変お待たせしました、
マルティネです。
いただいたサンプルと以前メモリリークしていたサンプルを比べてみて、カクカクせずにリークを回避してみました。
残念ながらいい区別方法を発見できず、ひとまず、今の 4.6.0-3 バージョンでリークが起きそうなところに実際に現在処理中のバッファー数を確認して判断するようにしました。
「sample-30s.mp4」ではフレームの数が安定しているので、ドロップせずに処理されています。
NXP にも連絡を入れて、もっと適切な修正がないかを確認しているところですが、とりあえず今の 4.6.0-3 よりは改善になっていますので今月末にリリースしようと考えてみます。
それまでに確認したい場合は deb ファイルを添付しましたので、アーカイブの「gstreamer1.0-imx_4.6.0-4_arm64.deb」をインストールしてみていただければと思います。
よろしくお願いします。
| ファイル | ファイルの説明 |
|---|---|
| gstreamer1.0-imx_4.6.0-4_deb.tar.gz |
r_kawai
マルティネ様
お忙しいところご対応いただきありがとうございます。
取り急ぎですが、こちらでもご提供頂いた4.6.0-4で「sample-30s.mp4」の映像が改善していることを確認しました。
ただ、epiphany上でカメラ映像を表示して確認したところ、4.6.0-3よりは改善しているものの、4.6.0-2と比べると若干カクカクしているようには見えております。
(フレーム数が安定しているとドロップされないとのことでしたが、カメラ映像の場合ビットレートに合わせてフレームレートが変化しているかもしれないので、ドロップされやすいのではないかと推測しております)
＞NXP にも連絡を入れて、もっと適切な修正がないかを確認しているところです
お手数をおかけしますが、引き続きよろしくお願いいたします。
＞とりあえず今の 4.6.0-3 よりは改善になっていますので今月末にリリースしようと考えてみます。
こちらでも4.6.0-4で動作はもう少し見てみたいと思います。
at_dominique.m…
r-kawaiさん
お世話になっています、
マルティネです。
> ただ、epiphany上でカメラ映像を表示して確認したところ、4.6.0-3よりは改善しているものの、4.6.0-2と比べると若干カクカクしているようには見えております。
> (フレーム数が安定しているとドロップされないとのことでしたが、カメラ映像の場合ビットレートに合わせてフレームレートが変化しているかもしれないので、ドロップされやすいのではないかと推測しております)
ご確認ありがとうございます。
epiphany を実行する時に「GST_DEBUG=vpu_dec_object:3」で実行すると、4.6.0-3/4 の時のワーニングだけが表示されますので確認しやすいと思います。
メッセージが出力されてなければ影響ないはずです。
どのみち、ログが大量に生成されますので不便かもしれませんが、変数のレベルを「GST_DEBUG=vpu_dec_object:9」にした時の出力を再現した時に取得できれば大変助かります。
（もしくは、カメラのストリームを decode せずに filesink location=file.ts 等に保存してそれで再現できたらさらに便利ですが、難しい場合は助記のログだけでなんとかなると思います）
何か動きがあればまた連絡します。
よろしくお願いします。
r_kawai
マルティネ様
> ただ、epiphany上でカメラ映像を表示して確認したところ、4.6.0-3よりは改善しているものの、4.6.0-2と比べると若干カクカクしているようには見えております。
誤解を招く表現でしたので訂正させていただきます。
実際には常時カクカクしているのではなく、時々数秒程度カメラ映像が停止する動きとなります。
言葉での説明で分かりづらく申し訳ありませんが、今まで確認した限りでは、10FPS程度で撮影されたカメラ動画に対して、
4.6.0-3ではepiphany上での表示は1FPSを切っている(数秒に1回程度しか映像が更新されない)ように見えました。
4.6.0-2、4.6.0-4では数FPS程度で表示されているように見えましたが、時々映像が停止し、その頻度が4.6.0-4の方が高く見えています。
> どのみち、ログが大量に生成されますので不便かもしれませんが、変数のレベルを「GST_DEBUG=vpu_dec_object:9」にした時の出力を再現した時に取得できれば大変助かります。
4.6.0-3/4のそれぞれについてご教示頂いたオプションを有効にしてログを取得いたしましたので、お手数をおかけしますがご確認をお願いいたします。
(ログ内のurlの情報は少し手を加えています)
4.6.0-3では「VPU hasn't consumed partial input data, dropping frame anyway」が出力されていますが、4.6.0-4では出力されておりませんでした。
また、「GST_DEBUG=vpu_dec_object:3」を指定した場合、4.6.0-4ではログが出力されませんでした。
「GST_DEBUG=3,vpu_dec_object:9」として全カテゴリのログも出力してみたところ、カメラ映像が停止するタイミングと一致しているかは確認できていないのですが、気になる箇所として4.6.0-4でのみ以下のようなログが出力されていました。
0:00:15.397430577 272 0xfffdf00136a0 WARN basesink gstbasesink.c:3132:gst_base_sink_is_too_late:<webkit-gl-video-appsink> warning: A lot of buffers are being dropped. 0:00:15.397476953 272 0xfffdf00136a0 WARN basesink gstbasesink.c:3132:gst_base_sink_is_too_late:<webkit-gl-video-appsink> warning: There may be a timestamping problem, or this computer is too slow.
ログ名とログレベルは以下のように対応しています。
gst*.vpu_dec_object3.log：「GST_DEBUG=vpu_dec_object:3」
gst*.vpu_dec_object9.log：「GST_DEBUG=vpu_dec_object:9」
gst*.vpu_dec_object9-other3.log：「GST_DEBUG=3,vpu_dec_object:9」
> （もしくは、カメラのストリームを decode せずに filesink location=file.ts 等に保存してそれで再現できたらさらに便利ですが、難しい場合は助記のログだけでなんとかなると思います）
周囲の映像が映っているので、現時点ではひとまずログのみのご提供とさせていただきたいと思います。
(今後必要になりましたら別途メール等にてご提供させて頂ければと思います)
補足ですが、こちらで
gst-launch-1.0 souphttpsrc location=xxx.m3u8 ! hlsdemux ! filesink location=test.ts
のようにストリームを保存した後に
gst-launch-1.0 playbin uri="file://$(pwd)/test.ts"
で再生した場合は映像が停止する現象は発生しませんでした。
PC上でも確認しましたが、PCとG4とで映像の滑らかさに特に違いは無いように見えました。
そのため、カメラ映像が停止する現象について、epiphany(webkit)も何か関連している可能性があるのではないかなと少し考えています。
ログの情報が不足していましたらご指摘ください。ログを取得し直したいと思います。
at_dominique.m…
r_kawaiさん
マルティネです。
> 誤解を招く表現でしたので訂正させていただきます。
> 実際には常時カクカクしているのではなく、時々数秒程度カメラ映像が停止する動きとなります。
>
> 言葉での説明で分かりづらく申し訳ありませんが、今まで確認した限りでは、10FPS程度で撮影されたカメラ動画に対して、
> 4.6.0-3ではepiphany上での表示は1FPSを切っている(数秒に1回程度しか映像が更新されない)ように見えました。
> 4.6.0-2、4.6.0-4では数FPS程度で表示されているように見えましたが、時々映像が停止し、その頻度が4.6.0-4の方が高く見えています。
訂正ありがとうございます、分かりました。
> 4.6.0-3/4のそれぞれについてご教示頂いたオプションを有効にしてログを取得いたしましたので、お手数をおかけしますがご確認をお願いいたします。
> (ログ内のurlの情報は少し手を加えています)
ログありがとうございます。
4.6.0-3 でやはりパッチの影響でフレームを drop しすぎて、「gst_video_decoder_get_frame failed.」の影響で表示できるところを表示してなかったので、そこは確実によくなったと思います。
（4.6.0-4 での「system frame number send out: 73 list length: 4」メッセージをみて、リストが暴走してないことも確認できたので、リークしていないところで問題ないですね）
ひとまず、今回対応したかった「waylandsink でのカクカク」は 4.6.0-4 で発生してないことを確認できました。
> 4.6.0-3では「VPU hasn't consumed partial input data, dropping frame anyway」が出力されていますが、4.6.0-4では出力されておりませんでした。
> また、「GST_DEBUG=vpu_dec_object:3」を指定した場合、4.6.0-4ではログが出力されませんでした。
>
> 「GST_DEBUG=3,vpu_dec_object:9」として全カテゴリのログも出力してみたところ、カメラ映像が停止するタイミングと一致しているかは確認できていないのですが、気になる箇所として4.6.0-4でのみ以下のようなログが出力されていました。
> 0:00:15.397430577 272 0xfffdf00136a0 WARN basesink gstbasesink.c:3132:gst_base_sink_is_too_late:<webkit-gl-video-appsink> warning: A lot of buffers are being dropped. > 0:00:15.397476953 272 0xfffdf00136a0 WARN basesink gstbasesink.c:3132:gst_base_sink_is_too_late:<webkit-gl-video-appsink> warning: There may be a timestamping problem, or this computer is too slow.
このワーニングは確かに関係ありそうですね。
そこのコードを確認したところ、フレームが遅かった場合に CPU を節約するために表示しないようにしているところで、遅くても過去一秒以内に何も表示されてなかった場合にこのメッセージを表示してそのフレームを表示します。
ちょうど一秒に一つのフレームしか表示しないパターンになりますので、今の問題の説明とあっていると思います。
間に合わなくても decoding の処理をスキップできないので、間に合わなく始めたらいやなところですね…
ちなみに、この問題はログを表示させると発生しやすいと思いますが、ログと関係なく、明らかに 3.6.0-4 が 3.6.0-2 より発生率が多く感じると言うことであってますか？
また、epiphany の差があれば webkit のアップグレードで処理が変わった効率やや悪くなった可能性もありますので、epiphany のアップデートではなく gst のプラグインだけのアップデートでの差を確認したかったです。
gst_4.6.0-4.vpu_dec_object9-other3.log では 45秒内に7回ぐらい起きてますので、かなり多いですね。一秒未満のフレーズもログに出力されないと考えるとかなりひどいですね…
CPU不足の問題でしたら、 3.6.0-4 が確かにlist_length() の計算が何回か追加されていますが、リストが短い（1-12アイテム）ので G4 の CPU では差を感じれるほどの違いがないはずです（確認したところ、20アイテムのリストの g_list_length() は .05us ぐらいかかりますので、フレームが間に合うか間に合わないの差になるとは思えないですね…）
> > （もしくは、カメラのストリームを decode せずに filesink location=file.ts 等に保存してそれで再現できたらさらに便利ですが、難しい場合は助記のログだけでなんとかなると思います）
>
> 周囲の映像が映っているので、現時点ではひとまずログのみのご提供とさせていただきたいと思います。
> (今後必要になりましたら別途メール等にてご提供させて頂ければと思います)
承知しました。
とりあえずこちらで epiphany 経由で他のファイルで再現できないか試してみます、ちょっと時間ください。
前回の返事に書いた様に、完全に修正されてなくても 3.6.0-3 よりはいいのでとりあえず一旦このパッケージで更新して、引き続きその問題も確認します。
> 補足ですが、こちらで
> gst-launch-1.0 souphttpsrc location=xxx.m3u8 ! hlsdemux ! filesink location=test.ts
> のようにストリームを保存した後に
> gst-launch-1.0 playbin uri="file://$(pwd)/test.ts"
> で再生した場合は映像が停止する現象は発生しませんでした。
> PC上でも確認しましたが、PCとG4とで映像の滑らかさに特に違いは無いように見えました。
> そのため、カメラ映像が停止する現象について、epiphany(webkit)も何か関連している可能性があるのではないかなと少し考えています。
はい、私もそう思っています。
私がテストしていた環境も gst-launch を直接に実行していただけですが、epiphany はおそらく waylandsink より性能は低いと思われます。
このプロジェクトを開発していた時点では Armadillo IoT G4/X2 の flutter 実装がまだできていませんでしたが、epiphany の gstreamer widget がフレームをコピーしていたら flutter に移植した方が効率よくなります（dmabuf という機能で、フレームのデーターをコピーせずに表示することはできます）
flutter で gstreamer の widget を使えますし、インターネットからの情報も取得できますのでページの作りは簡単でしたらその移植もそんなに難しくなくて、epiphany で頑張るよりやりがいのある方向だと思います。
とりあえずこれから epiphany の動作確認して、改善の余地があるかどうかを確認します。
次の返事はまた来週になりそうですが、よろしくお願いします。
r_kawai
マルティネ様
詳細な解説いただきありがとうございます。大変勉強になります。
私の知識が足りていない部分が多いので、頂いた情報をもとにこちらでも調べていきたいと思います。
さしあたって現時点で回答できる箇所について回答いたします。
> ただ、epiphany上でカメラ映像を表示して確認したところ、4.6.0-3よりは改善しているものの、4.6.0-2と比べると若干カクカクしているようには見えております。
後出しの情報が多く大変申し訳ありません。
上記確認を行っていた際には、youtube画面も同時に表示しており、epiphany上でyoutubeとカメラ映像を再生している状態でした。
https://armadillo.atmark-techno.com/forum/armadillo/16618#comment-14069
で4.6.0-4でカクカクしているとお伝えした際には、youtube＋カメラ映像を同時に再生して確認していました。
一方、
https://armadillo.atmark-techno.com/forum/armadillo/16618#comment-14088
でログ取得時は切り分けのためにカメラ映像1画面で確認しており条件が変わっています。
改めて確認したところ、カメラ映像1画面のみ表示の場合は、体感とはなりますが、4.6.0-2と4.6.0-4とで映像の停止頻度に差はないように見えました。
youtube＋カメラ映像をepiphanyで表示した場合、メモリの使用量が急激に増え、「cma_alloc: alloc failed」エラーが発生することがあるので、4.6.0-2と4.6.0-4とで差分があるように見えたのは、その時点で4.6.0-4ではメモリが不足していたのかもしれません。
以下ご参考までにyoutube＋カメラ映像の環境で、改めて4.6.0-4で取得したメモリ使用量になります。
コンテナ起動前はメモリは余裕がありますが、コンテナを起動してyoutube＋カメラ映像を表示するとかなりメモリの消費量が多くなっているように見えます。
「cma_alloc: alloc failed」が発生したあたりでは動画は停止したり不安定だったと思います。
# while true; do free; grep -i cma /proc/meminfo ; sleep 5; done ... [2023-08-25 11:20:43.426] total used free shared buff/cache available [2023-08-25 11:20:43.432] Mem: 1969800 388444 1331472 1292 249884 1510328 [2023-08-25 11:20:43.437] Swap: 1048572 15616 1032956 [2023-08-25 11:20:43.443] CmaTotal: 950272 kB [2023-08-25 11:20:43.443] CmaFree: 616688 kB ★コンテナ起動 [2023-08-25 11:20:48.437] total used free shared buff/cache available [2023-08-25 11:20:48.443] Mem: 1969800 928200 667348 26872 374252 944292 [2023-08-25 11:20:48.449] Swap: 1048572 15616 1032956 [2023-08-25 11:20:48.454] CmaTotal: 950272 kB [2023-08-25 11:20:48.454] CmaFree: 284940 kB [2023-08-25 11:20:53.459] total used free shared buff/cache available [2023-08-25 11:20:53.465] Mem: 1969800 1028616 563108 27900 378076 843832 [2023-08-25 11:20:53.470] Swap: 1048572 15616 1032956 [2023-08-25 11:20:53.476] CmaTotal: 950272 kB [2023-08-25 11:20:53.476] CmaFree: 261356 kB [2023-08-25 11:20:58.466] total used free shared buff/cache available [2023-08-25 11:20:58.470] Mem: 1969800 1187340 370100 27900 412360 685192 [2023-08-25 11:20:58.476] Swap: 1048572 15616 1032956 [2023-08-25 11:20:58.481] CmaTotal: 950272 kB [2023-08-25 11:20:58.481] CmaFree: 200256 kB [2023-08-25 11:21:03.472] total used free shared buff/cache available [2023-08-25 11:21:03.478] Mem: 1969800 1431948 75060 27888 462792 440616 [2023-08-25 11:21:03.482] Swap: 1048572 15616 1032956 [2023-08-25 11:21:03.488] CmaTotal: 950272 kB [2023-08-25 11:21:03.488] CmaFree: 34896 kB ... [2023-08-25 11:21:58.615] total used free shared buff/cache available [2023-08-25 11:21:58.621] Mem: 1969800 1661404 62520 2396 245876 236464 [2023-08-25 11:21:58.626] Swap: 1048572 305920 742652 [2023-08-25 11:21:58.632] CmaTotal: 950272 kB [2023-08-25 11:21:58.632] CmaFree: 19944 kB [2023-08-25 11:22:03.627] total used free shared buff/cache available [2023-08-25 11:22:03.633] Mem: 1969800 1679292 58908 2396 231600 218828 [2023-08-25 11:22:03.638] Swap: 1048572 321792 726780 [2023-08-25 11:22:03.643] CmaTotal: 950272 kB [2023-08-25 11:22:03.643] CmaFree: 22536 kB [2023-08-25 11:22:07.009] [ 6782.852526] cma: cma_alloc: alloc failed, req-size: 893 pages, ret: -16 [2023-08-25 11:22:08.644] total used free shared buff/cache available [2023-08-25 11:22:08.649] Mem: 1969800 1665532 77812 2396 226456 232568 [2023-08-25 11:22:08.657] Swap: 1048572 326144 722428 [2023-08-25 11:22:08.660] CmaTotal: 950272 kB [2023-08-25 11:22:08.660] CmaFree: 35668 kB
また、こちらもご参考までにですが、カメラ1画面の再生で、epiphanyとgst-launchとでメモリ消費量はかなり違って見えました。
・epiphanyで再生
total used free shared buff/cache available Mem: 1969800 1196528 313012 7752 460260 694480 Swap: 1048572 10240 1038332 CmaTotal: 950272 kB CmaFree: 156636 kB
・gst-launch(gst-launch-1.0 playbin uri)で再生
total used free shared buff/cache available Mem: 1969800 518736 746052 5160 705012 1371624 Swap: 1048572 7680 1040892 CmaTotal: 950272 kB CmaFree: 357248 kB
補足ですが、こちらの環境ではCMAはarmadillo_iotg_g4.dtsで上限と思われる値に設定しています。
resmem: reserved-memory {
linux,cma {
size = <0 0x3A000000>;
alloc-ranges = <0 0x40000000 0 0x80000000>;
};
};> ちなみに、この問題はログを表示させると発生しやすいと思いますが、ログと関係なく、明らかに 3.6.0-4 が 3.6.0-2 より発生率が多く感じると言うことであってますか？
体感ではログの有無では映像の停止頻度に特に違いはないように感じました。
ご参考までに、ログの有無のそれぞれについてのtopコマンド結果を以下に記載します。cpu負荷の点ではそれほど差はなさそうに見えました。
(あるタイミングでのスナップショットなのであまり意味はないかもしれませんが)
・GST_DEBUG="3,vpu_dec_object:9"の場合
Mem: 1859004K used, 110796K free, 20388K shrd, 452K buff, 694496K cached CPU: 12% usr 3% sys 0% nic 82% idle 0% io 0% irq 0% sirq Load average: 1.09 0.98 0.75 3/318 12422 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 12191 12051 root S 103g5489% 1 8% /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 54 65 12051 12049 root R 86.9g4607% 2 7% epiphany 11996 11992 root S 438m 23% 1 1% weston --tty 1 --backend=drm-backend.so 12066 12051 root S 86.4g4580% 2 1% /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitNetworkProcess 1 16
・GST_DEBUG無効の場合
Mem: 1902228K used, 67572K free, 28124K shrd, 452K buff, 706616K cached CPU: 12% usr 3% sys 0% nic 83% idle 0% io 0% irq 0% sirq Load average: 1.06 0.98 0.78 2/333 12875 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 12702 12551 root S 103g5487% 1 7% /usr/lib/aarch64-linux-gnu/webkit2gtk-4.0/WebKitWebProcess 61 72 12551 12549 root S 86.8g4604% 3 7% epiphany 12498 12495 root S 439m 23% 1 1% weston --tty 1 --backend=drm-backend.so
> また、epiphany の差があれば webkit のアップグレードで処理が変わった効率やや悪くなった可能性もありますので、epiphany のアップデートではなく gst のプラグインだけのアップデートでの差を確認したかったです。
本件の確認ではgstreamer周りは3.6.0-2～3.6.0-4で変更していますが、webkitやepiphany周りは変更しておりません。
gstreamer関連以外は
https://armadillo.atmark-techno.com/sites/armadillo.atmark-techno.com/f…
に貼付したパッケージを変更せずに使用しております。webkit、gtk関連は以下となります。
ii libgtk-3-0:arm64 3.24.24-4+deb11u3 arm64 GTK graphical user interface library ii libgtk-3-bin 3.24.24-4+deb11u3 arm64 programs for the GTK graphical user interface library ii libgtk-3-common 3.24.24-4+deb11u3 all common files for the GTK graphical user interface library ii libjavascriptcoregtk-4.0-18:arm64 2.40.2-1~deb11u1 arm64 JavaScript engine library from WebKitGTK ii libwebkit2gtk-4.0-37:arm64 2.40.2-1~deb11u1 arm64 Web content engine library for GTK
epiphanyはこちらで少し修正は加えていますが、エラー画面の変更程度なので、映像再生には影響はない認識です。
> とりあえずこれから epiphany の動作確認して、改善の余地があるかどうかを確認します。
> 次の返事はまた来週になりそうですが、よろしくお願いします。
お手数をおかけしますが、よろしくお願いいたします。
at_dominique.m…
r_kawaiさん、
大変お待たせ致しました、
マルティネです。
理解しているところから回答させていただきます。
まずは、CMA の「contiguous memory allocation」は、おっしゃるとおりに「resmem: reserved-memory」の「linux,cma」ブロックで設定できます。
そっちらですでに色々試してわかっていると思いますが、欲張ってそこに大きい値を設定するとメモリの予約が失敗して 512MB で fallback しています。
他の予約を確認したところ、0x56000000-0x58000000 には OPTEE のメモリがあって、移動しにくいですが、実は 0x92400000からの予約は現在不要になっていてそれを無効化すると cma の領域を増やすことはできます。
1/ dsp の予約を無効化する(make dtbs の後に armadillo_iotg_g4.dtb が更新されます）
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index dde207a7f348..009fb4f5bc46 100755
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -194,23 +194,28 @@ linux,cma {
dsp_reserved: dsp@92400000 {
reg = <0 0x92400000 0 0x1000000>;
no-map;
+ status = "disabled";
};
dsp_reserved_heap: dsp_reserved_heap {
reg = <0 0x93400000 0 0xef0000>;
no-map;
+ status = "disabled";
};
dsp_vdev0vring0: vdev0vring0@942f0000 {
reg = <0 0x942f0000 0 0x8000>;
no-map;
+ status = "disabled";
};
dsp_vdev0vring1: vdev0vring1@942f8000 {
reg = <0 0x942f8000 0 0x8000>;
no-map;
+ status = "disabled";
};
dsp_vdev0buffer: vdev0buffer@94300000 {
compatible = "shared-dma-pool";
reg = <0 0x94300000 0 0x100000>;
no-map;
+ status = "disabled";
};
/* used only by tuning tool, can be removed for normal case */2/ CMA の予約を大きくするのは、overlay で行うことをおすすめします（dsp の領域無効化はこちらで行いますので、カスタムなカーネルを必要とされていなければこれからもカーネルと dtb を通常にアップデートできます）
atde:linux$ git diff
diff --git a/arch/arm64/boot/dts/freescale/armadillo_iotg_g4-customize.dts b/arch/arm64/boot/dts/freescale/armadillo_iotg_g4-customize.dts
index dbf416b532b3..c0a87a3957bd 100644
--- a/arch/arm64/boot/dts/freescale/armadillo_iotg_g4-customize.dts
+++ b/arch/arm64/boot/dts/freescale/armadillo_iotg_g4-customize.dts
@@ -12,5 +12,9 @@
#include "imx8mp-pinfunc.h"
-// Replace this empty section by your configuration
-&{/} {};
+&resmem {
+ linux,cma {
+ size = <0 0x60000000>;
+ alloc-ranges = <0 0x40000000 0 0xbfffffff>;
+ };
+};
# dtbs を更新します
atde:linux$ make dtbs
DTC arch/arm64/boot/dts/freescale/armadillo_iotg_g4-customize.dtbo
# 省略の為 scp でコピーします
# SWU で更新する場合は /usr/share/mkswu/examples/dtb_overlay.desc を参考にできます。
atde:linux$ scp arch/arm64/boot/dts/freescale/armadillo_iotg_g4-customize.dtbo armadillo:/boot
# armadillo で使うように設定します
armadillo:~# vi /boot/overlays.txt
fdt_overlays=armadillo_iotg_g4-customize.dtbo
# 永続化して、-p でアップデートでも永続させます。
armadillo:~# persist_file -vp /boot/overlays.txt /boot/armadillo_iotg_g4-customize.dtbo
'/boot/overlays.txt' -> '/mnt/boot/overlays.txt'
Added "/boot/armadillo_iotg_g4-customize.dtbo" to /etc/swupdate_preserve_files
'/boot/armadillo_iotg_g4-customize.dtbo' -> '/mnt/boot/armadillo_iotg_g4-customize.dtbo'この設定では CMA が 1.5GB になります：
armadillo:~# grep -i cma /proc/meminfo CmaTotal: 1572864 kB CmaFree: 704384 kB
普通のアプリケーションもその領域を使えますので、fragmentation されたら GPU で使えなくなりますが、ひとまず epiphany でどうがを同時に2回再生できてなかったところからカクカクせずに2回再生できています。
（同じ理由で、連続で（再起動無しで）テストを行うとメモリ不足に当たって性能が悪くなった可能性は充分にありえると思います、よく見つけてくれました）
3回目のウィンドーで再生しようとすると、メモリ不足のエラーがなくても処理が追いつかない問題になっていて同じ一秒に一回だけ更新されているカクカク現象になっていますので、メモリの問題だけではないと思いますが、ひとまずそれで試していただければと思います。
以上、CMA についてでした。
---------------------------------------------------
話を平行で進めていますが、同時に epiphany の gstreamer pipeline を確認したところ、"imxvideoconvert_g2d" である程度に VPU で CPU の負担を減らしていても最適ではないことも明らかです。
今から epiphany を止めて flutter や別の gstreamer の frontend に移植するのは大変で、すごく勝手な話ですが、任意の website を表示するのではなく、URL を取得して固定した形のビデオの表示だけでしたら flutter での実装にそんなに時間がかからないと思いますので試していただければ幸いです。
r_kawaiさんが開発を始めたころにまだできていませんでしたが、今ならコードのサンプルもマニュアルの説明もできているので、試す分にはすぐできていると思います。(debug モードの性能が低いので、複数のストリームの再生は release モードで試してください)
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
メモリの設定だけで問題がなくなればベストだと考えていますが、epiphany の追加改善が必要でしたらかなりの時間が必要で、あまり深く調べることはできないと思っています。
一旦まとめます：
* 予定どおりに gstreamer1.0-imx の 4.6.0-4 バージョンをリリースして、ひとまず最初に報告していただいた問題はこれで解決されているとします（NXP からの返事は、まだないです…）
* 今月のアップデートに不要な dsp のメモリ予約を無効化して、cma のデフォルトサイズを少し大きくします（evk と同じく 1GB にしようと考えていますが、まだ別のところで悪影響がないかを確認してませんので今のところは何も決めてません）。案内した方法で DTBO が優先されますので、コンフリクトはしません。
* 一秒に一回更新のカクカク問題は未だに残っていて、メモリ設定だけで解決されないと考えていますが試していただけたら幸いです。
* やっぱりダメな場合は、時間がございましたら、flutter も顧慮していただけたら、将来てきには安心できると思いますが、本当に申し訳ございません… 無理との判断でしたらまた相談ぐらいできますので引き続きもよろしくおねがいします。
よろしくお願いします。
r_kawai
マルティネ様
お忙しいところ、いつも詳しく調査、ご回答いただきありがとうございます。
取り急ぎ以下返信させていただきます。
> そっちらですでに色々試してわかっていると思いますが、欲張ってそこに大きい値を設定するとメモリの予約が失敗して 512MB で fallback しています。
ご認識の通り、こちらで確認した際には「resmem: reserved-memory」のsizeを0x3A000000より大きくすると失敗してしまうので、0x3A000000としていました。
> この設定では CMA が 1.5GB になります：
ありがとうございます。ご教示いただいた設定を試してみようと思います。
> * やっぱりダメな場合は、時間がございましたら、flutter も顧慮していただけたら、将来てきには安心できると思います
flutterを製品に組み込むかの方針は関係者との調整が必要ですが、ご教示頂いたマニュアル等をみながら、まずはflutterを試してみたいと思います。
不明点等がありましたら再度質問させていただくかもしれませんが、その際はよろしくお願いいたします。
at_dominique.m…
2023年8月10日 12時51分
r_kawaiさん、
お世話になっています、
マルティネです。
> 標題の件について、gstreamer1.0-imx 4.6.0-3を使用して動画を再生すると映像がカクカクする現象が見えています。
完璧な報告大変助かります、ありがとうございます。
> 1つ前のバージョンのgstreamer1.0-imx 4.6.0-2だと発生しておりません。
> 原因、対策についてわかりましたらご教示頂けませんでしょうか。
調べた通りに、gstreamer1.0-imx 4.6.0-3 でメモリリークを修正したはずでしたが、その過程で別の問題を起こしましたね…すみません。
4.6.0-3 のログにまさに追加した「VPU hasn't consumed partial input data, dropping frame anyway」メッセージが表示されて、再現しなくてもこれでカクカクすることが納得できます。
詳細はこちらで調べたいと思いますので、お手数ですが少し時間ください。
弊社は明日からお盆休みに入りますので、今日中に何か見つからない限り次の返事は来週の木曜日以降になります。
（言われるまでもないと思いますが）それまでは 4.6.0-2 のバージョンのままを使い続けてください。
よろしくお願いします。