完成形に達したと思っていたffmpegによるmp4エンコードだが、今頃なってbオプションで指定した5Mbpsに遠く及ばない1~2Mbps程度になっている事に気付いた。
CRF | 1280x720p | 720x480p | ||||
---|---|---|---|---|---|---|
rate (kbps) | Size (MB) | Time(s) | rate (kbps) | Size (MB) | Time(s) | |
15 | 7966 | 84 | 645 | 3860 | 41 | 210 |
16 | 7349 | 77 | 629 | 3419 | 37 | 204 |
17 | 6639 | 70 | 605 | 3032 | 33 | 199 |
18 | 5826 | 61 | 576 | 2693 | 29 | 189 |
19 | 5100 | 54 | 552 | 2399 | 26 | 184 |
20 | 4470 | 47 | 527 | 2142 | 24 | 180 |
21 | 3923 | 42 | 504 | 1915 | 21 | 173 |
22 | 3453 | 37 | 487 | 1715 | 19 | 170 |
23 | 3051 | 33 | 465 | 1541 | 17 | 164 |
24 | 2709 | 29 | 452 | 1388 | 16 | 160 |
25 | 2415 | 26 | 436 | 1252 | 14 | 158 |
なんてこったい。Intel Media SDKどころの話では無く、我ながらうっかりにも程があるというものだ。
改めて調べてみるとx264の場合、ビットレートはCRF(Constant Rate Factor)によってコントロールするのが筋で、bオプションは無効らしい。
突然CRFと言われても現状 /usr/local/share/ffmpeg/libx264-hq.ffpreset で "25" に設定されていた事以外はよくわからなかったものの、ググったところ0~51の設定範囲のほぼ中間値だが品質指標としては比較的低いという事なので、1~2Mbps程度になってしまったようだ。
実用的には20~22が良さそうだというのも同時に察しが付いたが、折角の機会なので自力で検証してみる事にして、85秒の動画(地デジフルHD1440x1080、MPEG2TSで260MB)をMP4エンコード(1280x720と720x480)でCRF値を15~25まで変えながら、エンコードした平均を表にしてみた。
なお、動作環境がXeon E3-1275 (8M Cache, 3.40 GHz)@gt110bとCore i3-2120 (3M Cache, 3.30 GHz)@ML110G7での各10回ずつ廻した結果(各CRFで合計20回)。動作クロックは大差無い事から処理時間もさほど変わらなかったのだが、別プロセスの負荷やストレージデバイスの反応速度などの差分もあるのであくまでも処理時間は参考程度で。
当然、品質(ビットレート)に比例して処理時間は長くファイルは大きくなるのが落とし処として難しいところなのだが、バランス的には20~22あたりが良さそうな雰囲気かな。
CRF20でエンコードした例 |
ちなみに、MediaEspressoでは1280x720サイズが6Mbpsで63MB、4Mbpsで42MB。QSVのおかげで処理時間はわずか6秒の爆速だが、じっくり見るとx264とは違って破綻が良く見られるのが残念。
【参照】
●もにっき http://tutinoko.org/blog/
┗x264のcrf値はどれくらいが適切なのか? 2010年12月25日
●いろいろwiki@princo.org http://wiki.princo.org/
┗x264エンコーディングで固定品質(qp,crf)の設定値を比較 2010年12月25日