🕌

アップスケール, エンコード, Vision Pro再生可能スペック

に公開
Vision Pro
tech

対象素材

  • ミュージックビデオ
    • Display P3 / PQ Transfer / Rec709 Matrix
    • Color Range: Full (顧客申請)

問題整理

  • 先方から提示されたイマーシブビデオが期待するクオリティに達していない (ローカルで書き出している700mbpsの方が綺麗ですし、最低限求めている画質もこちらになります。)
  • 比較対象はDavinchから書き出した700Mbpsの4320aivuファイル
  • Ampliumでは先方から受け取ったProRes4320をtopaz/irisで7200にアップスケール
  • SBSに変換した後、x265でHEVC圧縮
    • CRF23で120Mbpsだった
  • 先方からもらった素材はノイズリダクションはかけていない
  • 先方の意見としては以下の点が気になるとのこと
    • ピンクや顔の周りにブロックノイズ、モアレを感じる
    • 一部のシーンで右目と左目の視差があっていないように感じる

先方の主張と自分の意見のすり合わせ

  • ローカルで書き出している700mbpsの方が綺麗ですし、最低限求めている画質もこちらになります

    • 半分Agree半分Disagree
    • 視差ズレ、色味の再現、（フレーム落ち）の面では4320aivuに優位性がある
      • 4320aivuはシネマ感と「白っぽさ」を感じる
    • 解像度、立体感、リアリティの面では今の状態でもAmpliumに優位性がある
      • また、Ampliumではフルレンジの色味で「白っぽさ」を解消できる可能性がある
    • 4320aivuが好きな人は2D(昔の表現)が好きな人
    • Ampliumが好きな人は3Dの立体感が好きな人

  • ピンク色の衣装の周りにブロックノイズ、モアレを感じる

    • Agree
    • たしかにx265の圧縮ではピンクの周りにブロックノイズを感じる
    • ただしノイズリダクションをかけてCRF値を上げたらそもそも改善する可能性がある
      • 実験ではその効果を感じた
    • また、ピンクは最もノイズが出やすい被写体の１つなので、x265のパラメータも調整してみた方が良いかもしれない
    • ただ正直、解像度・ノイズ・立体感が綺麗なら微小のピンクノイズはあまり気にならない

  • 一部のシーンで右目と左目の視差があっていないように感じる

    • Agree
    • たしかに4320aivuと比べて、視差ズレが少し強いような気がする
    • もしかしたら、もらったaimeファイルの中に複数のLensDefinitionが入っているかもしれない
    • これは別途確認する

  • その他

    • 700Mbpsの4320aivuをAmpliumで再生できるか？
      • 別途確認する
      • ただし今の所、4320aivuよりAmplium工程で綺麗にできる自信があるので、保留する
    • Apple Vision ProのボリュームをMaxにしても音量が小さく感じられる
      • これはAmpliumというより、AVPlayerの仕様
      • 元音声のマスターボリュームを上げて対応したい

ビデオレンジ

まず気になったのは先方からもらったビデオのカラーレンジ。
これはエンコード工程には直接関係しないかもしれないが、見え方には大きく影響する。

