【ITニュース解説】-preset slow bought 0.16%. Ten ffmpeg settings measured on two ARM cores.

この記事は、AIである筆者（Obole）が、自身が実際に使う動画エンコードツール「ffmpeg」の設定を詳細に測定した結果をまとめたものだ。筆者はGPUを持たない2コアのARMサーバー上で動作しており、日常的に短い動画を公開している。その際に、最適なエンコード設定を見つけるため、ファイルサイズ、エンコードにかかる時間、そして動画の品質の3つのバランスを検証した。

動画エンコードとは、動画のデータを圧縮してファイルサイズを小さくする作業のことだ。ファイルサイズが小さいほど、保存やインターネットでの共有がしやすくなるが、圧縮率を上げすぎると動画の画質が劣化してしまう。そのため、適切なバランスを見つけることが重要になる。ffmpegは、この動画エンコードを行うための強力なツールで、さまざまなオプションを使って圧縮の度合いや方法を細かく設定できる。

この記事で主に検証しているのは、H.264という動画圧縮方式で使われる「libx264」というエンコーダの設定だ。特に重要な3つの設定について見ていこう。

1. -crf (Constant Rate Factor): これは「品質固定モード」と呼ばれ、エンコード後の動画の品質を一定に保つように設定する。たとえば、-crf 23と設定すると、画質が23という品質レベルになるようにエンコーダが自動的にファイルサイズを調整する。数値が小さいほど高画質になり、ファイルサイズは大きくなる。逆に数値が大きいほど低画質になり、ファイルサイズは小さくなる。この設定は、ユーザーが「これくらいの画質が欲しい」という基準でエンコードしたい場合に非常に便利だ。

2. -b:v (Video Bitrate): これは「ビットレート固定モード」と呼ばれ、エンコード後の動画の1秒あたりのデータ量（ビットレート）を直接指定する。たとえば、-b:v 2Mと設定すると、動画のビットレートが2Mbps（メガビット毎秒）になるようにエンコードされる。ビットレートが高いほど画質は良くなるがファイルサイズも大きくなり、低いほど画質は悪くなるがファイルサイズは小さくなる。この設定を使うと、目標とするファイルサイズを厳密に決められるが、動画の内容によっては画質が大きく変動してしまう可能性がある。この記事の筆者は、この設定を推奨していない。なぜなら、動画の内容に対して必要以上に大きなビットレートを指定してしまうと、ファイルサイズが無駄に肥大化することが示されたからだ。

3. -preset: これはエンコード速度と圧縮効率のバランスを決める設定だ。動画をエンコードする際には、エンコーダがどれだけ時間をかけて最適な圧縮方法を探すかによって、結果が変わってくる。

   • veryfast（非常に速い）: エンコード時間が短くなるが、ファイルサイズはやや大きくなりがち。
   • medium（中程度）: 速度と圧縮効率のバランスが良い。
   • slow（遅い）: エンコード時間は長くなるが、ファイルサイズを最も小さくできる可能性が高い。 この記事の筆者の検証では、slowはmediumと比較してファイルサイズがわずかしか減らず、エンコード時間が大幅に伸びるため、2コアのマシンではあまりメリットがないことが分かった。

筆者は、テストのために2種類の動画素材を用意した。

• 素材A: 筆者が実際に公開している動画で、黒い背景に白い文字が中心、動きが少ないシンプルな内容だ。このような動画は圧縮しやすく、品質を保ちやすい。しかし、これだけで結論を出すと、他の種類の動画には当てはまらない可能性があるので注意が必要だ。
• 素材B: ffmpegを使って人工的に作成した、非常に複雑でノイズの多い動画だ。これは一般的なスマートフォンの動画よりもはるかに圧縮が難しい「ハードケース」として作られており、エンコーダの性能差や設定の違いが顕著に現れるように設計されている。この素材は、設定を変更したときに結果がどの方向に動くかを見るための指標として使われた。

動画の品質を客観的に評価するためには、いくつかの指標が使われる。

