NVIDIA GPUで4K iPhone動画をより速く圧縮（VideoRecompress 2026.2.17）
NVIDIAのグラフィックカードがあれば、VideoRecompress Studio 2026.2.17は4KのiPhoneクリップを以前より37–48 %短い時間で圧縮し、その間プロセッサーはほぼ空いたままです。出力の見た目もサイズも変わりません。スマホ動画に関する2つの不具合も修正しました。縦向きのクリップをリサイズしても潰れなくなり、HDRのiPhone動画は遅いCPUエンコーダーに切り替わることなく、グラフィックカード上でH.264に変換されるようになりました。
測定環境：AMD Ryzen 9 3900XとNVIDIA RTX 3080を搭載したPC 1台、実際のiPhoneで撮影した4K HEVC 10ビット映像（30 fps、約30 Mbit/s）。
改善前と改善後（RTX 3080で測定）
| 処理 | 改善前 | 2026.2.17 |
|---|---|---|
| 17 sの4K iPhoneクリップをH.265へ：時間 | 16.3 s | 9.5 s (−42 %) |
| 同じクリップを縦向きで撮影：時間 | 15.0 s | 9.5 s (−37 %) |
| CPU時間（4Kクリップ） | 154 s | 2.3 s (−98 %) |
| 最大メモリ使用量（4Kクリップ） | 5.30 GB | 4.45 GB |
| 出力ファイル（4Kクリップ） | 64.1 MB | 63.7 MB |
| 4Kから1080pへのリサイズ：エンコード時間 | 9.1 s | 1.7 s |
| 4Kから1080pのプリセット：コマンドライン全体の実行 | 12.9 s | 3.7 s |
| 起動ごとのハードウェアエンコーダー確認 | 0.8–1.3 s | 33 ms |
| コマンドライン起動時のライセンス確認（登録済み） | 1.1–2.0 s | 41 ms |
VideoRecompressのコマンドラインで旧版と新版を交互に3回ずつ実行した中央値。各実行には約1.5 sのプログラム起動時間を含みます。4Kクリップでの以前の2回の測定では46–48 %の短縮でした。
つまりこういうことです。以前はプロセッサーが4K HEVCのフレームを1枚ずつ展開しており、10コアがふさがった状態でRTX 3080は毎秒21フレームに抑えられていました。今はグラフィックカードが展開とエンコードの両方を行うため、クリップは早く終わり、プロセッサーは他の作業に使えます。
短い720pや1080pのクリップでは時間の短縮は小さい（エンコードで5–8 %）ものの、CPU時間は59–72 %減ります。
画質は変わりません。単純な再圧縮では、8ビット動画は従来の方法とビット単位で同一になります。10ビットのiPhone動画では、ファイルサイズの差は1 %未満で、元の映像に対するSSIMスコアは同等かわずかに高くなります。
GPUでのリサイズ：約5×高速、ファイルは約20 %大きく
| 処理 | CPUスケーラー（以前） | GPUスケーラー（現在の既定） |
|---|---|---|
| 17 sの4Kクリップを1080pへ：時間 / CPU時間 | 9.1 s / 122 s | 1.7 s / 1.6 s |
| 同じ品質設定でのファイルサイズ（2クリップ） | 5.50 / 3.44 MB | +19 % / +22 % |
| 同じファイルサイズでのVMAF（2クリップ） | 46.0 / 59.2 | −4.5 / −2 |
RTX 3080で、iPhoneの4K HEVC 10ビットクリップ2本を使用。VMAFは各出力を4Kの元映像のサイズに戻して測定しました。
4Kから1080pのプリセットのようなリサイズでは、以前はすべてのフレームをプロセッサーに戻していました。リサイズだけを行う場合、2026.2.17ではスケーリングもグラフィックカード上で行います。17 sの4Kクリップで9.1 s → 1.7 s、CPU時間は122 sから1.6 sに減りました。
トレードオフもはっきり書いておきます。GPUのスケーラーはCPUのスケーラーと同じではありません。同じ品質設定ではファイルが約20 %大きくなり、同じサイズではスコアがやや低くなります。フレームを並べて比較したうえで、GPUを既定にしました。
NVIDIA GPUがない場合、切り抜き・ノイズ除去・手ぶれ補正・透かしや字幕の追加を同時に行う場合、回転情報付きのクリップをMKVやWebMに出力する場合、そしてGPUでの処理が失敗した場合は、引き続きCPUのスケーラーを使います。
スマホ動画に関する2つの修正
縦向き動画はリサイズしても形が崩れません
ウィザードで解像度を選んだ場合、4Kから1080pのプリセットを使った場合、またはコマンドラインで--widthと--heightを両方指定した場合、フレームの縦横両方が固定されていました。縦向きのスマホ動画は横長のフレームに押し潰され、4:3の動画は16:9に引き伸ばされていました。
動画は選んだサイズの内側に収まるように調整され、枠は映像が見える向きに合わせて回転します。縦向きの4Kクリップを1080pにすると、1080 × 1920の縦向きで再生されます。
HDRのiPhone動画からH.264への変換がGPUで動作
iPhoneはHDR動画を10ビットで記録します。NVIDIAのH.264エンコーダーは10ビットのフレームを受け付けないため、SNS用プリセットが使う形式であるH.264への変換は、NVIDIAカードを搭載したすべてのPCで失敗していました。その後アプリは何も知らせずに、はるかに遅いCPUエンコーダーに切り替えていました。
VideoRecompressは現在、まずグラフィックカード上でフレームを8ビットに変換し、処理はNVENCのまま進みます。
もう1つ気付くかもしれない変更があります。MP4やMOVで保存する縦向きクリップは、プロセッサーで1フレームずつ回転させる代わりに、スマホの回転フラグをそのまま保持します。プレーヤーでは同じ縦向きの映像が表示されます。
仕組み
- 同じカードでデコードとエンコードエンコーダーがNVENCで、プロセッサー側でフレームを必要とする処理がない場合、NVIDIAカードが動画を展開し、フレームをそのまま自身のエンコーダーに渡します。
- 確認済みのフォールバックGPUでデコードした処理が失敗した場合は、ソフトウェアエンコーダーに切り替える前に、プロセッサーでデコードして同じ処理をやり直します。
- エンコーダー確認の結果を記憶どのハードウェアエンコーダーが使えるかのテストは、以前は起動のたびに実行されていました（テストエンコード10回、0.8–1.3 s）。現在は結果をffmpegのビルドとグラフィックドライバーごとに保存し（初回0.7 s、以降33 ms）、30日後またはハードウェアエンコードが失敗したときに再確認します。
- RAMに合わせた並列処理4K 10ビットのエンコード1本には4.4–5.3 GBのメモリが必要です。以前のルールでは、8 GBが一般的なPCで最大4本を同時に実行し、約20 GBを必要としていました。現在のキューは並列エンコードを搭載メモリの半分以内に収めます。8 GBなら4Kは1本、1080pなら3本ずつです。
- より速いコマンドライン登録済みのコピーは24時間以内のライセンス確認を再利用するため、
videorecompressCLIは呼び出しのたびにサーバーを1.1–2.0 s待つことがなくなりました。エンコーダー確認の保存と合わせて、12 sのクリップは開始から終了まで1.5–1.6 sになりました（以前は3.2–4.5 s）。
GPUでのデコードとリサイズには、NVENC対応のNVIDIAカードが必要です。これがないPC、またはIntel Quick SyncやAMDのエンコーダーを使うPCでは、VideoRecompressは以前とまったく同じようにプロセッサーでデコードします。縦向き動画の修正、エンコーダー確認の保存、メモリに合わせたキューはすべてのPCに適用されます。
VideoRecompress 2026.2.17を入手
すでにインストール済みの場合は、VideoRecompress Studioを起動してください。上部のバナーにバージョン2026.2.17が利用可能と表示され、ダウンロードに進めます。現在のバージョンに上書きでインストールしてください。
初めての方へ：無料体験版では10ファイルまで透かしなしで圧縮できます。その後は登録するまで、出力に透かしが入り、10分で停止します。