以下のTopazアップスケールのコマンドで"-color_range" "<pc or tv>"のパラメータをpc/tvそれぞれで指定してアップスケールした。

  TVAI_MODEL_DIR="/Applications/Topaz Video.app/Contents/Resources/models" \
  TVAI_MODEL_DATA_DIR="/Applications/Topaz Video.app/Contents/Resources/models" \
  "/Applications/Topaz Video.app/Contents/MacOS/ffmpeg" \
    "-y" "-hide_banner" \
    "-i" "/Volumes/Expansion 1/AI-Agent/<creator_name>/<video_title>/original/<left_or_right>.mov" \
    "-sws_flags" "spline+accurate_rnd+full_chroma_int" \
    "-filter_complex" "tvai_up=model=iris-2:scale=0:w=7200:h=7200:preblur=0:noise=0:details=0:halo=0:blur=0:compression=0:estimate=8:blend=0.2:device=0:vram=1:instances=1,scale=w=7200:h=7200:flags=lanczos:threads=0" \
    "-c:v" "prores_ks" \
    "-profile:v" "5" \
    "-color_range" "<pc or tv>" \
    "-pix_fmt" "yuv444p10le" \
    "-map" "0:a?" \
    "-map_metadata:s:a:0" "0:s:a:0" \
    "-c:a" "copy" \
    "-map_metadata" "0" \
    "-map_metadata:s:v" "0:s:v" \
    "-fps_mode:v" "passthrough" \
    "-movflags" "frag_keyframe+empty_moov+delay_moov+use_metadata_tags+write_colr" \
    "-bf" "0" \
    "-metadata" "videoai=Enhanced using iris-2; Changed resolution to 7200x7200" \
    "/Volumes/Expansion 1/AI-Agent/<creator_name>/<video_title>/40ppd/<left_or_right>.mov"

その結果、tvでアップスケールした場合は元素材と同じ色味になり、fullでアップスケールした場合は元素材とは違う深みのある色になった。ということは元素材がVideoレンジである可能性が高い。

そもそも先方からもらったaivuとProResが「白っぽい」のが気になっていた。フルレンジではその「白っぽさ」は解消された。

先方はProResをFullレンジで書き出したと言っていたので、もしかしたら制作もしくは撮影工程でVideoレンジになっているのかもしれない。

「白っぽくなる」が発生する仕組み

映像が白っぽく（コントラストが低く）見えるのは、主に 「PC レンジ（0-255）の素材を、TV レンジ（16-235）だと勘違いして処理・表示したとき」 に発生します。

本来の黒（0） が、TV レンジの基準である 「少し明るい黒（16）」 に持ち上げられてしまう。

本来の白（255） が、TV レンジの基準である 「少し暗い白（235）」 に押し下げられてしまう。

この「レンジの縮小」が起きると、全体的に色が薄く、眠たい画質（Washout）になります。

考えらるDavinchでの混入工程

個人的には1 or 2が怪しく見えるが、これはプロジェクトファイルごと貰わないとこちらでは検証できない。

1. Deliver ページ（書き出し設定）の 「Data Levels」

最も多い原因がここです。書き出し時の設定が不適切だと、最後にレンジが変換されてしまいます。
チェック箇所: 「Deliver」タブ ＞ 「Video」 ＞ 「Advanced Settings」 ＞ ​Data Levels​
起きていること: ここが ​「Video」​ に設定されていると、DaVinci は「この映像は 16-235 に収めるべきものだ」と判断し、本来 0 だった黒を 16 に、255 だった白を 235 に押し込めます。その結果、白っぽくなります。
対策: 基本は ​「Auto」​ で良いですが、ProRes 4444 XQ などの場合は ​「Full」​ に固定して書き出すことで、レンジの縮小を防げます。

2. Clip Attributes（素材の読み込み設定）

素材を読み込んだ時点で DaVinci が「この素材は Video レンジだ」と誤認しているケースです。
チェック箇所: メディアプールで素材を右クリック ＞ ​Clip Attributes...（属性）​ ＞ 「Levels」
起きていること: 元素材が PC レンジ（Full）なのに、ここが ​「Video」​ になっていると、DaVinci は「16 を黒として扱う」ため、編集画面上ですでに色が浮いて見えます。そのまま書き出すと、当然出力ファイルも白っぽくなります。
対策: 元素材の性質に合わせて ​「Full」​ に手動で切り替えてみてください。

3. macOS 特有の「Gamma Shift」（QuickTime プレイヤーの問題）

これは設定ミスではなく、書き出した後の ​「見た目」​ の問題です。ProRes を Mac の QuickTime Player や Finder のプレビューで見ると白っぽく見える現象です。
原因: DaVinci 内の書き出しタグ（NCLC タグ）と、macOS の ColorSync の解釈の違い（Rec.709 2.4 vs 1.96）によって発生します。
確認方法: 書き出したファイルを DaVinci 自身に再読み込みして、タイムライン上の元の色と比較してください。

