10-bit、4:2:2 の動画は変換後にどうなるか：画面を再圧縮するかどうかで決まります
最も大事な一文を先に置きます。画面を再圧縮しない場合は、10-bit と HDR の情報がそのまま付いてきます。画面を再圧縮する場合は、納品の形はソースのビット深度・上限 10-bit・クロマ 4:2:0 の統一です。どちらの経路を進むかは CineX がファイルごとに判断します。判断の根拠はCineX で速い動画と時間がかかる動画がある理由に書いてあります。同じファイルで再エンコードが必要かどうかは、中の画面コーデックで決まり、拡張子では決まりません。
1. 「再エンコードしない」経路では、なぜ何も変わらないのか
HEVC 10-bit（HDR10 のたぐいを含む）や H.264 Hi10P といった画面は、デバイス側がもともと読み取れる場合、CineX は描き直すのではなくそのまま移します。ピクセルデータを 1 バイトも再生成しないので、ビット深度もクロマのサンプリングも輝度レンジもすべて元のまです。こうしたファイルはたいてい数秒で終わります。速いのは、まさに再圧縮していないからです。
画面が描き直されていない限り、「画質は落ちないか」と問い立てること自体が成り立ちません。触れられていないからです。
2. 再圧縮が必要な場合：ビット深度はソースで納品、上限は 10-bit、クロマは 4:2:0 に統一
画面を再エンコードしなければならない場合（たとえば元が VP9、AV1、Xvid などで、デバイスが直接読み取れない画面の場合）、ビット深度は能動的には下げません：元が 10-bit（または HDR のたぐいである PQ／HLG 転送特性）なら 10-bit で納品し、元が 12-bit なら 10-bit に落とし、4:2:2 と 4:4:4 のクロマサンプリングは 4:2:0 に統一しますが、ビット深度は保たれます。8-bit で納品されるのは 2 つの場合だけです。元がもともと 8-bit である場合と、ファイルからビット深度の情報を読み取れない場合です。変わるのはクロマサンプリングの層です——10-bit の階調の精度はピクセルに残りますが、4:2:2 の色サンプリングはピクセルに残りません。
なぜクロマを 4:2:0 に統一し、12-bit を 10-bit だけに落とすのか。これは私たちが自分で引いた納品ラインです。成果物は放行の証拠でカバーされた形の段階（HEVC Main 10、4:2:0）だけを通し、より広い段階には賭けません。これは取舍であり、見落としではありません。しかもこれを覆せるスイッチは一つもありません。CineX はパラメータゼロで、画質の段階も提供しません。
3. この経路では、HDR と Dolby Vision の結末が違う
ここではビット深度に直接関わる結論だけを置きます。再エンコードの経路はソースのビット深度で納品し、上限は 10-bit です。ドルビービジョンのたぐいの情報はコンテナだけ変更の経路で画面とともに運ばれるとしか言っていません。再エンコードの経路で何がまだ残るかは検証していないため、どちらの側も約束としては書きません。色の表記（伝送特性や色域のたぐい）は元の値に従い、あれば持っていき、なければ補いません。だからこそ「表記が残っている」と「効果が残っている」は別の話であり、これがドルビービジョンと HDR10 を分けて議論しなければならない理由にもなります。
4. 10-bit が遅いとは限らないが、時間を見込むべきケースが一つある
10-bit の H.264（Hi10P）も 10-bit の HEVC も、私たちが実機サンプルで通り終えた入力の範囲内にあります。時間を見込むべきは極端なケースです。高フレームレートで高解像度の画面を完全な変換にかけると、待ち時間は素材の長さに応じて素材そのものより通常もっと長くなります。こうした「待てない」ファイルについては、本当に再圧縮が必要かどうかを先に見るほうが、ツールを乗り換えるより効果的なことがほとんどです。
遅くなる原因はいつでも「10-bit」という数字ではなく、画面をもう一度描き直す必要があるかどうかです。描き直さないほうはビット深度がソースどおりに保たれます。描き直すほうは、ソースのビット深度に従い上限 10-bit の 4:2:0 の画面を交付します——時間をかける価値があるのは後者のほうです。
5. 事前に知っておくべき境界
- この記事が話すのは三つの経路それぞれの規則です。10-bit と HDR は「再エンコードしない」ほうの挙動に実機のサンプルがあります。12-bit と 4:2:2 にもそれぞれ実機の読み値が一本あります（12-bit は 10-bit に落ち、4:2:2 の色度は 4:2:0 に落ちますがビット深度は保たれます）。この一本の iOS での項目ごとの確かめはまだ固まっていません ⇒ 10-bit はここでは交付の形としてのみ語り、売り文句にはしません。必須条件として数える方は、ご自身のファイルで一度お試しください。
- 再圧縮が画面を変えることを否定しませんし、「元のまま保つ」選択肢も用意していません。
- ビット深度と色は変換がつまずいた合図ではありません。成果物はいつもどおり再生でき、色度サンプリングが 4:2:0 に統一されるのはこの経路の規則で、壊れたという意味ではありません。
- 完全な変換では十分な空き容量も必要です（ディスク使用のピークは元のファイルの 2 倍まで、コンテナだけを変えるなら成果物 1 本分あれば足ります）、その理由は動画の変換になぜ追加の空きを確保するのかに書いています。
よくある質問
10-bit の HEVC 映画は 8-bit に下げられてしまいますか？
いいえ。デバイスがその画面を直接読み取れる場合、CineX はコンテナだけを入れ替え、ピクセルには触らないので、10-bit はそのまま保たれます。再エンコードが必要になるときもビット深度は下げません——10-bit のソースは 10-bit で納品されます。元がもともと 8-bit であるか、ファイルからビット深度の情報を読み取れないかのどちらかの場合のみ、出力は 8-bit になります。
変換後に HDR の表記が残っているのに、画面が灰色っぽく見えるのはなぜですか？
灰色っぽく見える問題は、たいてい成果物が壊れているのではなく、表示する側が HDR のたぐいの明るさ情報をどう扱うかにあります。再エンコードの経路はクロマを 4:2:0 に統一して納品し、色の表記は元の値に従って持ち込まれます。「表記が残っている」ことは「効果が残っている」ことと同じではありません。元のファイルを残して、それに対応する経路で見ることが正しい対処です。
10-bit を保ったまま出力する方法はありますか？
追加の設定は不要ですし、設定することもできません。再エンコードではビット深度はもともとソースに応じて納品され、10-bit のソースは 10-bit で納品されます。8-bit のソースは、残したいと思っても 10-bit にはなりません。CineX はパラメータゼロで、画質の段階、ビット深度の選択、目標サイズはいずれも提供しません。
10-bit の変換は必ず遅いですか？
必ずしもそうとは限りません。遅くなるのは「再圧縮が必須」で、かつフレームレートと解像度の両方が高いたぐいだけです。多くの 10-bit ファイルは再エンコードしない経路を通り、数秒で終わります。
Axiom One LLC — CineX