ffmpeg 8.1.2 は ARM64 版に替えても決定打にならなかった

ffmpeg 8.1.2 の x64 版と BtbN の ARM64 版を比べたら、x264 medium 720p は3.61秒対3.28秒で x64 が1.10倍遅いだけだった。

手元では ARM64 版へ入れ替える強い理由は出なかった。winget で入った ffmpeg.exe が x64 だと分かった時点では、Windows 11 Pro の ARM64 上でエミュレーションが足を引っ張り、ネイティブの BtbN ビルドが素直に勝つと思っていた（かなり単純に見ていた）。

実際に測った結果はもっと面倒だった。x264 の medium プリセットで 720p に落とす処理は ARM64 が少し速い。ところが x264 ultrafast の 1080p では x64 のほうが速く、純粋なスケーリングだけを見る -f null では ARM64 がはっきり速い。どれかひとつを取り出して「ネイティブが速い」「エミュレーションでも十分」と言い切ると、残りの数字に裏切られる（この割れ方が、今回いちばん面倒なところ）。

測定日は2026-06-30。マシンは Microsoft Surface Pro, 11th Edition、Snapdragon X 12-core X1E80100 @ 3.40GHz、メモリ 32GB の ARM64 Windows 環境。電源は AC 接続、電源プランは既定のバランスのままにした（普段の作業状態から大きくは外していない）。

まず winget 版の正体を見た

winget で入っていた実行ファイルは Gyan.FFmpeg 配下の ffmpeg-8.1.2-full_build にあった。パスを見るだけでも x64 か ARM64 かは分からないので、最初に実体を確認している（winget のパッケージ名だけでは決められない）。ここで x64 だと分かり、では ARM64 ネイティブ版を持ってきたらどうなるのか、という流れになった。

ARM64 版は BtbN/FFmpeg-Builds の winarm64-gpl zip を落として、zip の中から ffmpeg.exe を取り出した。実際に使った取得コマンドはこれだ。

curl.exe -L -s -o C:\Users\AKIRAS~1\AppData\Local\Temp\arm64lab_c\ff-arm64.zip https://github.com/BtbN/FFmpeg-Builds/releases/download/latest/ffmpeg-master-latest-winarm64-gpl.zip

ダウンロードは7.8秒で終わり、zip は114800704バイトだった。作業用に展開した ARM64 版の ffmpeg.exe は C:\Users\AKIRAS~1\AppData\Local\Temp\arm64lab_c\ffmpeg-arm64\ffmpeg.exe に置いている。素材も同じ ARM64 版で作った。testsrc2 の 1920x1080、30fps、20秒の合成映像を libx264 ultrafast で src.mp4 にしたものだ。生成に14.78秒かかり、できたファイルは38850889バイトだった（実写ではないので、ここも結果の読み方に効いてくる）。

比べたジョブ

比較したジョブは3本に絞った。1つ目は x264 medium で 720p へ落とす処理、2つ目は x264 ultrafast の 1080p、3つ目はエンコードをほぼ外してスケーリング結果を -f null に捨てる処理である。各ジョブは x64 版と ARM64 版で3回ずつ測った。

この設計は正直に言って粗い。素材は実写ではなく testsrc2 の合成映像だ。1ジョブの実行時間も0.52秒から5.81秒の範囲に収まっていて、プロセス起動やファイル I/O の比重が大きい。反復も3回だけなので、中央値を出しても安心できるほどではない。それでもまずは小さく測ってみた。

ffmpeg のビルドを差し替える動機があるかを見たいだけなら、最初の当たりとしては悪くない。ただ、1割程度の差を判定する用途には足りず、この点は測り終えてから気づいた失敗だった。

runs_s をそのまま見る

中央値だけを見ると見通しがよくなるが、今回はそれをやると危ない。ばらつき自体が結果の一部なので、3回分の runs_s と fps_samples をそのまま載せる。