• SSIM (Structural Similarity Index): これは人間の視覚システムに近い形で画質の劣化度合いを評価する指標で、数値が1に近いほど元の動画に近いと判断される。
• PSNR (Peak Signal-to-Noise Ratio): これは元の動画とエンコード後の動画のデータ上の差を数値化したもので、数値が大きいほど元の動画に近いと判断される。 筆者は、人間の目に最も近いとされる「VMAF」という指標を使いたかったが、筆者の環境では利用できなかったため、SSIMとPSNRで評価を行った。

具体的な測定結果では、いくつかの重要な発見があった。 まず、同じ-crf値であっても、-presetが異なるとファイルサイズと品質が変わる。たとえば、-crf 23 -preset veryfastは、-crf 23 -preset mediumよりもファイルサイズが小さくなるが、それは品質がわずかに低くなるためだ。そのため、正確な比較をするには、ファイルサイズか品質のどちらかを基準に合わせる必要がある。

シンプルな動画素材Aでは、-preset veryfastはmediumと同等の品質を保ちつつ、エンコード時間を24%から32%も短縮できた。これは、シンプルな動画では、エンコーダが時間をかけて圧縮方法を探索しても、大きな効果が得られないことを示している。 しかし、複雑な動画素材Bでは状況が逆転する。この場合は、mediumがveryfastよりもファイルサイズを14.3%も小さくでき、品質もわずかに高かった。これはエンコード時間は約2倍かかるが、詳細な動画素材ほど、エンコーダがより多くの努力（つまり時間をかけること）をすることで、より良い圧縮効果が得られることを示唆している。 また、-preset slowはどちらの素材でも、mediumと比較してファイルサイズの削減がごくわずかであり、エンコード時間が大幅に増えるため、筆者の2コア環境では推奨されない結果となった。

-b:v設定については、特に注意が必要だ。素材Aでは、動画が必要とする以上のビットレートを指定したため、元の動画の約2倍ものファイルサイズになってしまった。素材Bでも、-crf設定と比較して、ファイルサイズが大きくなり、品質も劣る結果となった。このことから、-b:vでファイルサイズを固定するよりも、-crfで品質を固定する方が、無駄なく効率的なエンコードができると筆者は結論付けている。

さらに、動画全体のファイルサイズに占める音声トラックの割合も重要だ。筆者の動画では、画像（映像）部分の圧縮を進めても、音声部分のサイズは変わらないため、エンコード後のファイルサイズの半分近くが音声トラックで占められていた。つまり、画像部分だけを最適化しても、全体のファイルサイズ削減効果は限定的になる場合があるということだ。

最終的に筆者は、自身の動画エンコードに以下の設定を使用することを推奨している。 ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset veryfast -pix_fmt yuv420p -c:a aac -b:a 128k -movflags +faststart output.mp4

この設定は、-crf 23で適切な画質を保ちつつ、-preset veryfastでエンコード時間を短縮し、音声もaac -b:a 128kで適切なビットレートに設定している。これにより、ファイルサイズとエンコード時間のバランスがとれた効率的なエンコードが可能になる。もし素材が複雑でエンコード時間に余裕があるなら、-preset mediumでより圧縮効率を高めることも考えられる。

ただし、この実験は筆者の特定の環境（ARMコア2つ、GPUなし）で行われたものであり、他のCPUアーキテクチャ（x86など）やGPUを搭載したマシン、あるいはH.265やAV1といった異なるエンコーダを使用した場合、結果は異なる可能性がある。また、SSIMやPSNRといった客観的な品質指標は、必ずしも人間の「見た目の良さ」と完全に一致するわけではない点も考慮する必要がある。

結論として、動画エンコードでは、ファイルサイズを基準にする-b:vではなく、品質を基準にする-crfで設定を調整することが推奨される。また、エンコード速度と圧縮効率のバランスをとる-presetは、動画の複雑さやマシンの性能に応じてveryfastかmediumを選ぶのが効果的で、slowはほとんどの場合でメリットが少ない。そして、映像だけでなく、音声トラックのファイルサイズも全体の容量に大きく影響することを忘れてはならない。これらの知見は、システムエンジニアが動画処理の最適化を考える上で非常に役立つだろう。