この記事では、さまざまなVPUクロックでのビデオ再生でのi.MX6DQの機能を検証するためのいくつかの実験を行います。
1. 事前準備
Board: i.MX6DQ SD
ビットストリーム:1080pヒマワリ、40Mbps、最もタフなH264クリップと見なされています。元のクリップを 20 回コピーして新しい raw ビデオを生成し (ひまわりクリップを 20 回繰り返します)、mp4 コンテナにカプセル化します。これは、vpu単体テストと比較して、gstreamerの起動ワークロードの影響を排除し、最小限に抑えるためです。
カーネル:270MHz、298MHz、329MHz、352MHz、382MHzの異なるVPUクロック設定で異なるカーネルを生成します。
テスト設定:1080pデバイスでの1080pコンテンツのデコードと表示。(サイズ変更なし)
2. VPU単体テストとGstreamerのテストコマンド
タイル形式のビデオ再生はNV12形式よりも高速であるため、以下の実験では、ビデオ再生中にタイル形式を選択します。
ユニットテストコマンド:(フレームレートを-a 70に設定し、1080p 60fps HDMIリフレッシュレートより高く設定します)
/unit_tests/mxc_vpu_test.out -D "-i /media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.264 -f 2 -y 1 -a 70"
Gstreamerコマンド:(最高の再生速度を得るためのフリーラン)
gst-launch filesrc location=/media/65a78bbd-1608-4d49-bca8-4e009cafac5e/sunflower_2B_2ref_WP_40Mbps.mp4 typefind=true !アイウルデマックス!vpudec framedrop=false !キューの最大サイズバッファ= 3!mfw_v4lsink sync=false です。
3. 動画再生フレームレートの測定
テスト中に、コマンド「echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor」を入力して、CPUが常に最高周波数で動作することを確認し、割り込みに迅速に応答できるようにします。
異なるVPUクロックを持つ各テストポイントに対して、5ラウンドのテストを行います。最大値と最小値は削除され、残りの 3 つのデータが平均化されて最終的な再生フレームレートが取得されます。
| #1 | #2 | #3 | #4 | #5 | Min | 最大 | 平均 | |||||||
| 12月 | 再生 | 12月 | 再生 | 12月 | 再生 | 12月 | 再生 | 12月 | 再生 | 再生 | 再生 | 再生 | ||
| 270M 閲覧数 | ユニット・テスト | 57.8 | 57.3 | 57.81 | 57.04 | 57.78 | 57.3 | 57.87 | 56.15 | 57.91 | 55.4 | 55.4 | 57.3 | 56.83 |
| GSTの | 53.76 | 54.163 | 54.136 | 54.273 | 53.659 | 53.659 | 54.273 | 54.01967 | ||||||
| 298M 閲覧数 | ユニット・テスト | 60.97 | 58.37 | 60.98 | 58.55 | 60.97 | 57.8 | 60.94 | 58.07 | 60.98 | 58.65 | 57.8 | 58.65 | 58.33 |
| GSTの | 56.755 | 49.144 | 53.271 | 56.159 | 56.665 | 49.144 | 56.755 | 55.365 | ||||||
| 329M 閲覧数 | ユニット・テスト | 63.8 | 59.52 | 63.92 | 52.63 | 63.8 | 58.1 | 63.82 | 58.26 | 63.78 | 59.34 | 52.63 | 59.52 | 58.56667 |
| GSTの | 57.815 | 55.857 | 56.862 | 58.637 | 56.703 | 55.857 | 58.637 | 57.12667 | ||||||
| 352メートル | ユニット・テスト | 65.79 | 59.63 | 65.78 | 59.68 | 65.78 | 59.65 | 66.16 | 49.21 | 65.93 | 57.67 | 49.21 | 59.68 | 58.98333 |
| GSTの | 58.668 | 59.103 | 56.419 | 58.08 | 58.312 | 56.419 | 59.103 | 58.35333 | ||||||
| 382M 閲覧数 | ユニット・テスト | 64.34 | 56.58 | 67.8 | 58.73 | 67.75 | 59.68 | 67.81 | 59.36 | 67.77 | 59.76 | 56.58 | 59.76 | 59.25667 |
| GSTの | 59.753 | 58.893 | 58.972 | 58.273 | 59.238 | 58.273 | 59.753 | 59.03433 |
注:Dec列はvpuデコードfpsを意味し、Playback列は全体的な再生fpsを意味します。
いくつかの説明:
単体テストがよりフラットなのに、Gstreamerのパフォーマンスデータがまだ改善されるのはなぜですか?Gstreamerには、vpu apiをより直感的に呼び出すために使用されるvpuラッパーがあります。したがって、最初は、全体的な GST 再生パフォーマンスは vpu (vpu dec 57.8 fps) によって制約されます。そして最後に、vpuクロックが増加するとvpuデコードパフォーマンスが60fpsを超えると、制約はディスプレイのリフレッシュレート60fpsになります。
Gstreamerのビデオ表示オーバーヘッドは、単体テストと同様に約1fpsにすぎません。
テスト結果に基づくと、352MHz の場合、1080p ディスプレイでの全体的な 1080p ビデオ再生は ~60fps に達する可能性があることがわかります。
または、2つのディスプレイを備えた2つのパイプラインで時間を共有する場合、2 x 1080p @ 30fpsのビデオ再生を行うことができます。
ただし、この実験は 1080p ディスプレイでの 1080p ビデオ再生に有効です。インターレースされたクリップとディスプレイのサイズが 1080p と同じでない場合、インターレース解除やサイズ変更などの後処理によって全体的な再生パフォーマンスが制限されます。
こんにちはJunping、
mfw_isink前にキューも使用する必要がありますか?
vpu はデコードに 6 つのバッファを使用し、vl4sink はそのうちの 2 つを使用し、キューは 3 つのバッファを使用します。大きすぎる設定は使用できません。そうしないと、実行するのに十分なバッファがありません
スケールダウンしても大きな違いはないはずです、なぜならどちらもIPUを使用しているからです
ああ、わかりました。よくわかりません。ジャックマオさん、これについてコメントしていただけますか?
Leo
Hi Leo,
スケールダウンする必要がありますが、私の質問は次のとおりです。
mfw_ipucsc を使用したスケールダウンと mfw_isink を使用したスケールダウンの違いは何ですか?パフォーマンスの向上はありますか?
Hi Tarek,
mfw_ipucsc は色空間変換および解像度スケーラーであるため、これらの機能が必要ない場合はパイプラインから削除できます。一方、それを追加して前にcapsfilterを追加しない場合、(私が信じている)何もしません。
Leo
Hi Leo,
私はmfw_ipucscと同じIPUを使用していると思うmfw_isinkを使用しています。それを使用することで追加の利点があると思いますか?
とにかく試してみるので、パイプラインは次のようになります。
appsrc -> vpudec -> mfw_ipucsc -> mfw_isink.それでよろしいですか。
jackmao は、キューのバッファを減らす必要がある理由について、よりよく理解しているはずです。AFAIKでは、vpudecは少なくとも6つのバッファを実行する必要があり、vpudecのプロパティを使用して変更することはできないため、残っている唯一のパラメータはキューのバッファです。実際、私はキュー要素を調べましたが、デフォルトは200のようです!!
max-size-buffers : 最大キュー内のバッファの数 (0=無効)
フラグ:読み取り可能、書き込み可能
符号なし整数。範囲: 0 - 4294967295 デフォルト: 200 現在: 200
ところで、mfw_ipucsc要素をダウンスケーリングに使ってみたことはありますか?
Leo
Hi Leo,
1.メモリ リークは見られません。私はTop valgrindとmtraceを使用したことがあるので、疑いはありません。
2.私はそれを理解しているかどうか諦めていません!デフォルト値は 20 バッファで、VPU がバッファを使い果た しないように 、この数を 3 バッファ に減らす 必要があります。数を増やす必要があると思いますよね?
Hi Tarek,
1. フリーズの問題: パイプラインの実行中に RAM のメモリ使用量/空き容量 (top -b | grep Mem) を監視できますか?
2.キュー:「max-size-buffers」を減らす理由は、vpudecが常にパイプライン上で実行されるいくつかのバッファを必要とするためだと思います。デフォルト値が指定されている場合、vpudecはある時点でバッファを使い果たします。
Hello,
この情報を提示していただきありがとうございます。それは非常に有益です。
私は関連する問題をデバッグしており、ほとんど質問がありません。
問題を：
gstreamerを使用して、複数のネットワークストリーム(4-8-16)を1080p画面に再生しています。画面はDVIのみをサポートしているため、HDMI-DVIケーブルを使用しています。もちろん、画面に収まるように mfw_isink 要素を使用してストリームを縮小しています。すべてのストリームは目立ったエラーなしで正常に開始されますが、数時間後にはエラーメッセージを表示せずにビデオがフリーズします。
私が使用しているパイプラインは次のとおりです
vpudec ->
appsr c-> output-selector -> input-selector -> mfw_isink
jpegdec->
私の質問:
1.システムは24時間年中無休でビデオを再生し、消費電力は気にしません。常にコマンド "echo performance > /sys/devices/system/cpu/cpu0/cpufreq/"を使用する方が良いですかscaling_governor
2. なぜデコーダとシンクの間で "queue max-size-buffers=3" を使用するのですか?バッファのサイズ= 3をどのように決定しますか?
3. VPUとIPUのパフォーマンスを監視するためのツールはありますか?
4.ボトルネック、ディスプレイ、またはデコーダーのどちらがより可能性が高いですか?
ありがとうございます