コーデックは難しいものではありません。 いや、本当に、そうなのです。 重要なのは、正しいコーデックを選択することです。
この記事の終わりには、各プロジェクトで自分に最適なコーデックを選択できるようになっていることでしょう。 私の目標は、あなた自身がコーデックについて十分な情報を得た上で意思決定するために必要なものを提供することです。 そのため、他の誰かがうまくいったことに頼るのではなく、自分にとって正しいコーデックを選択することができます。
これから、ビデオ制作のプロセスのすべてのステップを説明します。 見出しをクリックすると、そのセクションにジャンプします。 カバーするのは
- 撮影するコーデック
- 編集するコーデック
- 色補正するコーデック
- VFXに送るコーデック
- エクスポートするコーデック
- 保存するコーデック
それぞれの段階において、以下のことを取り上げます。 どのような点を考慮してコーデックを選べばよいかを説明します。 また、その段階で最もよく使用されるコーデックの例をいくつか紹介します。
途中で、ローエンドコーデックとハイエンドコーデックがそれぞれ編集を遅くする理由、プロキシ/オフライン編集の理由、実際のプロジェクトのウォークスルー、ストレージ節約の戦略、トランスコーディングで画質を改善できない理由の説明などを説明します。 正しいコーデックを選択すれば、画像を最高品質で保存することができます。 また、作業を高速化し、コンピュータとストレージを最大限に活用することができます。 ハイエンドのタワー型パソコンで行うよりも、ラップトップで行う方がより速く作業ができます。 そして、その方法についてはかなりスマートです。 数年前、私は、多くのコーデックが使用する主な圧縮技術をカバーするビデオを作成しました。 この記事を理解するのに必須ではありませんが、見ておいて損はありません。
How Codecs Work – Tutorial.
ビデオをスキップする場合、以下は非常に基本的な説明です：
- Chroma subsampling: 一部の色データを捨てる（4:4:4はクロマサンプリングなし。 4:2:2はクロマサンプリングあり。4:2:0はクロマサンプリングが多い）。 4:2:0はクロマサブサンプリングが多い）色調補正をする場合には不利です。 4509>
- Macro-Blocking (マクロ・ブロッキング)：グリーン・スクリーンやVFX作業を行う場合は、本当に悪いことです。 同系色のブロック（大きさは様々）を見つけ、それらをすべて同じ色にします。 VFXや色調補正には不向きです。 ほとんどのコーデックはこれをある程度使用しており、その量はビットレートによって異なる傾向があります。 現在のフレームを計算するために、前のフレーム (および場合によっては次のフレーム) を使用します。 編集には不向き。
- ビット深度。 可能な色の数。 ビット深度が深い（数字が大きい）ほど、色補正やVFXに適しています。
Codec Comparison Table
ポストプロダクションの世界で最もよく使用されるコーデックのリストも作成しました。 このリストは、異なるコーデックを互いに比較し、プロジェクトに最適な判断を下すのに役立ちます。
編集プロセスで使用できるさまざまなコーデックがあります。 私が紹介したものは、圧倒的に一般的なものです。 一般的なコーデックを使用することには、大きな利点があります。 あなたのシステム、クライアントのシステム、5年後のあなたのシステムなどで動作する可能性が高くなります。 また、何か問題が発生したときに、ヘルプを見つけるのも簡単です。
新しいタブで表を開く。 そうすれば、記事を読みながらコーデックを比較できます。
表をチェックする
Lossyness
表の列の1つは「ロッシーネス」で、これはコーデックで重要な概念です。 ロッシーネスについて話すとき、私は必ずしも目で見たものを意味しているわけではありません。 コーデックによって保持されるデータ量のことで、目に見えるのはその一部だけです。 問題は、非圧縮の画像があったとして、それをこのコーデックで圧縮した場合、新しい画像は古い画像とどの程度似ているのか、ということです。 トランスコードで失われる情報はどの程度でしょうか？ もし2つの画像が非常に似ていれば、そのコーデックはあまりロスがないことになります。 9686>
非可逆性は、特定のコーデックが使用する手法とそのビットレートの組み合わせです。 より非可逆的なコーデックは必ずしも悪いわけではありません。 場合によっては (たとえば、オンラインで表示する場合)、元の画像を 100% 保持する必要は本当にないのです。 より非可逆なコーデックを使用することで、どれだけ容量を節約できるかを考えると、本当に賢い選択と言えます。
自分の目には画像が同じように見えるのに、なぜ技術的に「非可逆」であるかどうかを気にしなければならないのですか。 もし、何らかの色補正をするのであれば、画像を変更することになります。 その結果、キャプチャしたときには見えなかった (または目立っていた) 画像の要素が見えるようになるかもしれません。
たとえば、次の画像は生でキャプチャしたものです。
そしてDNxHD 350xで圧縮：
どれもほとんど同じに見えますね。 視覚的な品質はほぼ同じで、H.264 ファイルは DNxHD ファイルの何分の一かのサイズです。 そのため、YouTubeでは推奨設定となっています。 しかし、H.264バージョンで困るのは、画像に変更を加えるときです。 露出を上げたい場合はどうすればよいでしょうか。
さて、高圧縮画像がどこで破綻しているのかがわかります。 彼女の髪とシャツは h.264 画像ではひどく、川沿いの建物はすべてつぶれて見えます。
このため、画像を取り込む際には、高品質のコーデックが必要なのです。 なぜなら、おそらく後で変更を加えたいと思うでしょうが、その変更がどのようなものであるかはまだわからないからです。 色やコントラストを調整したり、速度を調整したり、VFXを追加したりしたいはずです。 高圧縮されたファイルでは、分解せずに変更することはできません。
これが、最終的に 8 ビット ファイルを出力するとしても、映像を 10 ビットでキャプチャすることが良いアイデアである理由です。
コーデックの旅
では、いよいよ各プロジェクトで遭遇するさまざまな段階を説明しましょう。 そして、エクスポート（配信コーデック）してクライアントに渡したり、Web にアップロードしたりするコーデックで終了します。 最もシンプルなケースでは、編集と色調補正をすべてカメラのファイル上で行います。 その後、配信コーデックにエクスポートするので、2 つのコーデックを使用するだけです。
しかし、ほとんどの場合、もう少し複雑になります。 編集用に別のコーデックにトランスコードしたり、色調補正用にトランスコードしたり、VFX 用にトランスコードしたりすることがあります。 しかし、すべては…
撮影するコーデック
（目次へ戻る）
これはキャプチャコーデック（「カメラ ネイティブ コーデック」または「取り込みコーデック」としても知られています）
一般的には、カメラ（あるいは予算）で取り込める最高品質のコーデックを目標とする必要があります。 私が「最高品質」と言った場合、できるだけ多くの情報をキャプチャしたいという意味です。 つまり、より少ない圧縮、より高いビット深度、より少ないクロマサブサンプリングなど、よりロスの少ないコーデックが望ましいのです。 キャプチャ時の情報量が多ければ多いほど、後々の柔軟性が高まります。 特に、色調補正と VFX (それを行う場合) においてです。
もちろん、この決定では、他の多くの実用的な要因も考慮する必要があります。 さもなければ、常に 8K raw を撮影することになるでしょう。
Cost
最初に考慮すべきは、明らかにコストです。 一般的に、高価なカメラほど、より高品質のコーデックを使用できます。 一般的にと言ったのは、リーズナブルな価格で優れたコーデックを提供できる「スイートスポット」カメラがいくつか存在するからです。 Panasonic の GH シリーズ (特に GH2 がハッキングされた初期の頃) は、その価格帯の他のカメラよりも優れたコーデックを提供することで知られていました。
Tip: 外部レコーダーでより良いコーデックを実現
安いカメラでより高品質のコーデックをキャプチャする方法の 1 つは外部レコーダーを使用することです。 したがって、最終的に映像の 2 つのコピーが作成されます。 1つはカメラで大きく圧縮されたコピー、もう1つは外部レコーダーで軽く圧縮されたコピーです。 ここで重要なのは、カメラが圧縮する前にレコーダーに信号を送ることです。
ここで1つの重要な注意点は、多くの安価なカメラは8ビットしか出力せず、多くの場合4：4：4では出力しないことです。 外部レコーダーは12ビットコーデックに圧縮することができるかもしれません。 しかし、カメラが8ビットしか送らないのであれば、レコーダーは8ビットしか記録できないのです。 また、安価なカメラでは、録画に適した「きれいな」HDMI信号が出力されない場合もあります。
ストレージ
考慮すべき 2 つ目の要因は、ストレージ容量です。 高品質なコーデックはビットレートが高くなる傾向があり、ファイルが大きくなります。 撮影中にそれらのファイルをすべて保存し、バックアップするための準備が必要です。 また、高ビットレートのデータを記録するために、メモリーカードのアップグレードが必要になる場合もあります。 9686>
仕上げ
もう 1 つの考慮すべき要因は、色調補正と VFX（総称して仕上げと呼ぶ）をどの程度行う予定なのかということです。 色調補正やVFX をほとんど行わないのであれば、低品質のキャプチャー コーデックに付随する低いビット深度、クロマ サブサンプリング、およびマクロ ブロックを使用せずに済むかもしれません。 ほとんどのキャプチャ コーデックは、高性能なコンピュータがないと編集に適していません。 H.264 および一部の Raw ファイルは、スムーズに編集するために強力な CPU/GPU を必要とします。 また、非常に高いビットレートのコーデックは、高速のハードディスクやデータサーバーを必要とする場合があります。 編集に適したコーデックで撮影していない限り、編集前にファイルを他のコーデックにトランスコードする必要がある場合もあります。 そして、これには時間がかかることがあります。 映像のトランスコードは、夜間や予備のコンピュータで行えるので、大きな問題ではない人もいるでしょう。 しかし、納期が非常に厳しい場合は、たとえコストが高くても、画質を犠牲にしても、撮影後すぐに編集を開始できるコーデックを選択することができます。 次のセクションで、編集に最適なコーデックについて説明します。
編集するコーデック
（目次に戻る）
さて、映画を撮影し、すべてのファイルをコンピューターに取り込んだとします。 ここで、これらのファイルを編集するかどうかを決定する必要があります。 または、別の形式にトランスコードするかどうか。
なぜ編集前にトランスコードする必要があるのでしょうか。 カメラから出力されたファイルを編集するだけではだめなのでしょうか。 ほとんどすべての主要なソフトウェア パッケージは、カメラが作成するあらゆるコーデックを編集できます。 (あなたが最新技術を搭載した真新しいカメラで撮影するようなヘタレでない限り)。 しかし、カメラが撮影したコーデックを編集することはほとんど可能ですが、それが最善の方法とは限りません。
幸運にも編集に最適なコーデックで撮影している場合は、この手順を省略できます。 編集用コーデックを選択する際に考慮すべき主な要因は、圧縮タイプとビット レートの 2 つです。
高圧縮コーデックは編集を遅くする
（目次へ移動）
ほとんどの下位～中位のカメラは、長時間 GOP 圧縮としても知られる時間圧縮を使用するコーデックで記録します。 ここで簡単な説明をしますが、より詳しく知りたい方は、19:00 から始まる私のコーデック ビデオをご覧ください。
ロング GOP を簡単に説明すると、各フレームについて、コーデックはこのフレームと前のフレーム間で変化したものだけをキャプチャするということです。 ビデオに多くの動きが含まれていない場合、新しいファイルは非常に小さくなります。 このフレームと最後のフレームとの差は、ほんの数ピクセルです。 つまり、保存する必要があるのは数ピクセルだけなのです。 素晴らしい！
常に順方向
しかしながら、問題は、これらのコーデックは順方向に再生したときにのみうまく機能する傾向があるということです。 (その理由が気になる方は、ビデオを見てみてください)。 これは、YouTube や DVD プレーヤーで見るには素晴らしいことですが、編集には向いていません。 編集しているときは、ジャンプしたり、クリップを逆再生したりすることがよくあります。 ロングGOPコーデックでこうしたことを素早く行うには、より多くの処理能力が必要です。 ハイエンドのコンピューターは問題ないかもしれませんが、ミドルレンジのコンピューターでも、映像をすばやく読み飛ばしたり、あちこちに飛んだりすると、ラグが生じ、動作が遅くなります。
ロング GOP でないコーデック（別名イントラフレームコーデック）は、順方向の再生と同じくらい簡単に逆方向の再生ができます。 そのため、ミドルレンジのコンピュータでも非常にスムーズにスキップできます。 カメラからのクリップを直接編集したことがあるだけなら、何を見逃しているのか気付かないかもしれません！
再生に問題を引き起こす可能性があるもうひとつのものは、生のビデオです。 生のビデオは、表示する前に変換する必要があります (コーデックのようなものです)。 そして、一部のコンピューターは、特に 4K の場合、Raw ファイルを十分に速くデコードすることができません。 皮肉なことに、ローエンドのカメラもハイエンドのカメラも、編集しにくいファイルを生成します！
ハイビットレートコーデックは編集を遅くする
（目次へ移動）
ロー～ミドルレンジのコーデックは、ビットレートについてまったく心配する必要がありません。 しかし、上位に進み始めると、高ビットレートのコーデックは、特に日常的なコンピュータで作業している場合、編集に問題を引き起こすことがあります。
その理由は、コンピュータが、少なくともコーデックのビットレートと同程度のビットレートでハードディスクからデータを読み取ることができる必要があるためです。 それは理にかなっています – コーデックが 50Mb/s (50 メガビット/秒) である場合、コンピュータはハード ドライブからそのファイルを 50Mb/s で読み取ることができる必要があり、さもなければ、遅れをとってしまい動作が不安定になります。 1 バイトには 8 ビットがあるので、MB/秒から Mb/s に変換するときは 8 倍する必要があります）
いくつかの良いニュース
良いニュースは、ハード ドライブが日々速くなっていることです。 したがって、50Mb/s は決して問題を引き起こさないでしょう。 しかし、ProRes 422HQ を 734Mb/s の 4K で編集している場合はどうでしょうか。 平均的な外付けハードドライブは、これを再生するのに十分な速度がぎりぎりです。 安価なハードドライブでは、まったく対応できないものもあります。 さらに、3台のカメラでマルチカムを編集する場合はどうでしょう？ 突然、その3倍のデータレート、2,202Mb/sが必要になるのです! この時点で、高性能のハード ドライブや RAID に投資する必要があります。
一般的なデータ ストレージ速度の大まかなガイドラインを以下に示します。 (常に、性能の劣る、または性能の高い特定のモデルが存在します。)
- 標準的な回転式ドライブ。 100-120MB/s
- プロフェッショナル・スピニング・ドライブ。 150-200MB/s
- 標準的なSSD。 400-500 MB/s
- ローエンド RAID: 200-300 MB/s
- ハイエンド RAID: 1000-2000 MB/s
ログで撮影すると編集速度が落ちる
ログでの撮影はダイナミックレンジをできるだけ多く保持するための方法です。 これにより、明るいハイライトと暗いシャドーのあるシーンで、ハイライトを吹き飛ばしたり、黒をつぶしたりすることなく、撮影することができます。 特に、フィルムではなくビデオで撮影した場合の副作用として、ハイライトの白飛びがあります。 そのため、ログで撮影することで、より映画的な映像に仕上げることができます。 ほとんどのプロシューマー用カメラでもログ プロファイルが利用できるようになったので、非常に人気のある方法です。
欠点
欠点は、カメラから出力されるイメージがあまりよく見えないことです。 最終的な画像に近づけるために、コントラストと彩度を追加する必要があります。 そのための最も一般的な方法は、映像にLUTを追加することです。 これは、基本的に、映像を「通常」の外観に戻す簡単なプリセット カラー コレクションです。
ログ カラー スペースを使用して撮影した場合、通常のカラーとコントラストでプレビューするために、映像に LUT を適用する必要があります。 これは、編集者が編集時に、すべてのクリップに適切な LUT を適用する必要があることを意味します。 これは管理が煩わしく、またコンピュータの速度が少し遅くなることもあります。 これは、まず各フレームをデコードし、表示する前にLUTを適用する必要があるためです。 確かにログ映像をLUTなしで編集することは可能ですが、理想的ではありません。 2 つのショットのカラーは、それらをどのようにインターカットするかに影響するかもしれません。
ファイルを編集する前にトランスコードするのであれば、トランスコード プロセス中に LUT を適用することが可能です。 そうすれば、編集者は常に良好なコントラストとカラーを持つ映像を扱うことになり、LUT に煩わされることはありません。 Direct Intermediate ワークフロー（後述）ではなく、Proxy ワークフローを使用している場合にのみ、これを行うべきであることに注意してください。
エンコードにかかる時間を考慮する
編集前に映像をトランスコードすることの最大のマイナス面は、トランスコードにかかる時間だけです。 処理する映像が多く、コンピュータが高速でない場合、長い時間がかかることがあります。 それほど急いでいないのであれば、トランスコードを一晩中実行することもできますし、複数のコンピューターにアクセスできるのであれば、その可能性もありますが、それは必ずしも理想的ではありません。 その人たちは、しばしば非常にタイトなスケジュールで動いていました。 私は通常、4K でロング GOP ログ フォーマットで撮影し、MacBook Pro で編集していました。 ラップトップで LUT（ログ映像を補正する）を使用して 4K のロング GOP を編集すると、Premiere Pro でビデオをうまく再生できますが、スタッターなしでタイムラインを好きなだけ速くズームすることはできません。 いくつかのカットと、音楽と、タイトルだけで、私は終わりました。 私の編集スピードが理想的でなかったとしても、編集スピードの節約よりもトランスコードに多くの時間を費やしていたでしょうから、元のファイルを使用しました。 一般に、私はトランスコーディングのほとんどを夜間に行い、多くの場合、複数のマシンを同時に実行します。
Proxy Edit
（目次へ移動）
編集前にネイティブ カメラ ファイルをトランスコードする場合、「中間」コーデックを使用することになります。 キャプチャ コーデックとエクスポート コーデックの間に位置するため、中間コーデックと呼ばれます。 中間コーデックを使用する一般的な方法は 2 つあります。
1 つ目は、「プロキシ」ワークフローまたは「オフライン編集」です。 これは、キャプチャした映像を中間フォーマットにトランスコードし、そのフォーマットで編集し、エクスポートする前に元のカメラ ファイルに再リンクすることを意味します。 エクスポートにはプロキシファイルではなくカメラファイルを使用するため、画質の高いプロキシコーデックを選択することにそれほど気を使う必要はありません（ロッシーコーデックでも問題ありません）。 代わりに編集速度とストレージの利便性を最適化できます。
プロキシ ワークフローは非常に一般的で、多くのハイエンド カメラはハイエンドの Raw ファイルと ProRes または DNxHD プロキシ ファイルを同時に記録しています。 撮影後、RAW ファイルはバックアップされ、ストレージに保存されます。 プロキシ ファイルは、編集者や、デイリーのためにディレクター/プロデューサーに送られます。
時間圧縮を避ける
プロキシ コーデックを選択する場合、時間圧縮（別名フレーム間圧縮またはロング GOP 圧縮）を使用しないものを選び、より低いビットレートのものを選びたいものです。 ビットレートが低いということは、ファイルが非常に小さくなるということで、より少ない、より小さい、より安いハードディスクを使用することができ、ワークフローを簡素化することができるのです。 Woot！
プロキシファイルは編集に最適ですが、プロキシファイルで基本的な色調補正以上のことはしないほうがよいでしょう。 編集ソフトウェア内ですべての色補正を行う場合は、プロキシ ファイルの色の品質が低い可能性があるため、カメラ ファイルに再リンクするのが最善です。
良いことに、今日のほとんどの編集ソフトウェアは、カメラ ファイルとプロキシ ファイルをわずか数クリックで切り替えられるので、必要であれば、前後に移動することも可能です。
私たちは、主要な NLE のそれぞれで、プロキシ ワークフローに関する詳細なガイドを公開しています。
- Final Cut Pro X Proxy ワークフロー
- Premiere Pro Proxy ワークフロー
- Avid Media Composer Proxy ワークフロー
Some good choices for proxy codecs
Proxy コーデックで最も一般的なのは DNxHD/DNxHR と ProRes です。 これらはどちらも何年も前から存在しているため、非常に広くサポートされています。 誰もがその扱い方を知っています。 どちらもプロキシ ワークフローに非常に適しており (ProRes には「プロキシ」というプリセットがあるほどです)、プロキシに使用する場合はほぼ互換性があります。
DNxHD は Avid によって、ProRes は Apple によって製造されています。 そのため、DNxHD は Media Composer で、ProRes は Final Cut Pro X でよりよく機能することは理にかなっています。以前は確かにそうでしたが、現在では、両方のコーデックはすべての最新エディター (Premiere Pro を含む) で非常にスムーズに機能します。 システム用に設計されたコーデックを使用することで、若干の速度向上があるかもしれませんが、それはごくわずかです。
プロキシ ワークフローにおける 2 つの大きな違いは、PC で ProRes を作成するのが難しいかもしれないという事実だけですが、DNxHD はクロス プラットフォームで非常に簡単に作成することが可能です。 PCでProResを作成する方法として公式にサポートされているのは、Assimilate Scratchのみです。 その他にもPCでProResファイルを作成するためのサポートされていない方法がいくつかありますが、必ずしも信頼できるものではありません。 PC では ProRes ファイルの再生と編集は簡単にできますが、PC 上で新しい ProRes ファイルを DNxHD ほど簡単にエンコードできないため、その理由から DNxHD ワークフローを好むエディターもいます。
Pick a lane
どちらのコーデックを選ぶかにかかわらず、どちらのフレーバーを選ぶかも必要です。 これは、実際にストレージの制約に依存することになります。 良い点としては、編集時には最高の画質は必要ないので、低ビットレートコーデックを選択することができます。 GB/hrの欄を見て、持っている映像の時間数を掛けてみてください。 十分なストレージ容量があれば、そのコーデックを使用すればよいでしょう。 しかし、十分なストレージ容量がない場合、または性能の低いマシンを使用している場合は、解像度を 1 つ下げます。 多くの巨大予算のハリウッド映画は、ほんの数年前までは 480p で編集されていたので、編集のために 4K から 720P に解像度を下げる必要があっても、気にしないでください。 これは、カメラ ファイルを、編集に適しており、非常に高品質な (非可逆性の) コーデックにトランスコードすることを意味します。 このコーデックは非常に高品質なので、カメラファイルのオリジナル情報はほぼすべて保存されており、カメラファイルへの再リンクは必要ありません – 中間ファイルから直接エクスポートすればいいだけなのです。 トランスコード時に理論的な情報の損失がありますが、十分な中間コーデックを選択すれば、それを気にする必要はありません。
（注：このプロセスを「ダイレクト中間」と呼んでいるのは、このワークフローに一般的な名前がないからです。 通常、人々はこれを「中間」と呼びますが、プロキシワークフローも中間ワークフローの一種であるため、混乱することがあります。 また、これを「オンライン」ワークフローと呼ぶ人もいますが、この用語はオフラインとオンライン編集を含むワークフローを表すために作られたものであり、最初から最後までオンラインであるワークフローではないので、これも紛らわしいです。 中間コーデックは画像を良くすることはありませんが (詳細は後述)、間違ったコーデックを選択した場合は、確実に画像を悪化させることがあります。 重要なのは、元の映像の詳細を理解し、中間コーデックが各領域でキャプチャコーデックと同等以上であることを確認することです。 Sony A7SiiのようなDSLRで4Kで映像をキャプチャする場合、4:2:0、8ビット、Long-GOPコーデックで100Mbpsで記録することになります。 少なくとも4:2:0、8ビットの中間コーデックが必要です。 この値を超えても（例えば4:4:4や12ビット）問題はありませんが、全く役に立たないわけでもありません。 したがって、余分なストレージ容量を使用する価値はないでしょう。
たとえば、ProRes コーデックを使用するとします。 4:2:2 および 10 ビットから選択できる 4 つのオプションがあります。
- 145Mb/s ProRes 422 Proxy
- 328Mb/s ProRes 422 LT
- 471Mb/s ProRes 422
- 707Mb/s ProRes 422 HQ
Over and above
カメラのビットレート（100Mbps）に合わせるだけでいいと思われるかもしれません。 が、実際にはカメラのビットレートを大きく上回る必要があります。 これは、h.264がProResよりもはるかに効率的なコーデックだからです。 h.264はLong-GOP圧縮を使用しているため、ProResよりも多くの情報を100メガビットに詰め込むことができます。 ProResがh.264の画質に匹敵するためには、より高いビットレートが必要です。 100Mbpsのh.264コーデックから始める場合は、ProRes 422またはProRes 422 HQのみを使用することをお勧めします。 ProRes 422 でもおそらく十分ですが、ストレージ容量が大きい場合は、ProRes 422 HQ を使用する方が若干有利です。
中間ファイルを選択する際に、ビット深度とカラーサンプリングを単純に一致させても問題ありませんが、常にビットレートを少なくとも少し増加させるべきでしょう。 長い GOP から長い GOP でないコーデックに移行する場合は、ビットレートを大幅に上げるべきです。
補足: ProRes の代わりに DNxHD を使用したい場合、DNxHD がローエンド コーデックのための 8 ビット バージョンも提供することを除いて、同じようなオプションがあります。 私たちの映像はもともと 8 ビットなので、まったく支障はありません。
プロキシ ワークフローはかなり良さそうでしたね。 Direct Intermediate を使用する理由
Direct Intermediate ワークフローが一般的である理由の 1 つは、以前はプロキシ ワークフローを使用することが非常に困難であったからです。 主要なソフトウェア プロバイダーの中には、オリジナルのカメラ ファイルに再リンクすることを特に容易にしていないものもあり、そのため人々はダイレクト インターミディエイト ワークフローを選択することになります。 しかし現在では、どの編集パッケージでもかなり簡単に行えるようになりました。 ただし、映像の種類がたくさん混在している場合は例外です。 同じプロジェクトに複数のフレーム レートとフレーム サイズがある場合、プロキシとキャプチャ コーデックの間で切り替えを行うと、頭痛の種になります。
カットする前に、映像を準備し整理するためにサードパーティ製ツールを使用している場合、それらも再リンク プロセスをより厄介にすることがあります。 よくある例としては、オーディオ トラックを自動的に同期するソフトウェアやマルチカム撮影などがあります。
スワップ不要
ダイレクト中間ファイルを使用したいもうひとつの理由は、ファイルをスワップせずにカラー コレクションと VFX（「仕上げ」）プロセスにすぐに移行できるためです。 その便利な理由については、色補正と VFX のセクションで詳しく説明します。
ただし、1 つの欠点は、エディター用に LUT を「焼き込む」ことができないことです。 Direct Intermediate ワークフロー用にトランスコードする際に LUT を含めると、そもそもログに記録することの利点をすべて失うことになります。
他の明白な欠点は、これらの（はるかに大きな）ファイルをすべて保存する必要があることです。
中間コーデックで画像がよくなることはありません
（目次へ移動）
これは非常に重要で、非常によく誤解されており、オンラインには多くの誤った情報があるからです。 編集前に映像をトランスコードしても、出力の品質が向上することは決してありません。 トランスコード プロセスで行うことができる余分な操作 (高度なアップレゾ ツールの使用など) によって画質が向上する場合もありますが、新しいコーデック自体では決して画質は向上しません。
正しいコーデックを選択すれば、画像を傷つけずに済むことはあっても、向上することはあり得ません。 また、8 ビットから 10 ビットへの移行も含まれます。 また、4:2:0 から 4:4:4 への移行も含まれます。
この概念を理解するのに役立つ図解があります。 4 メガピクセルで、私の 27 インチ モニターではかなりきれいに見えます。
さて、Red Helium 8k カメラで私のモニターの写真を撮ったらどうでしょう。 これは野獣のようなカメラです。 私は数年前、バラの写真を、現在 250 ドル程度のチープな Canon Rebel DSLR で撮影しました。 Red Helium のセットアップは約 5 万ドルで、35 メガピクセル、Raw、これまでに製造された最高のカメラ センサーの 1 つです。
4 メガピクセルの写真と 35 メガピクセルの写真、どちらが良い画像になるでしょうか。
A capture of a capture
レッド カメラにはメガピクセルがもっとありますよね？ rawだし、Redのデジタルマジックが全部入ってるんでしょ？ でも、高解像度カメラを使って、バラの写真ではなく、写真の写真を撮っているので、私の派手な新しいイメージは、決して最初のものよりも良くはないでしょう。 技術的には高解像度のファイルがありますが、最初のファイルよりも被写体 (バラ) を捉えていないのです。 あなたは、コピーのコピーを作成し、写真の写真を撮っているのです。 写真の写真を撮るために高級な高解像度カメラを使用した場合、元の画像のほとんどすべての情報を保持することができますが、それ以上何も追加できません。
大きな注意点は、画像に何らかの処理、変換（たとえば、LUT の追加）を行う場合、新しい情報を保持する、より高品質のコーデックにトランスコードしたいことは間違いないでしょう。 しかし、画像に変更を加えていない場合は、トランスコードによって画像が何らかの形で「良く」なることはありません。
実例
（インデックスに戻る）
例えば、4K 映像を Sony A7sii カメラで撮影し、XAVC-Sのロング GOP バージョンで記録したドキュメンタリーを編集するとします。 編集には理想的ではありません。 長編ドキュメンタリーのために 40 時間の映像を撮影した場合、約 2.7TB のカメラ ファイルになり、1 つのハード ドライブに簡単に収まります（もちろん、他の個別のバックアップを作成していますが！）。
これを Direct Intermediate ワークフロー用の高品質であまり損失のないコーデック、おそらく 4K の ProRes 422 HQ に変換することができます。 1 つのプロジェクトですべての映像に簡単にアクセスするには、高価な RAID セットアップを使用する必要があり、少なくとも 1,000 ドルは必要です。 大規模な施設では大したことはありませんが、一人のエディターにとっては大きな投資です。
プロキシの選択
そこで、代わりにプロキシ ワークフローを使用し、ファイルを ProRes 422 Proxy 4K 形式にトランスコードすることに決めたとします。 そうすれば、キャプチャした映像よりわずかに多い 2.8TB しか使用できません。 そうすれば、1台のハードディスクで簡単に編集できるようになり、ワークフローもぐっとシンプルになります。 (ビットレートとファイルサイズの計算方法については、こちらの記事をご覧ください。
たとえば、国の反対側にいる別のエディターと共同作業しているとします。 この場合、映像をさらに ProRes 422 Proxy HD にトランスコードすると、映像はわずか 640GB に縮小され、高速接続があれば、インターネット経由で送信することがより現実的なものになります。 (80Mbps の接続でダウンロードに 18 時間）
編集がすべて完了したら、プロジェクトを元のカメラ ファイルに再リンクしてエクスポートするだけです。 あなたとリモート エディターがかなりロッシーなコーデックで作業していたとしても、最終的なエクスポートではそれをバイパスするので、品質が落ちることはありません。
色補正するコーデック
（インデックスに戻る）
さて、ビデオを編集したら、次は色補正をしましょう。 ここで説明することは、編集アプリケーションの中で色補正を行う場合でも、専用の色補正ソフトウェアに送信する場合でも同じです。
この時点での大きな問題は、元のカメラのファイルでそのまま色補正を行うか、トランスコードするかということです。 プロキシ/オフライン編集を行った場合、プロキシファイルは画質が低いので、絶対に色調補正をしたくありません。 色について適切な判断を下すには、利用可能な最高品質の画像が必要です。なぜなら、作業するものを正確に確認できる必要があるからです。 カメラ ファイルをグレードアップする
これは確かに単純なオプションです。 プロキシ編集を行った場合、仕上げ処理用のカメラ ファイルに再リンクして、街に繰り出すことができます。 これで最大限の画質が得られますが、カメラファイルの動作が遅くなることを思い出してください。 カメラファイルを使用すると、処理速度が多少低下しますが、使用するソフトウェアと必要な作業量によっては、このシンプルさが、潜在的な処理速度の低下を少し上回る価値があると判断できるかもしれません。 あまり複雑な作業を伴わない短い編集であれば、これは簡単で素晴らしいワークフローになります。
色補正の速度低下が気になるので、より簡単に作業できるコーデックが必要だと仮定しましょう。 すべての映像を高画質コーデックにトランスコードし、それらのファイルにリンクしてから、色調補正を開始することができます。 でも、それではプロキシワークフローの意味がありませんよね？ 私たちがプロキシを使ったのは、プロキシによって生成される大きなファイルを処理するのが嫌だったからです。 幸いなことに、別のオプションがあります。 統合してトランスコードする
（インデックスに戻る）
編集にプロキシ/オフライン ワークフローを使用したが、カメラ ファイルの色補正をしたくない場合は、カメラ ファイルに再リンクしてプロジェクトを統合し、ハイエンド コーデックでトランスコードすることも良い選択肢の 1 つです。
プロジェクトを統合すると、編集ソフトウェアはメディアのコピーと一緒にプロジェクトのコピーを作成しますが、最終的にシーケンスで使用した特定のファイルのみが作成されます。 つまり、7 つのテイクを撮影したが、編集ではそのうちの 1 つしか使用しなかった場合、その 1 つのテイクだけがコピーされます。 これによってストレージが大幅に削減されるので、この段階で重宝します。 さらに、各テイクのうち実際に編集で使用した特定の部分のみを残し、残りを破棄するような統合も可能です。 この場合、ソフトウェアは通常、フェードやモーション トラッキングを追加する場合に備えて、各テイクの前後に数秒間（「ハンドル」と呼ばれる）を含めます。
グレードの開始
次に、この新しい統合プロジェクト（オリジナルに再リンク後）を受け取り、これらすべてのファイルを非常に高品質で高ビットレートのコーデックでトランスコードして、カラー コレクションを開始することができます。 これはダイレクト・インターミディエイトのワークフローとは異なります。なぜなら、すべての映像をトランスコードするのではなく、最終編集に入る映像だけをトランスコードするので、もともと撮影した映像の20分の1や50分の1の長さになるかもしれないからです。 高ビットレートコーデックにトランスコードするのは、それほど多くの映像を保存する必要がないため、それほど悪いことではないと思われます。 ProRes 4444 4K でも、長編映画は 2TB ほどになり、かなり管理しやすくなります。
ポケットに入るサイズのハードディスクで、最高品質の画像と高速な処理で映画を完成させることができます。 Woot！
C. Direct Intermediate を継続する
3番目のオプションは、Direct Intermediate 編集ワークフローを継続することで、この場合、問題ありません。 編集を始める前に、すでにすべてのファイルを高品質のコーデックにトランスコードしているので、色調補正のために同じファイルをそのまま引き継げばよいのです。 また、それらのファイルは編集にも色調補正や VFX（後述）にも適しているので便利です。
外部のカラーリストや VFX 担当者にプロジェクトを引き渡す場合、高品質の映像をすべて渡すか（サイズの関係で迷惑になる可能性があります）、上で使用したのと同じ統合チップを使用するかのいずれかです。 統合されたプロジェクトを渡すことで、より速く作業を進めることができ、カラリストの時間も節約できます。
もう 1 つの利点
Direct Intermediate ワークフローの単純さ（1 つのファイル セットのみを使用）に加えて、もう 1 つの利点があります。
プロキシ編集を終了し、統合してトランスコードし、カラリストに送った後、編集にいくつか変更を加える必要があると判断したとします。 今度はプロキシに戻って編集を行い、再度コンソリデーションして映像を送り直さなければなりません。 このような仕組みは、かなり面倒なことになります。 ハイエンドのポストプロダクションワークフローでは、通常、編集に「ロック」がかかり、仕上げ工程に入ることができます。 つまり、（よほどのことがない限り）編集に立ち戻って変更を加えることは、極力避けなければならないのです。
そして今、Direct Intermediate編集のもうひとつの良い理由が見つかりました。 カラー作業と編集作業を同時に行う場合、または少なくとも何度か行き来する場合は、両方に 1 つのコーデックを使用する方がシンプルになります。 これは、編集と仕上げを同じソフトウェア パッケージ (または Creative Cloud などのパッケージ群) で行う場合に特に便利です。
VFX に送信するコーデック
(back to the index)
VFX 作業を行っている場合、おそらくファイルを別のプログラム（別のアーティストが使う別のマシン）に送信しなければならないことが予想されます。 VFX 作業をすべてエディタで行っている場合 (簡単な作業であれば、ますます実行可能になってきています)、このセクションをスキップすることができます。 しかし、ほとんどの場合、エディタから VFX ソフトウェアにクリップを送信し、終了したらまた戻ってくるという「ラウンドトリップ」プロセスを設定する必要があります。 これはショットごとに行われるので、カラーグレーディングのようにシーケンス全体をVFXに送るわけではありません。 プロセスのいつショットをVFXに送るかという問題は、特定のワークフローに大きく依存します。
編集がロックされ、カラーコレクションが終了した後にVFXに送る人もいますが、時間の圧力により、それ以前にショットの送信を開始しなければならない場合もあります。 Dynamic Link は自動的にラウンドトリッピングを行います。 VFXを多用する場合は、このセクションのテクニックを使用することをお勧めします。なぜなら、Dynamic Linkは多すぎるプロジェクトでは少々気難しくなることがあるからです。 しかし、Adobe は常にそのようなバグに対処しているので、個人の好みにもよります。
Go big or go home
VFX プロセスでは、主に 2 つの理由から、非常にハイエンドな（高ビットレートの）コーデックを使用する傾向にあります。 1 つ目は、VFX アーティストが仕事をうまくこなすために、提供できるすべての情報を必要とするからです。 VFXアーティストは、コーデックに関して最もうるさい人たちの一人ですが、それには十分な理由があります。 誰もが高品質の画像を望んでいますが、画像の問題は、編集、色調補正、および最終エクスポートよりも、VFX にとってより大きな問題となることがよくあります。 たとえば、グリーンスクリーンの抽出を行う場合、キャラクターとグリーンスクリーンの間のエッジをできる限りきれいにしたいものです。 キャラクタのエッジがすべて途切れていたり、ぼやけていたりするひどいグリーンスクリーンショットを見たことがあるでしょう。 このような問題は、肉眼では見えない画像圧縮アーチファクトが原因で発生することがよくあります。 例えば、4:2:2や4:2:0のカラーサブサンプリングは、画像にほとんど影響を与えません。 人間の目は主にコントラストを気にするので、色の解像度が低いことに気づくことはほとんどありませんが、グリーンスクリーンの抽出プロセスは主に色の値を頼りにしています。 コーデックが 4:2:0 クロマサブサンプリングを使用してカラー値の大部分を捨てている場合、良いカラーキーは不可能かもしれません。
世代損失
ハイエンドコーデックを使用したい理由の 2 つ目は、世代損失があるためです。 VFX のプロセスでは、おそらくファイルを複数回圧縮する必要があります。 ファイルを送信するときに一度だけ圧縮します。 そして、複数のスペシャリスト間でファイルを受け渡す必要がある場合、そのファイルを2回、3回と圧縮してから送り返すことがあります。 ファイルが何度も圧縮されることを、私たちは多重世代損失と呼んでいます。
ローエンドのコーデックを使用している場合、再圧縮するたびに画像は徐々に悪くなっていきます。 本当に高品質のコーデックの素晴らしい点の 1 つは、品質をあまり落とさずに 2、3 回圧縮できることです。 ビデオを何度も圧縮することは常に避けるべきですが、非常に高品質のコーデックを使用している場合、通常はかなり問題ないでしょう。 良いことに、VFX ショットは通常クリップあたり数秒しかないため、ハイエンドのコーデックを使用してもファイル サイズは小さくなります。 だから、大きくしてください カメラで4:4:4をキャプチャしたのであれば、VFXに4:4:4を送るのは間違いないでしょう。 そうでなければ、私は最高級の 4:2:2 コーデック（ProRes 422 HQ または DNxHQX）を選びます。
そしてもちろん、どのコーデックを送信するかについて、常に VFX と事前にコミュニケーションを取る必要があります。 もし彼らが間違った選択をしていると思ったら、この記事🙂
エクスポートするコーデック
（目次へ移動）
これで編集、カラー、VFXが終わり、エクスポートする準備ができていることになります。 通常、色補正に使用したソフトウェアから、色補正に使用したコーデックを使用して最終的なエクスポートを行います。
クライアントがメディアビジネスを行っている場合、どのコーデックが必要かは分かっているはずですので、このセクションの残りは読み飛ばしていただいて構いません!
クライアントがビデオの専門家でない場合、何を望んでいるのか分からないことがあるので、クライアントに代わって何らかの決定を下す必要があります。 ほとんどの場合、クライアントは YouTube や他のソーシャル メディア サイトにアップロードするためのビデオを希望しています。 インターネットでのストリーミングに適したコーデックを選びたくなるかもしれません。 しかし、それは間違いです！
その理由は、これらのサイトは、あなたが視聴者にアップロードしたのと同じファイルをストリーミングするのではなく、ストリーミングする前にファイルを *再度* 圧縮し、彼らが使用する設定をまったく制御できないからです。 つまり、低品質のコーデックをアップロードすると、先ほど話した低品質の写真を撮っているようなシナリオになるのです。 バッド! 避けましょう！
最高品質を目指す
一般論として、最高品質の結果を望むなら、最高品質のソースをアップロードすべきです。 どうせまた圧縮されるのだから、より多くのデータを与えても損はないでしょう？ 十分な速度の接続があれば、ProRes 422をアップロードすることができます。 推奨される h.264 の代わりに ProRes をアップロードした場合、若干（ほんの少し）良い結果が得られたという報告もあります。
クライアントにファイルを配信し、彼らが Youtube にアップロードする場合、私は彼らに ProRes を提供しないでしょう。 幸いなことに、これらのサイトは推奨アップロード仕様を公表する傾向があります（ググってみてください）。 私自身は、彼らが推奨するどのようなビットレートでも受け取り、約1.5倍から2倍の倍率にします。
クライアントも自分のウェブサイトに直接埋め込むことができるファイルを望んでいるかもしれません（可能なら、私はそれを思いとどまらせるでしょうけど）。 一般的には、非常に重く圧縮された h.264 が望まれます。 良いビットレートとは何かということに興味があるなら、私の推論は、スイートスポットのビットレートを知っている人がいるとすれば、それはYouTubeであるということです。 私は定期的に YouTube からビデオをダウンロードし、そのビットレートをチェックして、ベンチマークとして使用しています。
Going small
ビデオが公開されていない場合、ダウンロードできるように自分のクライアントに直接メールまたはリンクできる小さなファイルが必要かもしれません。 このような場合、特に長い動画の場合は、2 つ以上の別々のファイルを配信することが適切な場合があります。 YouTubeにアップロードするファイルは、メールで送るには大きすぎる。 この場合、私は通常、ファイルをダウンレゾして、非常に大きく圧縮することになります。 また、現実的に考えて、クライアントが 2 つのファイルの違いを実際に理解すると思うかどうかを判断する必要があります。
複数のファイルを配信する必要がある場合、私は通常、ファイル名で 1 つを「HD」、もう 1 つを「小」または「非 HD」と呼ぶことにしています。 彼らにコーデックの違いを説明しようとしても、来週にはその違いを忘れていることはほぼ確実ですが、HDと「not HD」の意味はおそらく覚えているでしょうね。
The Codec You Archive
(back to the index)
クライアントにファイルを納品したので、これでゆっくりくつろげますね(ほとんど)。
この業界で働くプロなら誰でも知っていますが、クライアントに完成品を納めた日がプロジェクトを扱う最後ではない場合があります。 クライアントが数週間後に戻って何かを変更したい場合もありますし、より高品質のコーデックが必要な場合もありますし、自分の作品集に追加したい場合もあります。 これらのいずれの場合も、別のマシンや別のソフトウェアに移行している可能性があり、元のプロジェクトを開いて再エクスポートするのは頭痛の種です。
それは便利です
ここで、非常に高品質のコーデックで完成したプロジェクトの素晴らしいアーカイブを持っていると便利なのです。 クライアントが非常に高品質のコーデックを納品するように要求した場合、一般に、これで準備は完了です。 そのファイルのコピーを保管しておけば、大丈夫です。 しかし、クライアントが最高品質ではないコーデックを要求してきた場合は、常にロスレス、またはロスレスに限りなく近いコーデックで自分で書き出すとよいでしょう（ただし、そのために必要な容量は考慮してください）。 私は通常、非常に高いビットレートの 4:4:4 コーデック (DNxHD/HR または ProRes) にエクスポートします。 コメントをお寄せください。
私は実際にすべてのコメントを読んでいます。 この記事は進行中で、皆さんのフィードバックに基づいて、より多くの説明や例を更新していく予定です。 個人的なフィードバックや質問がある場合は、david at frame dot io.
Frame.io Blog に書きたいですか？ Eメール：blog at frame dot io.
Many thanks to Larry Jordan, Shane Ross, and Philip Hodgetts for input on this article!