DaVinci Resolveの書き出し画質。MacとWindowsどっちがキレイ？ 処理方法ごとに数字で比べてみた
先日のDaVinci Resolveのユーザーミーティング「DRUM」の配信（vol.32、ゲストは松尾直樹さん）は「デリバーページを深掘りする回」で、「DaVinci Resolveで書き出したファイルがキレイでない」というSNSのポストを検証していました。マニアックだけど、とても神回でした。
NVIDIAのハードウェアエンコーダーが思ったより優秀、MacはCPUで書き出すと少しきれい、といった話が出ていました。それでは数値にした際どのくらいの違いが出るのか興味を持ち、MacとWindowsの両方で書き出し設定を総当たり（約600本!!）で比べました。と言っても、自分で全部計測するのは正確性と作業量的に不可能に近いので、Claude Codeに指示をして、DaVinci Resolve（Mac／Windows）でプロジェクトの作成からタイムラインの構築、計測、検証までをやってもらいました（MacはResolveのMCPサーバー、WindowsはSSHでつないだスクリプトで操作しています）。
比べた条件
機材：MacBook Pro（M4 Max 48GB）と、自作Windows機（Ryzen 9 5950X、RTX 3090）。どちらもDaVinci Resolve Studio 21.1.1
長さ：各10秒。UHD、素材のフレームレートのまま書き出し
ビットレート：20、40、60、100Mbps
画質の測り方：元の映像との差をVMAF（人の見た目に近い画質の点数、100点満点）で計算。キーフレーム（Iフレーム）はほかより明らかにきれいに出るので、点数から外しています
公平にするため、各素材は一度Rec.709に変換して可逆圧縮のマスターにし、MacもWindowsも同じマスターから書き出しました。元の素材から完成ファイルまでの時間は、これとは別に測っています。
使った素材は次の10本です。
c01 水しぶき（Z8 8.3K N-RAW）
c02 高山帯の遠景（N-RAW 6K）
c03 のっぺりした室内（H.265 10bit）
c04 ジンバルで移動（ZR R3D NE）
c05 朝焼け（ZR R3D NE）
c06 風で揺れる木の葉（ZR R3D NE）
c07 星空と夜景（H.265 8bit）
c08 人の肌・女性（Artlist、ProRes）
c09 人の肌・男性（Artlist、ProRes 4444）
c10 高彩度の赤（Artlist、ProRes）
H.265の処理方法で、どれだけ違うか
H.265は、同じResolveの中でも処理のしかたがいくつか選べます。MacのいちばんいいH.265（ネイティブ、ハードウェア、速度重視オン）を基準にして、同じ画質を出すのに何%のビットレートが必要かで比べました。マイナスが大きいほど、少ないビットレートで元に近く書き出せています。
MacとWindowsのNVIDIAは、指定したビットレートどおりには書き出しません（Macは簡単な素材だと指定より少なく、NVIDIAは少し多め）。なので、同じ40Mbps指定の点数を並べるより、この比べ方のほうが公平です。
この表のビットレートの比較と画質の点数は、代表の4本（水しぶき、高山帯、のっぺりした室内、夜景）で出しています。MacのソフトウェアとMainConcept、Windowsのネイティブは時間がかかるので、この4本だけで比べています。
いちばん元に近かったのはMainConceptで、基準の半分くらいのビットレートで同じ画質が出ました。ただ、10秒のクリップ1本に10分くらいかかります。
Macの「速度重視で最適化」は、オンでもオフでもほとんど同じでした。オフにする意味はなさそうです。逆に、Macでハードウェアアクセラレートを外してソフトウェアで書き出すと、画質が下がって時間は10倍ほどかかりました。配信では「MacはCPUで書き出すと少しきれい」という話でしたが、H.265ではそうなりませんでした。素材によるかもしれませんが。
同じ処理方法で、MacとWindowsにどんな差が出るか
MainConcept：ほぼ同じ
同じマスターから書き出すと、MacとWindowsで点数はほぼ同じでした（水しぶき40Mbpsで81.40と81.38）。ファイルの中身まで完全に同じではありませんが、見て分かる差ではありません。時間もどちらも10秒のクリップに約10分で、MainConceptを使うならMacでもWindowsでも結果は変わらない、と考えてよさそうです。
ネイティブ：Windowsのほうが元に近い
同じ「ネイティブ」でも、中身が違いました。Macはハードウェアアクセラレートをオンにすると、Macのチップの中の動画用の回路で書き出します。Windowsの「ネイティブ」は、書き出し中の負荷を見るとNVIDIAのエンコーダーが動いていました。結果は、Windowsのネイティブが基準より18%少ないビットレートで同じ画質で、NVIDIAの最良の設定に近い数字です。
ハードウェアどうし（Macの回路とNVIDIA）：設定しだいで逆転
Macのハードウェアと、WindowsのNVIDIAを初期設定のまま比べると、Macのほうが元に近い結果でした（NVIDIAは13〜26%多くのビットレートが必要）。NVIDIAを最良の設定にすると逆転して、10本中9本でWindowsのほうが元に近くなります（Macが上だったのは女性の肌の1本だけ）。設定を詰めればNVidiaの方がキレイに出力できるようです。
そのかわり時間はMacが速く、元の素材から書き出すと10秒のクリップでMacが4〜5秒、Windowsの最良の設定は約20秒でした。
差はどこから来ているのか
同じ素材を同じように書き出しても、MacとWindowsで画質に差が出ます。いくつか確かめた結果、圧縮を受け持つ回路の違いだと考えています。
まず、圧縮する前の映像は同じでした。MacとWindowsで同じマスターから書き出していて、RAWの現像結果もMacとWindowsでほぼ一致していることを別に確かめています。そのうえで、同じソフトの圧縮（MainConcept）を使うとMacとWindowsで点数がほぼ同じ（81.40と81.38）になりました。OSやResolveの処理の違いでは差が出ず、それぞれの専用回路で圧縮したときだけ差が出ています。
ちなみに、Macの「ネイティブ」がMetalを使っているのかも気になったので、書き出し中の負荷を測ってもらいました。
Metalは、RAWの現像や縮小でほぼ全開まで使われていました。一方で、すでに圧縮されている素材を書き出したときは、1秒あたり約180フレームの速さで圧縮していてもグラフィックス処理はほとんど動いていません。圧縮そのものはMetalではなく、Macのチップの中の動画専用の回路が受け持っているようです（この回路の使用率はMacのツールでは直接見られないので、負荷の差からの判断です）。Windowsでも、圧縮はNVIDIAのエンコーダーという、計算用とは別の部分で行われていました。
ただ、回路の性能だけで決まっているわけでもなさそうです。NVIDIAは初期設定だとMacより下で、設定を詰めると上になります。Resolveで変えられる設定も、NVIDIAは処理の丁寧さや2パス、先読みなどいろいろあるのに対して、Macは「速度重視で最適化」だけで、それもほとんど差がありませんでした。ビットレートの使い方も違っていて、Macは簡単な素材だと指定より少なめに、NVIDIAは少し多めに使います。
今回のNVIDIAはRTX 3090（エンコーダーとしては一世代前）で、MacはM4 Max、どちらも1台ずつの結果です。新しいGeForceではH.265の画質が上がっていると言われているので、世代が違えば結果も変わるかもしれません（ここは試せていません）。
H.264について
H.264で出力した場合は？ H.265はH.264の約半分のビットレートで、同じくらいの画質になりました。MacでもWindowsでも同じ傾向です。基本的にはH.265の方がファイルサイズ的にもお勧めできるのですが、WindowsパソコンにH.265のライセンスが入っておらず再生できない事があるのでクライアントワークなどでは気をつける必要があります。
素材ごとの結果
グラフは横がビットレート、縦が画質の点数で、上にあるほどきれいです。拡大は、画質がいちばん落ちていたフレーム（最初の1秒とキーフレームを除く）の、元との差が大きかった場所を2倍にしています。波形は同じ場所の輝度の波形で、「波形一致」は元の波形とどれだけ同じか、「細部」は細かい凹凸がどれだけ残っているかの割合です。
c01 水しぶき
いちばん差が出た素材です。40MbpsでもH.264は点数が70〜75点で、細かい水しぶきが平らにつぶれています。MainConceptだけが81点と頭ひとつ抜けていました。波形でもH.264は点のばらつきが消えて、灰色の帯のようにまとまっています。
c02 高山帯の遠景
どの設定も95点以上で、差は小さめです。点数ではH.265のほうが少し上です。
c03 のっぺりした室内
低いビットレートでもほぼ100点近くで、見た目ではほとんど分かりません。波形ではH.264だけ少し形が崩れていました。
c04 ジンバルで移動
画面全体が動く素材は20Mbpsで大きく落ちます。MacのH.264は20Mbpsで81点まで下がり、40Mbpsにすると93点まで戻りました。
c05 朝焼け
グラデーションの素材は、MacのH.265がH.264よりわずかに低いという、ほかと逆の結果でした。どれも94〜96点で、差はごくわずかです。
c06 風で揺れる木の葉
細かい葉が全体で動くので、水しぶきの次に差が出ました。40MbpsでMacのH.264が86点、WindowsのNVIDIA H.265（最良）が93.5点です。
c07 星空と夜景
星や暗部のノイズは、MacのH.264とH.265でほとんど差がありませんでした。WindowsのNVIDIA H.265（最良）とMainConceptが少し上です。
c08・c09 人の肌
肌はどの設定でも96点以上で、40Mbpsあれば気になる劣化はありませんでした。
c10 高彩度の赤
赤い花もどれも95点以上でした。
波形で見た違い（10本の平均）
配信で話していた「波形が薄くなる」は、数字にしても同じ傾向が出ています。H.264は波形の形が崩れやすく、MacのH.264は細かい凹凸の残り方も少なめです。点数（VMAF）の順番とほぼ同じになりました。
色とディテール、バンディング
点数（VMAF）と波形は明るさだけを見ているので、赤の崩れやグラデーションの縞は数字に出にくいです。そこで、気になる部分だけを別の測り方で確かめました（どれも40Mbpsで比較）。
朝焼けのバンディング：H.264だけ縞が出る
バンディング専用の指標（CAMBI。Netflixが公開しているもので、0なら縞なし、数字が大きいほど縞が目立つ）で測りました。元のマスターは0です。
H.265はどれもほぼ0で、縞が出たのはH.264だけでした。 MacのH.264（ハードウェア）は20Mbpsにすると平均4.8、いちばん出たフレームで10.7まで上がります。H.265（メイン10）は10bit、H.264（ハイ）は8bitで書き出されているので、その差がそのまま出ていると考えています。
点数（VMAF）では、朝焼けだけMacのH.265がH.264よりわずかに低い結果でした。縞で見ると逆で、H.265のほうがはっきり上です。空のグラデーションが多い映像は、点数だけで判断しないほうがよさそうです。
赤い花：色の細かい模様はどれも7割ほど
花びらの範囲だけで比べると、明るさの細かい模様は94〜96%残っていた一方で、赤の濃淡の細かい模様は72〜75%しか残っていませんでした。
これは処理方法の差というより、色の情報の持ち方によるものです。マスターは色の情報を横方向だけ半分（4:2:2）で持っていますが、書き出したH.264とH.265はどれも縦横とも半分（4:2:0）になるので、その時点で色の細かさが落ちます。そのうえで比べると、模様の一致度はH.265のほうが少し上で（H.264が0.64〜0.66、H.265が0.69〜0.72）、いちばん元に近かったのはWindowsのNVIDIA H.265（最良）でした。
人の肌：H.264は「ざらつき」が別物になる
額の範囲で見ると、H.264は細かい凹凸の量は元とほぼ同じ（99〜102%）なのに、元の模様との一致度は0.86〜0.88でした。凹凸の量は残っていても、圧縮でできたざらつきが混ざっていて、肌のきめそのものとは違うものになっています。H.265は凹凸の量が94〜96%と少しなめらかになる代わりに、一致度は0.91〜0.92で、残っているのは元のきめです。男性の鼻のまわりでも同じ傾向でした（一致度 H.264が0.91〜0.93、H.265が0.95〜0.96）。
高山帯の木と岩肌：差は小さい
動きの少ない木や岩肌は、どの処理方法でも細かい凹凸が95〜98%残っていて、40Mbpsなら見て分かる差はありませんでした。数字のうえではWindowsのNVIDIA H.265（最良）とMainConceptが少し上で、H.264がわずかに下という、全体と同じ並びです。
元の素材から完成までの時間
10秒のクリップ1本あたり、RAWを読み込んで書き出し終わるまでの時間です。
ここはMacのほうがかなり速く出ました。8.3KのN-RAWからUHDのH.264でも、10秒の素材が8秒ほどで書き出せました。WindowsのNVIDIAを最良の設定にすると、初期設定の2.4倍くらい時間がかかります。
YouTubeに上げるとどうなるか
書き出したファイルは、YouTubeでもう一度圧縮されます。どのくらい変わるのか、上げるファイルで差が出るのかを確かめました。c01〜c07の7本をつないだ70秒の映像を、次の3種類で書き出して限定公開でアップロードし、YouTubeが作り直した映像を元のマスターと比べています。
MacのH.265（ハードウェア、40Mbps、10bit）
MacのH.265（ハードウェア、100Mbps、10bit）
ProRes 422（約550Mbps、10bit。70秒で4.9GB）
点数は7本の平均です。フルHDは、元をフルHDに縮小したものと比べています。
上げる前の画質が高いほど、YouTubeで見たときの画質も高くなりました。 ProRes 422で上げると、YouTube側の4Kのビットレートが約20.8Mbpsと、H.265で上げたとき（約15Mbps）より多く割り当てられていました。フルHDでも約3.8Mbps（H.265は約2.4Mbps）で、スマホなどフルHDで見る人ほど差が大きく出ています（79.6→84.1）。H.265を40Mbpsから100Mbpsに上げても、YouTube後の差は2点ほどでした。
YouTubeが作った映像は、どれも8bitでした（4KとフルHDはVP9、フルHDにはH.264版もあり）。10bitで上げても、視聴者には8bitで届きます。
動きが多くて細かい素材ほど、ProResで上げた差が大きく出ました。水しぶきは69.5→80.8、ジンバルで移動は88.2→94.1です。水しぶきは、H.265 40Mbpsで書き出した時点の点数（74.2）より、ProResで上げたYouTube版のほうが上でした。
縞（バンディング）は、どのファイルで上げても出ました。 アップロード前はほぼ0だったのが、のっぺりした室内で13.6〜13.7、朝焼けで9.8〜10.4です。H.264で書き出した朝焼け（3.8）よりも大きい値で、YouTubeが8bit・限られたビットレートで作り直す段階で出ています。例外は星空で、ProResで上げると1.7と、H.265 40Mbps（5.6）より少なくなりました。
比較画像
同じフレームの同じ場所を2倍に拡大して並べています。左上が元の映像で、ほかの3つがYouTube 4Kです。縞は見えにくいので、明るさの差を強調した画像も載せています。
設定の最適解を探る
YouTube用
YouTubeで見たときの画質を優先するなら、ProRes 422で上げるのがいちばんでした（YouTube 4Kで87.9→91.8、フルHDで79.6→84.1）。ただ、70秒で4.9GBと、H.265 40Mbps（約340MB）の約14倍の大きさになり、アップロードに時間がかかります。普段は下の設定で、水しぶきや星空のように細かくて動きのあったり、少しでも高画質にこだわりたい映像はProRes 422で上げる、という使い分けがよさそうです。縞はどのファイルで上げても出たので、空や白い壁のようなグラデーションが多い映像は、YouTubeで縞が出る前提で見ておいたほうがよさそうです。
画質優先（納品やマスター用、MainConcept以外）
H.264が必要なとき（互換性優先）
WindowsのNVIDIAは、初期設定のまま目標を100Mbpsにすると、実際には105〜110Mbpsくらい出ていました（最良の設定では約98Mbps）。ファイルサイズに上限がある納品では、少し低めに設定しておくと安心です。
比較動画
拡大した部分を動画にして、元の映像と並べたものも作りました（4K、ProRes 422で作ってアップロード）。どれも左上が元の映像で、同じ場所を2倍に拡大しています。
水しぶき 20Mbps：H.264のMacとWindows
水しぶき 20Mbps：H.265とMainConcept
水しぶき：MacのH.264を20・40・100Mbpsで比較
夜景 40Mbps：圧縮方法による違い
木の葉 40Mbps：MacとWindows
水しぶき 20Mbps：元との差を8倍に強調（明るいところほど劣化が大きい）
YouTubeでは再度圧縮が掛かってしまうので出力したファイルとは見え方は変わってしまいます。
かなりマニアックな文章になってしまいましたがいかがだったでしょうか？私自身今回のDRUMを見なければなぁなぁで済ましてしまっていたところですが、検証したことで見えてくるものもありました。今回はM4 MaxとRTX 3090で比べましたが、CPUやGPU、そしてDaVinci Resolve自体の進化で結果は変わっていくと思います。数年に一度は検証し直してみるのも良さそうですね。DaVinci Resolveで書き出す時の参考になれば幸いです。
最後に少し宣伝です。山の映像と写真に特化したオンラインコミュニティ「Wonder Mountains」を運営しています。よかったらのぞいてみてください。
