マスターからゲームアセットへ：エンコード、解像度、ビットレート、ファイル命名

マスターはゲームアセットではない。正式なパイプラインでは高品質のアーカイブ用マスターを保持し、対象プラットフォームに合わせてエンコードを統一した納品版を生成する。各ファイルはアセットID、バージョン、技術パラメーター、チェックサムとともにマニフェストへ登録する。プログラムから「最終版_本当に最終2.mp4」を直接参照させてはいけない。

アーカイブ用マスターは最高品質の映像と音声を保存し、将来の再エンコードの元になる。編集用中間ファイルはポストプロダクションに、ランタイムファイルは特定のプラットフォームに、プロキシファイルは映像レビューとリモートでの共同作業に使う。この4種類は用途が異なるため、低ビットレートのレビュー用ファイルを元に配布パッケージを作ってはいけない。

マスターの解像度、フレームレート、色空間、ビット深度、音声トラック、ラウドネスの基準を記録する。特定のプラットフォームが焼き込み字幕を必要としない限り、字幕はできるだけ独立したファイルやデータとして保持する。すべての変換結果は、承認済みマスターから自動的に、または再現可能な方法で生成する。

解像度は高ければよいわけではない。視聴距離、映像の細部、機器のデコード能力、ストレージとダウンロードの目標を考慮して選ぶ。ビットレートは動き、ノイズ、暗部、エンコーダーに左右される。同じ平均ビットレートでも、動きの少ない会話と雨の夜の追跡では結果が異なる。

暗い場面、速い動き、細い髪の毛、グラデーション、字幕、切り替え直後の最初のフレームを含む代表的なクリップを用意する。各エンコード段階でブラインドテストを行い、画質、最初のフレームが表示されるまでの時間、フレーム落ち、温度、メモリ使用量、ファイルサイズを記録する。最終プリセットは、ネット上の万能な数値ではなく、証拠に基づいて決める。

分岐クリップでは、コンテナ、コーデック、解像度、フレームレート、色設定、音声形式をできるだけ揃え、開始位置の近くに適切なキーフレームを配置する。パラメーターが変わると、プレーヤーがパイプラインを再構築する必要が生じ、黒画面や急な音量変化につながることがある。エンコードのたびに、再生時間、冒頭と末尾の黒フレーム、無音、キーフレーム、映像と音声の同期を自動チェックする。

可変フレームレートの素材はプレーヤーによってタイムコードの問題が起きやすいため、正式なパイプラインでは通常、まずプロジェクトで合意したフレームレートに統一する。具体的な選択は、すべての対象プラットフォームで検証する必要がある。

アセットID、用途、言語またはプラットフォーム、バージョンで構成することを推奨する。例は VID_C03_S02_N010_MAIN_zhCN_PC_v007.mp4。スペース、曖昧な略称、作成者の名前、「final」は使わない。日付と承認状態はアセットマニフェストやバージョン管理システムに記録し、ファイル名が際限なく長くなるのを防ぐ。

バージョン番号は増やし、公開済みのファイルは上書きしない。ノードは論理アセットIDを参照し、ビルドマニフェストがそれをプラットフォーム用ファイルに解決する。これにより、エンコードを変更しても物語データを変更せずに済む。

マニフェストにはアセットID、元のマスター、出力パス、バージョン、再生時間、解像度、コーデック、ビットレート、音声トラック、字幕、チェックサム、ノード参照、承認者、状態を記録する。ビルド前にファイルの存在とチェックサムの一致を検証し、参照のないファイルと重複IDを自動報告する。

映像レビューで承認されたのは特定のチェックサムを持つファイルであり、フォルダー内の「同名ファイル」ではない。どのような差し替えでも新しいバージョンを作成し、参照パスの回帰チェックを実施する。

サンプリングレート、チャンネル構成、ラウドネス方針を統一し、台詞、ピーク、切り替え境界をチェックする。マルチチャンネルからステレオへのダウンミックスは対象機器でテストし、台詞の打ち消しを防ぐ。各言語の字幕について、時間基準、文字セット、スタイル、セーフエリアを記録する。

多言語の吹き替えがある場合は、独立した音声トラックか独立したファイルを選べるが、パッケージサイズとダウンロード方針を評価する必要がある。どちらの方式でも、言語変更によって再生時間が変わり、論理ノードが選択肢の提示地点を逃してはいけない。

固定の設定で一括トランスコードし、レポートを出力する。編集担当者が1つずつ手動で書き出すことによるばらつきを防ぐためだ。自動ゲートでは命名、パラメーター、チェックサム、黒フレーム、トラックの欠落を確認し、人によるゲートでは圧縮アーティファクト、色、字幕、音声、物語の連続性を確認する。

アーカイブ用マスター、プロジェクトファイル、フォント、字幕の元データもバックアップし、ランタイムアセットをゼロから再構築できることを検証する。最終的な圧縮ファイルだけをバックアップすると、将来の修正に必要な元データを失う。

動画ファイルは非常に大きい。小さな編集変更でファイル全体が変わると、パッチのためにプレイヤーが数GBを再ダウンロードする必要が生じることがある。章や安定したクリップ単位でパッケージを分割し、字幕を1か所修正しただけで全メディアの更新が必要になるのを防ぐ。ただし、細かく分割しすぎるとファイルリクエストと管理の負担も増える。実際のプラットフォームの差分更新の仕組みで一度リハーサルを行い、初回インストール容量、パッチ容量、ディスク使用量のピークを記録する。

公開前に空のキャッシュから全体をダウンロードして検証し、さらに前の正式版からアップグレードする。どちらの経路でも同じアセットマニフェストになる必要がある。オプションの高画質パックと吹き替えパックでは、インストール、アンインストール、言語切り替えをテストし、古いファイルが容量を占有し続けたり、誤って参照されたりしないようにする。

アセットは技術チェック、映像・音声レビュー、物語チェックを経て初めて承認済みと記録できる。新しいバージョンが対象機器で問題を起こした場合、マニフェストから前の承認済みバージョンを再び参照できるようにする。ロールバックのためにノードデータを変更する必要があってはいけない。手動による一時的な差し替えは、すべてビルド後のチェックサムレポートで検出されるようにする。

次のステップ：エンコードが最も難しい代表素材を5本選び、2〜3段階の候補を生成して、最低スペックの対象機器で画質と性能をブラインドテストする。プリセットを確定したら、マニフェストとチェックサムを使って作品全体を一括生成する。