コーデックの名前を信じた日、撮影素材が8-bitになっていた
現場で起きたこと
カラーグレーディング担当から連絡が入った。「この素材、暗部が全部潰れています。補正できません」。
10-bitのカメラで丁寧にLog収録した。問題はなかったはずだ。インジェスト時のコーデック選択を確認した瞬間、全部わかった。Avid DNxHR HQを選んでいた。
「HQ」＝「High Quality」。品質に問題がないはずだ、と思ったのだろう。しかし実態は違う。DNxHR HQはAvid公式仕様で8-bit固定のフォーマットだ。10-bitカメラが持っていた4,096段階の階調情報は、インジェストの瞬間に1,024段階（8-bit）へ圧縮されていた。削られた3,072段階分の色情報は、二度と戻らない。撮り直しのきかない本番素材だった。
なぜ起きるのか
このミスの根は3つある。
コーデック名と仕様の乖離を知らない。 「HQ」「SQ」という名前が品質の高さを保証すると思い込む。ところがDNxHR HQもSQも、仕様書に明記された8-bit固定フォーマットだ。
変換タイミングを設計していない。 映像制作のポストプロダクションには、フォーマット変換が必要な瞬間が3回ある。①素材を取り込む「インジェスト」、②仕上げ処理を行う「フィニッシング」、③納品ファイルを作る「デリバリー」。この3段階それぞれで何をどのコーデックに変換するかを事前設計していないと、後になって取り返しのつかないミスが出る。
品質とデータ量のバランスを計算していない。 Apple ProRes 422 HQ（220 Mbps）とProRes Proxy（45 Mbps）のデータ量差は4.9倍だ（出典：Apple Support 公式仕様書 https://support.apple.com/en-us/102207）。コーデックを1種類間違えるだけで、ストレージ消費量と編集レスポンスが根本から変わる。
すこし立ち止まって考えてほしいこと
映像データのストレージ管理は、台所の食材管理に似ている。毎日使う食材はカウンターに出しておく（ホットSSD）。数日に一度使うものは棚の奥（ウォームNAS）に。長期保存のものは冷凍庫（コールドLTO・クラウド）へ。
問題が起きるのは「全部カウンターに並べておかないと不安」という判断だ。すぐ使わないRAW素材まで高速SSDに置き続けると、2週間で空きがなくなる。コーデックの選択とストレージ階層の設計は、同じ構造の問題だ。どこに何を置くかを決めない限り、いつかパンクする。
設計さえ整えれば、防げる
フォーマット変換のタイミングを3つのフェーズに分けて設計し、各段階で正しいコーデックを選び、スマートレンダリングを活用すれば、品質を落とさずにストレージ使用量を最小化できる。
手法は確立されている。問題は、その判断基準を知っているかどうかだ。
有料部分で手に入るもの
- インジェスト・フィニッシング・デリバリー3段階のコーデック選択フロー（ProRes/DNxHR対応表付き）
- DNxHR HQ・SQの8-bit制約と、10-bitを正確に保持するHQXへの切り替え判断基準
- H.264プロキシ運用で踏みやすい4つの落とし穴と具体的な回避策
- Adobe Premiere ProとDaVinci Resolveでのスマートレンダリング構築手順（ステップバイステップ）
- ホット・ウォーム・コールドストレージへの素材割り当て設計表とクリーンアップフロー
- LTOテープとクラウドアーカイブの選択判断基準
コメント