ジョブ	ビルド	runs_s 全3回	median_s	fps_samples
x264 medium 720p	x64	2.94 / 3.61 / 5.81	3.61	225 / 179 / 109 fps
x264 medium 720p	ARM64	3.94 / 2.24 / 3.28	3.28	206 / 289 / 261 fps
x264 ultrafast 1080p	x64	1.88 / 1.81 / 1.61	1.81	375 / 391 / 420 fps
x264 ultrafast 1080p	ARM64	2.18 / 5.20 / 1.86	2.18	458 / 120 / 567 fps
scale only null	x64	0.73 / 0.76 / 0.76	0.76	0 / 0 / 0 fps
scale only null	ARM64	0.55 / 0.52 / 0.53	0.53	0 / 0 / 0 fps

x264 medium 720p は x64 が3.61秒、ARM64 が3.28秒で、x64 が1.10倍遅い。

これは予想どおりの向きだが、差は小さい。3回の中には x64 の2.94秒もあれば ARM64 の3.94秒もあるので、1回だけ測ったら逆に見えていた可能性がある（この時点で、勝ち負けを急ぐのは危ない）。

x264 ultrafast 1080p はもっと意外だった。中央値は x64 が1.81秒、ARM64 が2.18秒で、x64_slower_x は0.83倍になっている。つまりこの条件では x64 のほうが速い。ARM64 側の fps_samples は458 / 120 / 567 fps と暴れており、同じ条件のはずなのに120fpsから567fpsまで振れている。この幅を見ると、2.18秒という中央値にもかなり警戒が必要になる。

scale only null だけは素直だった。x64 は0.76秒、ARM64 は0.53秒で、x64 が1.43倍遅い。エンコードを外してスケーリング寄りにしたときは、ネイティブ版のほうが有利に見える。けれど fps_samples は全部0fpsで、ffmpeg の出力から拾える指標としては役に立たなかった、という落ち。

失敗したのは測り方のほう

今回の一番大きな失敗は、測定単位が短すぎたことだ。20秒の素材を処理しているのに、ジョブ自体は2秒から4秒程度で終わるものが多い。これだと ffmpeg.exe の起動、入力ファイルを開く時間、出力先の作成、OS のキャッシュ状態が混ざりやすい。

反復3回も不足していた。x264 ultrafast 1080p の ARM64 は runs_s が2.18秒、5.20秒、1.86秒で、最大と最小が2.80倍も違う。fps_samples も120fpsから567fpsまで動いた。この振れ幅では、1.10倍の差を性能差として扱うには厳しいだろう。なぜもっと長い素材にしなかったのか。

もうひとつの勘違いは、ARM64 ネイティブ対 x64 エミュレーションをそのまま「エミュレーションのコスト」と見そうになった点だ。libx264 は手書きアセンブリの最適化が厚い領域で、ARM64 ビルドと x64 ビルドでは使っているカーネルが違う可能性がある。実際には CPU 命令、x264 の実装、ffmpeg のビルド設定、Windows のエミュレーション、I/O の揺れが重なっている。単純な翻訳コストだけを切り出した測定ではない、という話。

この点に気づくまで、正直「ネイティブなら勝つはず」という見方をしていた。数値はその期待を崩している。結果がまちまちだったこと自体を、今回の結論として扱うべきだった。

手元の運用は変えない

個人的には、いまの数字だけで ffmpeg を ARM64 版へ置き換える気にはならない。x264 medium 720p の3.61秒対3.28秒は差が小さいし、x264 ultrafast 1080p ではx64が1.81秒で勝っている。scale only null の0.76秒対0.53秒は ARM64 が強いものの、普段の用途がそこだけに寄るわけではない。

手元では winget 版のままにしておく。パッケージ更新の楽さもあるし、今回の範囲では x64 エミュレーションが明確なボトルネックだとまでは読めなかった。むしろ Surface Pro 11th Edition 上の Windows 11 ARM64 は、x64 の ffmpeg でも思っていたより普通に動いてしまう、という印象が残った（この結果は少し悔しい）。

次にやるなら、実写素材で長時間のエンコードを測り直したい。少なくとも数分単位の入力を使い、反復も増やし、最初の1回をウォームアップとして捨てる。2026年6月30日の小さな実験としては、ARM64 版に替えれば常に速くなる、という期待をいったん止めるには十分だった。