jetson-video-pipeline

Jetson Video Pipeline

目的

NVIDIA のサンプルコマンドを直接構築して実行し、各コンシューマーが前のステージで生成されたものとまったく同じバイト列を使用したことを証明します。このスキルが扱うのはコーデックのワークフローとエビデンスポリシーです。環境のインストールや製品サポートに関する主張は扱いません。

ターミナルゲート

ターゲット、別のスキル、またはコマンドを調べる前に、以下を適用してください。

1. PSNR／SSIM のみを求めるリクエストの場合、客観的な品質測定はこのスキルの対象外であり、別途承認されたワークフローが必要であると伝え、理由を out_of_scope として not_evaluated を返し、その後停止します。ツールの名前を挙げたり、メディアを要求したりしないでください。キャプチャ、トランスポート、AI、ディスプレイ、またはグラス・トゥ・グラス遅延のみを求めるリクエストにも同様に対応してください。コーデックと品質の両方を求めるリクエストの場合は、コーデックの部分のみを続行し、品質の部分は黙って省略せず、理由を out_of_scope として not_evaluated と報告してください。

2. その他のリクエストは、メディアゲートを適用する前にすべて分類してください。

   • アーキテクチャやルートに関する質問には planned を返します。メディアは不要です。前提条件と、実行によって検証される内容を示し、その後、ターゲットの調査、取得、認証、レシピのディスパッチ、またはワークスペースの作成を始める前に停止してください。
   • 具体的なコマンドを含むドライランには、ユーザーが指定したパスまたはプレースホルダーと、そのコマンドに必要なメタデータが必要です。メディアが実在する必要はありません。jetson-video-recipe からレシピのオプションを取得し、planned を報告してください。調査、認証、または何らかの起動は行わないでください。
   • 実行、検証、パフォーマンスには、ターゲット上の正確なメディアパスを1つ、またはユーザーが指定した HTTP(S) URL を1つ必要とします。それがない場合は input_required を返し、このスキルの許可リストにあるサンプルで表現可能なステージのみを使って、想定されるルートを簡潔に示し、その項目を1つだけ求めてください。その後、ターゲットの調査、取得、認証、レシピのディスパッチ、またはワークスペースの作成を始める前に停止してください。その他に要求された変換は、実行可能なルートを作り上げず、すべて未解決として示してください。

   カタログメディアや合成メディアは選ばないでください。決定論的なセットアップ用スモークフィクスチャは、範囲が限定された機能操作に限り使用できます。パイプラインやパフォーマンスを代表するエビデンスとしては使用できません。

実行サーフェスを選択して認証する

手順 3～4 は実行に適用されます。手順 5 は、レシピを含むドライランにも適用されます。 その他の計画では、ライブで実行可能であると主張せず、明示的なサーフェスを維持してください。委任されたサーフェス固有のドライランは、選択肢に順位を付けずに selection_required を返します。

3. 明示された native、pynvc、both を維持します。「どちらでも」、「利用可能な最適なもの」、「選んでください」、またはその他の選択委任は、both ではなく auto にマッピングします。auto の場合、実行可能なサーフェスが 0 個なら blocked、1 個なら実行し、2 個なら selection_required とします。順位付けしたり、以前の結果を参照したりしないでください。

4. 公開スキルディスパッチを通じて、jetson-video-setup から最新の読み取り専用の準備状況の結果を取得します。Python では、ユーザーが指定した正確なインタープリター、または現在の会話で指定されたインタープリターがあれば、それを渡します。それ以外の場合は、ディスパッチ前にプロファイルを選択します。デコード性能の作業には pynvc-smoke を使用できます。エンコード、セグメンテーション、advanced/decode.py、パイプライン、エンコードベンチマークの作業には full-samples が必要です。セットアップでは、そのプロファイルの標準パスを確認します。venv を検索してはいけません。full-samples の作業に対して smoke プロファイルしか準備できていない場合は、ワークスペースを作成する前に dependency_required を返し、別の full-samples venv を用意するようユーザーに案内します。smoke venv をその場でアップグレードしてはいけません。ネイティブの実行可能性には、インストール済みでパッケージによって検証された SDK が 1 つと、パッケージが所有する Samples ルートが 1 つ必要です。Python の実行可能性には、指定された正確なインタープリター、その環境から読み込まれるインポート可能な PyNvVideoCodec ディストリビューション、および問題のない pip check が必要です。結果は、要求された Jetson と GPU に一致していなければなりません。候補が実行不可の場合は、セットアップの理由を維持します。要求されたパイプラインには、独自の操作証明が必要です。

