コンテンツにスキップ
Disguise User Guide

ハードウェア再生パフォーマンスキャプチャ

はじめに、および免責事項

Section titled “はじめに、および免責事項”

このドキュメントは、Disguise メディアサーバーの最大ビデオスループットを判定するために採用される方法を規定します。これらの数値を見つけるために構築された環境は、実際のプロダクションよりもラボラトリー条件に近いものであることが明らかになるでしょう。したがって、これらは実用的な最大値ではなく、理論上の最大値として考慮されるべきです。

その他のソフトウェアおよびハードウェア機能の適用による影響は、これらの一連のテストでは調査されておらず、カタログ内の特定のマシンの個別の目的（GX シリーズのジェネレーティブ機能など）も考慮されていません。

目標

Section titled “目標”

このテストの目標は、希望するフレームレートを維持しながら、単一のコーデックで何個の独立したビデオを再生できるかを発見することです。テストは各 Disguise メディアサーバーで同一であり、直接比較が可能です。コーデックによってビデオ再生パイプラインへのストレスのかかり方が異なるため、これらのテストにより各メディアサーバーの潜在的な長所と短所を判断することが可能になります。

プロジェクト要件とスコープ

Section titled “プロジェクト要件とスコープ”

ビデオ再生パイプライン自体には多くの潜在的な変数があります。テストが製品の能力を真に説明するものであり、プロセスを可能な限り再現可能に保つために、一連のルールが記録されています。これらのルールの一部は制御困難な変数を排除し、その他はマシンに十分にストレスがかかっていることを確認します。

添付のプロジェクトは、stage、timeline、feed、ハードウェアのカテゴリーに分けられるこれらのルールに従います。

Stage

Section titled “Stage”
  • テスト対象のメディアサーバーは、GUI を無効にした Actor として実行する必要があります。
  • メディアサーバーが Actor として実行できない場合、最小限の GUI 要素のみを表示し、measurements は stage view で行います。
  • Stage は可能な限り最小限に保つ必要があります。props や複雑なジオメトリはありません。
  • テストする解像度ごとに 1 つの LED スクリーンを使用し、すべてのレイヤーをそのスクリーンに直接マッピングします。

Timeline

Section titled “Timeline”
  • 1 つのコーデックを 1 つのトラックでテストします。
  • 1 つの一意のビデオファイルを 1 つのレイヤーに使用します。
  • 2 セクションごとに追加レイヤーを 1 つ追加します。
  • ビデオレイヤーは Locked モードに設定する必要があります。
  • prefetcher は、追加ビデオごとに 2 セクションを作成することで調整する必要があります。

Feed

Section titled “Feed”
  • すべてのスクリーンは Actor マシンの出力に割り当てる必要があります。Director マシンは出力が割り当てられていない Dedicated Director である必要があります。

ハードウェア

Section titled “ハードウェア”
  • Actor マシンはすべての出力で genlock されている必要があります。
  • テスト対象のメディアサーバーが VFC 対応の場合、DisplayPort または HDMI VFC カードのみを含む必要があります。
  • Actor マシンは、DisplayPort または HDMI 出力の少なくとも 1 つに物理ディスプレイを接続し、フレームドロップの発見を支援する必要があります。GUI 以外のすべての出力は、すべてが genlock できるようにエミュレートする必要があります。
  • メディアサーバーが RAID アレイを搭載している場合、出荷時と同じ構成である必要があります。たとえば、VX 4+ は RAID 10 構成で出荷されるため、それがテストに使用されます。
  • すべてのメディアサーバーは、それぞれの OS イメージの最新バージョンと、正しい信頼された GPU ドライバーを使用している必要があります。

上記の制限と並行して、独自のガイドラインを持つコーデックとビデオコンテンツの問題があります。

その他のサポートされるコーデックは、以下の理由により含まれていません。

DXV: HAP と同様、場合によってはわずかに軽いパフォーマンス影響です。バージョン 3 のサポートがないため、HAP よりも人気がありません。

