検証

前回、また検証しようといっていた通り、簡単に検証してきたので、結果を写真を交えて公開。

エンコードする動画は某対戦アクションのリプレイを4GB分撮影したものを使用。
というのも、Frapsの仕様で、容量が4GBになるごとに動画を分割して保存されるため。
時間にして2分4秒ほど。フレームは60フレーム。ニコ動に出してるものと同じとご想像願う。

比較したコーデックは件のCUDAと、普段、ニコニコ動画用動画を作成するのに使うx264。

さて、では検証した順番に時間と容量と画質を示していこう。

まずはニコニコ動画用とほぼ同じレベルのものから。

x264によるTwo-passで、bitは画像については1000k、音声については40k。
圧縮時間は238秒。出来上がった動画の容量は15.5MB。

出来上がった動画を再生して、これまたFrapsでjpeg形式で保存。

するとこうなる。記事内に写っているのは全部小さいが、クリックで元の大きさの写真へ。



ちなみに、jpegで保存するとこれまた元より画質が悪くなる。
といっても、ほんの少しだが、見比べると汚さが判る。記事上では判らないが。

さてお次はBitrate-based。bitは上記と同じものが影響するので、同じ調整を使用。
Quality-basedだと、1から100までの品質設定というものになるということにご注意を。

では結果を。時間は150秒、出来た動画の容量は15.7MB。
画像は以下に。



まったく同じシーンでないのはご愛嬌。画質の比較が出来れば問題ないので。

x264の最後はQuality-basedでのエンコード。品質設定は最低の1にしてある。

時間は141秒。出来上がった動画の容量は6.3MB。
これは下げすぎたような気もするが、x264でのコレはおまけなので。
画像は以下に。



この写真はわざと動き回っているところを撮影してブロックノイズの多さを強調したが
動いていなくても背景がモザイクがかったようになるほど潰れている。

最初と二番目の結果と同じ容量になるように調整するとどうなるかは少し興味があるところ。

さて、ここからCUDAの出番となる。

まずはBitrate-basedを既出のbit調整でエンコードした結果。

時間は131秒。出来た動画の容量は17.6MB。
画像は以下に。



x264で同じことをしたときより少し時間が早く、代わりにほんの少し容量が増える。
きっと画質がよくなったのだろう、ということではなかった。
画像真ん中ぐらいに線が見える。再生中もずっと映り続けていたものだ。

さて最後にQuality-basedでの結果。
時間は154秒。出来た動画の容量は133.9MB。
気になったので品質設定を50まで上げてみたところ、同じ容量になった。
画像は以下に。



ほぼ撮影したものと同じようなレベルになった。jpeg保存でようやく少しぼやけた部分が出た程度。
全体にいえることだが、鮮やかさが足りない。普段と処理の手順が違うためだと思われる。
CUDAはこのQuality-based専用のコーデックだといえそうだ。だが、そのレベルは高いと思われる。

が、今のところニコニコ動画で容量とbitrateを悩みながら動画上げる分には意味がない。

検証は手早く済んだが、書くのに手間取ったようで。では、また。