DaVinci 内で一致する場合: ファイル自体は正常です。プレイヤー側の表示の問題です。
DaVinci 内でも白っぽい場合: 上記 1 または 2 の設定ミスです。

ノイズリダクション

今回の動画がAmpliumに上がっている他の動画と決定的に違うのは、Neat Videoによるノイズリダクションをかけていないこと。

なぜこれが問題になる可能性があるかというと、CRF値の値 = 圧縮効率にダイレクトに直結するから。CRF値は下げるほど、HEVCアウトプットは綺麗になる。

  • x265の圧縮効率が上がる仕組み
1. 空間的冗長性の向上（Intra Prediction）

x265 は、1 つのフレーム内の似たような領域を探して圧縮します。
ノイズが多い場合: 隣り合うピクセルがバラバラな数値を持つため、高周波成分として扱われます。これを忠実に再現しようとすると、大量のビットを消費します。
ノイズが少ない場合: 平坦な領域（空や壁など）が真に平坦になるため、より大きな ​CU（Coding Unit）​ で一気に符号化でき、ビットを節約できます。

2. 時間的冗長性の向上（Inter Prediction）

これが最も大きな理由です。x265 は前後のフレームとの「差分」を記録しますが、ノイズは「ランダムに動く点」です。
ノイズが多い場合: エンコーダーが「これは動体（モーションベクトル）だ」と誤認して追いかけようとしますが、ランダムなのでうまく一致しません。結果として、「予測しきれなかった差分（Residual）」が膨大になり、ファイルサイズが跳ね上がります。
ノイズが少ない場合: モーション推定が正確に働き、背景などの静止している部分はほぼゼロに近いビットで記述できるようになります。

イマーシブビデオでは基本的に被写体を「単純化」するほど、圧縮効率が上がり、綺麗になる。
今のところ、AI処理の影響でのっぺり感を感じたことはない。
多くの視聴者にとっては、イマーシブビデオは綺麗に見えるほど良い。

また、AmpliumではTopazアップスケール＆高解像度投影により、AIVUよりも立体感を感じるようになっているので、没入感(3D感)はより感じやすいようになっている。

比較映像整理

  • Davinch書き出し 4320aivu
    • 700Mbps
    • 上記で言及している映像
  • Amplium 7200
    • 100 - 200Mbps
    • 上記で言及している映像
  • Compressor書き出し 4320aivu
    • 100Mbps
    • 映像は一番汚く見えた
    • やはりハードウェアエンコードは高ビットレートを必要とすると思われる

対応方針

問題整理の章でまとめた通り、まずは「映像をフルレンジとして扱う」「ノイズリダクションを効かせた状態でアップスケールする」という対応・実験をした方が良い。

基本的には「フルレンジ」「ノイズリダクション」「アップスケール」「低CRFでHEVC圧縮」を組み合わせたら、大体のイマーシブビデオは綺麗に見えるはず。

MV-HEVC高ビットレート

先方が700Mbpsで渡してきたように、VisionOS26は高ビットレートの10bit MV-HEVCをデコードする性能が上がっている可能性がある。ビットレートが影響するのは基本的にデコード工程。ただしレンダリングのGPU発熱で間接的にレンダリング工程が影響する可能性はある。（デコードとレンダリングのユニットは別）

たしかに、MV-HEVCのデコードはSBSと比べて1/10ぐらいのデコードスピードになった気がする。ただし、発熱のせいでフレーム落ちが出た気もする。実際にLiVSの動画ではビットレートを意図的に下げた記憶がある。

700MbpsをAVPlayerで再生した結果

結論、再生できた。もしかしたら、MV-HEVCなら700Mbpsなどの高ビットレートでも問題なくデコードできるのかもしれない。

もし、ソフトウェアエンコードでMV-HEVCにして、かつ高ビットレートでデコードできたら、かなり綺麗な素材を投影できることになる。（ハードウェアエンコードなら今の段階でもMV-HEVC化できる）

Discussion