背景と判断の流れ（先に全体像）

PCの空き容量が10GBを切っており、先に動画ファイルを圧縮して容量を確保する必要があった。
複数の動画をまとめて処理するために圧縮用のバッチを作って試したところ、40分程度の動画1本に80分近くかかり、この待ち時間に毎回付き合うのはコスパが悪すぎると感じた。

設定を細かく詰める方向ではなく、実行環境の前提そのものを見直した方が早いと判断し、最終的にGPUを使う方式に切り替えた。

結論

処理内容そのものではなく、「CPUで処理する前提」がボトルネックだった。
実行環境と制約を整理した上でGPUを使う方式に切り替えた結果、
40〜50分の動画が数分程度で処理できるようになり、待ち時間を前提に作業を組み立てる必要がなくなった。

やりたかったこと / 課題

• 動画ファイルを圧縮してディスク容量を確保したい
• 複数ファイルをまとめて処理できるようにしたい
• 処理待ちで作業が止まる状態は避けたい

前提・環境

• OS: Windows
• 実行環境: PowerShell
• ハードウェア: Intel CPU（内蔵GPUあり）
• 使用ツール: ffmpeg
• 制約条件:
  • WSL と Windows で利用できる機能が異なる
  • PowerShell のバージョン差がある
  • GPUが使えるかどうかを最初は把握していなかった

※ 後から再現できる粒度を意識して整理した

試したこと

案1：CPU前提での動画圧縮

まずは一般的な設定で動画を圧縮するバッチを作成し、動作確認を行った。

結果

• 正常には動作する
• 40分の動画に対して処理時間が約80分
• このまま複数ファイルを処理するのは現実的ではないと感じた

案2：CPU前提のまま調整

• エンコード設定の調整
• スレッド数や並列数の変更

結果

• 多少は改善するが、根本的には変わらない
• CPU使用率が上がる割に、待ち時間はあまり減らない
• 「この待ち時間に最適化コストを払い続ける意味があるのか？」という疑問が強くなった

ダメだった理由 / 捨てた判断

• 処理自体が重く、CPU側の最適化には明確な上限があった
• 設定を詰めるほど、方向性そのものに違和感が出てきた
• 待ち時間の長さを考えると、前提条件を疑う方が合理的だと判断した

最終的に選んだ方法

実行環境を整理し、GPUアクセラレーションが利用可能かを確認した。
CPUで処理する前提をやめ、GPUの専用回路を使う方式に切り替えた。

ffmpeg -i input.mp4 \
  -c:v hevc_qsv -global_quality 24 -preset medium \
  -c:a copy output.mp4

結果

• 40〜50分の動画が、実時間で数分程度で処理できるようになった
• 実測では動画時間に対して 数倍速 で処理できている
• 最初に試したCPU前提の方法と比べると、体感では桁違いに高速
• CPU負荷が下がり、並列実行も現実的になった
• 処理待ちをほぼ気にせず、他の作業を進められるようになった

注意点・補足

• GPUアクセラレーションは環境によって利用できない場合がある
• WSLとWindowsでは使える機能が異なるため、実行環境の整理が重要
• 「何が使えるか」を事前に確認しないと、そもそも選択肢に気づけない

まとめ

• 時間がかかる処理では、設定調整より前に前提条件を疑った方が早いことがある
• 「動くかどうか」ではなく、「その待ち時間に付き合う価値があるか」で判断する
• 技術選定は目的ではなく、時間と作業効率を最適化するための手段