HAP-Alpha: HAPQ と同一のパフォーマンス影響とデータレートで、両方とも 4 番目のチャンネルを使用しています。

Photo-JPEG: CPU 依存のコーデックは、GPU 処理のコーデックと比較すると常に不利です。Photo-JPEG の場合、Quicktime Animation と比較して品質の向上に対して再生のために行う犠牲が不釣り合いです。

各コーデックに使用されるビデオコンテンツも慎重に検討されました。真っ黒なフレームでは適切ではありませんが、アニメーションカラーノイズの全フレームでも適切ではありません。コンテンツは、現実的な範囲で重い処理負荷とデータレートを発生させるよう選択されており、これを確実にするため次のガイドラインが守られています。

  • 大きな途切れない色のブロックを持つモーショングラフィックは避けてください。これは Quicktime Animation で特に重要です。ノイズの多いグラデーションは適しており、実写コンテンツが好まれます。
  • ビデオには、フレーム全体に渡るスイープ移動や素早いカットなどの動きが多く含まれる必要があります。大きな安定した動きが好まれます。再生のスムーズさを評価しやすくなるからです。ボードスポーツなどのスポーツフッテージはこれに適しています。
  • オーディオはテストされませんが、可能な場合はすべてのビデオに埋め込みオーディオを含める必要があります。
  • すべてのクリップはそれぞれ数分の長さである必要があります。
  • コンテンツはそのコーデックの最大品質でレンダリングする必要があります（Adobe Media Encoder で spatial quality を 100 に設定するなど）。
  • コンテンツは、30fps および 60fps で、Full HD (1920 x 1080) または 4K DCI (4096 x 2160) のいずれかで、8-bit カラーでレンダリングする必要があります。DPX Sequence は例外で、8-bit と 10-bit カラーの両方のコンテンツファイルでテストします。
  • 可変ビットレートを滑らかにするために、コンテンツに 4% のカラーノイズを追加する必要があります。

ビデオパフォーマンス - 例

Bad: 大きな一色のエリアを持つモーショングラフィック。これは特に Quicktime Animation で問題があり、フレームごとに大きなデータレートの変動を引き起こす可能性があります。

ビデオパフォーマンス - Bad な例

Good: 追加のカラーノイズ。これは大きなパッチを分断し均等にしますが、ビデオのデータレートを増加させる可能性もあります。

ビデオパフォーマンス - Good な例

Best: 実写コンテンツ。この例では、海全体の動きが自然なノイズを十分に生み出す一方、波とサーファーの動きはフレームのスムーズさを追跡するのに適した被写体です。

データの取得方法

Section titled “データの取得方法”

取得されるデータは、60Hz プロジェクトでマシンがフレームをドロップしたりミスしたりし始める前に、コンテンツを再生しているビデオレイヤーの数です。60Hz が使用されるのは、利用可能な従来のリフレッシュレートの最高で、各フレームが可能な最小の時間（この場合フレームあたり 16.67ms）を表すためで、ソフトウェアにとって最も難しいレートだからです。リフレッシュレートを下げると、フレームの作業に費やせる時間が増えるため、最大パフォーマンスが向上することがありますが、リフレッシュレートを下げて得られるリターンは 1 対 1 の変換ではなく、すべてのユースケースで一貫しているとは限りません。

1 秒あたり 60 フレームのビデオの最大数を、必ずしも 1 秒あたり 30 フレームのビデオの半分とすることはできません。ビデオのデータレート以外にもより微妙なオーバーヘッドが存在し、考慮する必要があり、ハードウェア構成によってさらに影響を受ける可能性があります。

各ケースの正しいレイヤー数は、d3net 上の組み込みマシンモニターを使用して発見されます。これらは、ハードウェアパフォーマンスのすべての側面に関するメトリクスを表示し、d3net セッションがホストされている間、自動的に収集およびストリーミングされます。これらのレイヤー数を確認するために使用される特定のモニターは、FPS、GPU Profiler、Prefetcher Misses、場合によっては Prefetcher Requests です。これらのモニターと可視出力の間で、レンダリングプロセスの各ステップのパフォーマンスを検証し、ボトルネックを発見し、それを実際のビデオ出力と照合することが可能です。

