TSMPDecoder

ヘッダーと本文の直接出力

useCombinedByteOutput の既定値は true です。予測経路では対応コーデックが復元済みの56バイトヘッダーと本文を専用の RGBA8 readback テクスチャへ直接出力し、別の結合パスと本文の中間出力を省きます。元画像のスナップショット、ヘッダー CRC 検証、長さの完全一致と同じ画像でのフォールバックは維持されます。送信データグラムは変わらず、一定の受信率を保証する機能ではありません。

シェーダーが _TSMPHeaderTex と _TSMPHeaderPixels の両方を実装すると使用できます。未対応の既存コーデックは別の結合パスを使用します。比較用の設定は Diagnostics > Advanced Decode にあります。combinedByteOutputCount は投入回数であり、後から拒否・再処理された予測も含みます。受信フレーム数ではありません。ResetDecodeDiagnostics() でリセットします.

受信側ではTSMPDecoderを使用します。 TSMP 入力テクスチャを読み取り、デコードされたメッセージを一致するシーン オブジェクトに適用します。

デコードの問題のほとんどは、入力テクスチャに未変更の TSMP イメージが含まれていないことが原因で発生します。レシーバーコンポーネントを変更する前に、テクスチャパスを確認してください。

必要なもの

• エンコードされた TSMP フレームを含む入力テクスチャ。
• 互換性のある Luma4 ハンドラー。
• ペイロード バイト テクスチャ。
• TSMP ネットワークの動作とバインディングの一致。
• TSMPSetup は参照が割り当てられた後に適用されます。

使い方

1. 入力テクスチャを割り当てます。
2. 送信者と同じ Luma4 パスを使用します。
3. TSMPSetup を通じてペイロード バイト テクスチャを割り当てるか自動サイズ設定します。
4. 受信者オブジェクトに一致する TSMP ネットワーク コンポーネントがあることを確認します。
5. 「Apply Setup」をクリックします。
6. ログを監視するか、TSMPDebugCanvas でフレームのステータスを確認します。

フレームウィンドウ

ライブ受信では decoder の Decode セクションで Filter Frames を有効にします。Window Size は既定 256 フレームで、受信側で変更できます。送信側に同じ値を設定する必要はありません。

重複・古い番号を除外します。ただし最後に適用した番号が1ウィンドウ以上なら、番号0を再開候補として許可します。既定値では 256 -> 0 は許可、255 -> 0 は拒否します。UInt32 の正常な周回は別に扱います。ウィンドウ分のテクスチャを保存する機能ではなく、データグラムも変わりません。

セッションを識別する機能ではありません。過去の0を再開と誤認する場合や、0の欠落により再開を検出できない場合があります。録画をシークする際はフィルターを無効にできますが、過去の変数値も適用されます。正確な規則と制限を参照してください。

有効なデコードはどのようなものですか

TSMPDebugCanvas では、デコーダが動作していると次のように表示されるはずです。

• valid=yes
• header=yes
• 時間の経過とともに変化するフレームインデックス。
• データ送信時のペイロード サイズが 0 より大きい。
• 送信されるデータの種類に一致するメッセージ数。
• 定常再生時の損失が少ない。

フレームは有効だがオブジェクトが移動しない場合は、ネットワーク ID、受信補間、および受信オブジェクトがアクティブかどうかを確認します。

デコード順序

デコーダは段階的に動作します。

1. 入力テクスチャからヘッダー領域を読み取ります。
2. マジック、バージョン、ヘッダー サイズ、および CRC を検証します。
3. コーデック ID からコーデック ハンドラーを選択します。
4. ペイロード バイトをペイロード バイト テクスチャにデコードします。
5. ペイロードバイトを読み取ります。
6. 変数状態メッセージと RPC メッセージをディスパッチします。

上記は最初のフレームとフォールバック経路の順序です。既定で有効な Use Predicted Readback は、前回検証した設定で現在のヘッダーと payload をまとめて復元し、逐次 GPU readback 待ちを2回から1回へ減らします。現在のヘッダーを検証するまで変数や RPC は適用しません。設定や payload 長が変わった場合は、同じスナップショットを従来の経路で再処理します。

追加のマテリアル指定は不要です。比較時は Diagnostics > Advanced Decode で無効にできます。手動レイアウトと安全モードは逐次経路を使います。推測した GPU デコードが実行済みでも、CRC 不一致ならフレームを破棄します。処理機会を増やす最適化であり、配送や一定の受信フレームレートを保証するものではありません。

Readback の重複実行

Diagnostics > Advanced Decode の Overlap Readbacks は既定で有効です。デコーダは最大2枚の画像を保持し、先の画像の GPU 応答を待ちながら次をキャプチャします。結果はキャプチャ順に適用します。両スロットが使用中なら新しいキャプチャをスキップし、キューは増やしません。この設定を無効にすると1スロット動作と比較でき、送信側の変更は不要です。

Readback が1回の更新より長い場合に欠落を減らせますが、メモリ使用量、適用遅延、GPU/CPU 負荷が増える可能性があります。スナップショット1枚は640x360で約3.52 MiB、1920x1080で約31.64 MiBであり、2スロットではバイトバッファを除いても倍になります。入力テクスチャに届かなかったフレームは復元できません。Pending Frames は使用中のスロット数、Skipped Busy Captures は容量不足で拒否した試行数であり、固有の欠落フレーム数ではありません。

受信補間

各 TSMPNetworkBehaviour には受信モードがあります。

モード	結果
なし	受信した値を無視します。
離散	受け取った各値を直接適用します。
継続的	コンポーネントがサポートしている受信ターゲットに向かってスムーズに進みます。

コンポーネントがデータを送信する必要があるが、受信データをそのオブジェクトに適用しない場合は、None を使用します。

CRC エラー

デコーダが CRC 不一致を記録する場合、フレームはデコード前に破損しています。最初に、スケーリング、フィルタリング、圧縮、および Luma4 設定の不一致を確認してください。

典型的な原因:

• OBS の画像のサイズが変更されました。
• マテリアルまたはカメラ効果によりピクセルが変更されました。
• 受信機の入力が間違ったテクスチャです。
• ヘッダー領域がトリミングされます。
• 送信者と受信者が互換性のないテクスチャ レイアウト設定を使用しています。

一般的な修正

症状	これを試してください
header=no	完全な TSMP 画像がデコーダ入力に到達することを確認します。
valid=no CRC 警告あり	トランスポートからスケーリング/フィルタリング/カラー処理を削除します。
msg=0	エンコーダーのペイロードがゼロ以外であり、セットアップ バインディングが存在することを確認します。
RPC カウントがゼロのままになる	TSMPNetworkGameObjectToggle でテストし、フレーム損失を確認します。
値は受信されますが、適用されません	受信補間とアクティブ状態を確認します。