5. レシピを含むエンコードおよびトランスコードの作業には jetson-video-recipe が必要です。パフォーマンス段階を含む受け入れ要求には、jetson-video-benchmark も必要です。いずれも公開スキルディスパッチを通じて呼び出し、その結果をデータとして渡します。必要な関連スキルが存在しない場合は、完了済みの段階を維持して、次のように伝えます。<stage> は実行できますが、インストールされていない <skill> が必要です。<skill> をインストールして、この段階を再試行してください。`

   「維持」とは、ユーザー向けの部分結果で、完了済みの各段階のステータスと、現在のパス／サイズ／SHA-256 の識別情報を保持することを意味します。非表示の再開可能な状態を作成することではありません。同じ要求内で再試行する場合は、これらのアーティファクトを再度開いてハッシュを計算し、変更のない complete 段階のみをスキップします。識別情報が変更または欠落している場合、あるいは後続の要求で以前の証拠が提示されない場合は、新しいワークスペースを使用してその段階を再実行します。

実行

1. 最小のルートを選択します：encode_decode、native_transcode、 pynvc_segments、container_triage、av1_verify、または acceptance。
2. ステージの順序、コンテンツの取り扱い、再試行ポリシー、レポートについては、pipeline-workflow.md を読みます。 サンプルの許可リスト、直接引数、マーカーの文法、フレームレイアウトの確認について説明している official-sample-contract.md を一度最後まで読みます。 ファイルシステムの境界については、buffer-sharing-and-synchronization.md を一度最後まで読みます。 カスタムのプロセス内 CUVID/CUDA/NVENC グラフを使用する場合は、 in-process-codec-boundaries.md も一度最後まで読みます。
3. 実行する場合は、対象メディアを正規化し、その来歴と識別情報を記録したうえで、新しいモード 0700 のワークスペースを使用し、出力を新規に作成します。ドライランの場合は、提供された識別情報とメタデータのみを使用し、前提を明記して、メディアを開いたりランチャーを認証したりせずに、予定しているコマンドと受け渡しを示します。
4. 実行する場合は、選択したネイティブサンプルまたはホイールの各メンバーを認証し、文字どおりの引数リストを直接起動して、編集していないログを保持します。リファレンスで指定された終了コード、マーカー、件数、エラー、新しさ、レイアウトの各確認を必須とします。
5. 各プロデューサー出力を、独立したコンシューマーで処理する前と後に再度開き、ハッシュを再計算します。成功したブランチは保持し、失敗したピアは partial と報告し、リファレンスの単一再試行ルールを適用します。
6. すべてのプラン、結果、プロデューサー／コンシューマーの境界で、該当する io_contract を直接出力します。コントラクトモジュールに依存したり、デバイスメモリーモードから外部共有を推測したりしないでください。

ルートの要件

ルート	必須の証明
encode_decode	検証済みのレシピを 1 つ使用すること。直接の AppEncCuda→AppDec、またはホイールが所有する basic encode→advanced decode を使用すること。raw バイト数とデコード後のバイト数が正確であること。
native_transcode	H.264 入力、正確な HEVC ネイティブ投影、AppTrans 出力、受け入れ可能なトランスコードマーカーがちょうど 1 つであること。その後、同じハッシュに対して AppDec を実行すること。AppTrans と AppDec のフレーム数が等しく、正の値であり、既知の入力フレーム数がある場合はそれとも一致すること。
pynvc_segments	ホイールが所有するスケジュール／設定を使用すること。宣言されたすべてのセグメントが新規かつ空でないこと。すべてのセグメントを個別にデコードしてハッシュを再計算すること。
container_triage	対象となる Jetson、正確なローカル／取得済みコンテナー、AppDec 内の libavformat による固有のデマルチプレックス、またはホイールが所有する advanced decode、新規のデコード出力を使用すること。
av1_verify	正確な AV1 ネイティブレシピを使用すること。ホストモードとビデオメモリーモードを使用すること。AppDec が各 IVF 出力をそのまま読み込み、期待されるフレーム数を報告すること。
acceptance	要求された準備状況、機能、レシピ、コーデック、ベンチマークの各ステージを対象に、ステージごとのステータスと識別情報を含む、簡潔で再現可能なレポートを作成すること。

レポート

pipeline-workflow.md で定義されているステータスと簡潔なレポートを使用します。選択したランタイム、メディアとレシピの正確な識別情報、文字どおりのコマンド、プロデューサーとコンシューマーの結果、デコード後のレイアウト／サイズの検証、ログ、制限事項、再試行の理由を含めます。必要な場合や要求された場合は、簡潔な JSON またはチェックサムマニフェストを追加します。

制限事項

• コーデックの作業によって、キャプチャー、転送、推論、表示、品質、エンドツーエンドのレイテンシーが証明されるわけではありません。
• API のフィールドやインベントリは、操作の証明でも製品サポートの証明でもありません。
• コンテナーのデマルチプレックスは、認証済みのリリース済み NVIDIA サンプル内でのみ許可されます。
• リファレンスに記載されたすべての決定的な受け入れ確認を適用します。
• コーデック／API の機能やベンチマーク結果によって、バッファーの相互運用性、ゼロコピー、同期の互換性が証明されるわけではありません。