パフォーマンスグラフ

Good FPS: Y 軸は、すべての 3 つのヘッドが 60fps のフレーム以内の値であることを示しています。この範囲内でのある程度のばらつきは予想され、レンダラーとメトリクス収集システムの間のタイミングのわずかな違いに起因します。

パフォーマンスグラフ

Bad FPS: head 1 と 2（緑とシアンの線）で 30fps への一貫したスパイクダウン。Head 0 は GUI で、他に何もフレームをドロップしていなければ安全に無視できます。

パフォーマンスグラフ

Good GPU Profiler: GPU profiler は、GPU が特定のフレームのタスクを実行するのにかかる時間を示します。マゼンタの線がフレームのミリ秒持続時間以下にとどまっている限り、GPU が各フレームを時間通りに処理していると想定できます。この場合、合計 16.67ms のうち 7.05ms から 8.05ms をそのフレームのタスクの実行に費やしています。

パフォーマンスグラフ

Bad GPU profiler: マゼンタの線が 16.67ms 以上にあります。これは、GPU がそのフレームの作業を完了するのにフレームの持続時間より長くかかっていることを意味し、失われた時間を補うために定期的にフレームをドロップする必要があります。

パフォーマンスグラフ

Good prefetcher requests: prefetcher は、メディアドライブからビデオデータを読み取って時間通りにデコードしてレンダラーに配信するシステムです。理想的には、reading（緑）、decoding（シアン）、decoded（紫）、delivered（黄色）は、新しいビデオごとに着実に増加する一定量のフラットラインであるべきです。Waiting（赤）と abandoned（オレンジ）は 0 であるべきですが、少量の waiting フレームは許容されます。

パフォーマンスグラフ

Bad prefetcher requests: Waiting（赤）フレーム数が他のすべてのカウンターを超え、メディアドライブから読み取るキューが成長していることを意味します。他のカウンターはその結果としてやや不規則になり、再生がぎこちなくなります。これらのケースでは、FPS はレンダラーで 60 のままであることが多く、メディアドライブのボトルネックを示しています。

パフォーマンスグラフ

Good prefetcher misses: 0 のフラットライン。グラフは prefetcher requests のより簡素化された内訳で、bad prefetcher requests の例に示すような状況でのみ報告されます。

パフォーマンスグラフ

Bad prefetcher misses: 0 より大きい値のフラットライン。これは、フレームあたり 6 ビデオフレームが期限を逃していることを意味し、結果はぎこちない出力で、レンダラーフレームレートに影響を与えずに発生する可能性があります。

これらのリモートモニターを Director マシン上で実行しながら、レイヤーが Actor マシンに積み重ねられ、そのうちの 1 つが持続的な再生中に定期的に途切れるまで続けられます。各レイヤーは同じクリップの一意のコピーを持ち、各レイヤーが同時に同じビデオフレームを配信するように Locked モードでキーフレーム化されます。これにより、クリップ内のデコードが「難しい」フレームがあれば、同時にシステムに影響を与えることが保証されます。言い換えると、ビデオレイヤーが normal モードの場合、マシンの正確な瞬間ごとのパフォーマンスは、スタックに各追加ビデオが追加されるまでの時間差に応じて変動する可能性があります。そのため、クリップ全体を再生し、その期間中モニターを観察する必要があります。

クリップの期間中、モニターからの疑わしい動作なしに Actor が管理できる最大レイヤー数が、そのマシンとソフトウェアバージョンのベンチマークとして記録されます。Actor として動作できないマシンは、代わりに mixed Director として構成され、Lock to Master モードのリモートエディターによって制御および監視されます。テスト中、それらにはタイムラインも最小化された状態で表示され、他の GUI 要素は開かれません。これにより、GPU はビデオ再生タスクに可能な限り多くの時間を費やすことができ、GUI のレンダリングに費やす時間を最小限に抑えることができます。