CUDAでリサイズ

CUDA GPGPU

すでにあるのか。興味深いのでメモ。
CUDA Resizer AUF
完全にCUDAで実装されたプラグイン。
残念ながらGPU演算は縮小方向にしか使えないのと、ランタイムとは別にDLLファイルが必要（それがとても探しにくい）のが難点。
GPU リサイズフィルタ
DirectXを使ってフレームをテクスチャとして演算してるような感じのプラグイン。
CUDAを使っていないので、ATIでも使えるのが利点か。

GPUを扱うどのプラグインにも言えることだけど、処理がいくら早くても転送に時間がかかるので、相対的な時間は変わらないという話が。
よっぽど古いCPUを使わない限り、恩恵は受けられないんじゃないかと思ったが、GPUに処理を投げる分CPUが別のことをできるから、そういう意味ではメリットがあるのかな？

MPEG2-TSのAviSynthスクリプト

memo

"AVS メモ TS"に対するレスみたいなもの。
うちでは某チューナを使っているのでTSファイルが大量に出来るわけですが、それをSprusEngineで録画時間の二倍くらいの時間で処理してます。
AVSはこんな感じ。処理速度最優先。

# プラグインロード
LoadPlugin("Path\warpsharp.dll")
LoadAviUtlInputPlugin("Path\m2v.vfp", "MPEG2VIDEO")
LoadPlugin("Path\BicublinResize.dll")
LoadPlugin("Path\LeakKernelDeint.dll")

# リサイズするときの解像度
target_width = 1280
target_height = 720

# 動画読み込み
MPEG2VIDEO("MOVIE_VIDEO.m2v")
AudioDub(last, WAVSource("MOVIE_AUDIO.wav"))
ConvertToYV12(interlaced=true)

# CPUでインタレ解除
LeakKernelDeint(1)
FastBilinearResize(target_width, target_height)

# FPS変換
ChangeFPS(29.97)

return last

ネタに対抗してみた

x264

200Passに対抗しようと適当に512x384でエンコードした．
オプション付けすぎて2-passに7時間かかりました…orz
オプションはこんな感じ

--progress --min-keyint 1 --b-pyramid --bime --weightb --trellis 2
--mixed-refs --bitrate 700 --scenecut 65 --8x8dct --partitions all
--bframes 16 --direct "auto" --subme 7 --b-rdo --me "tesa" --ref 5
--deblock -1:-1 --cqm "flat" --threads 1 --no-fast-pskip --no-dct-decimate
--fgo 1 --me-prepass --min-keyint 1 --keyint 300 --merange 64

相変わらず狂気のオプション．
で，結果はこんな感じ．
===
注：あっちの数値は"800x600"でのエンコード結果なのかもしれません．
その場合，こちらの検証は無意味な物になりますのでご注意下さい（調査中）

SSIMとPSNRだけを抜き出して表にするとこんな感じ

Pass SSIM PSNR(Y) PSNR(U) PSNR(V) PSNR(Avg) PSNR(Global) Bitrate
1Pass 0.9796792 43.917 46.584 46.367 44.442 42.429 679.34
2Pass 0.9816183 44.177 46.678 46.467 44.682 43.184 700.92
参考(200Pass) 0.9820838 43.956 46.322 46.092 44.501 41.624 700.58

200PassよりもSSIMは若干低く、PSNRでは2-passの方が上回っている．
詳細なエンコード結果は以下を参照．
1-pass目:

x264 [info]: slice I:88 Avg QP:22.59 size: 5816 PSNR Mean Y:53.90 U:71.63 V:70.65 Avg:54.66 Global:48.27
x264 [info]: slice P:3576 Avg QP:23.94 size: 4600 PSNR Mean Y:44.32 U:46.43 V:46.29 Avg:44.82 Global:42.84
x264 [info]: slice B:3227 Avg QP:25.47 size: 789 PSNR Mean Y:43.20 U:46.07 V:45.79 Avg:43.75 Global:41.94
x264 [info]: mb I I16..4: 63.9% 29.2% 6.8%
x264 [info]: mb P I16..4: 6.5% 6.0% 0.8% P16..4: 46.5% 11.9% 18.2% 0.1% 0.1% skip: 9.9%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 40.0% 0.4% 1.8% direct: 1.3% skip:56.4%
x264 [info]: final ratefactor: 23.74
x264 [info]: 8x8 transform intra:42.8% inter:64.4%
x264 [info]: direct mvs spatial:98.8% temporal:1.2%
x264 [info]: ref P 74.5% 11.6% 6.9% 3.5% 3.5%
x264 [info]: ref B 83.8% 9.4% 5.3% 1.4%
x264 [info]: AQ Result Bright MB:39.30% QP Up:32.26% Down: 4.35%
x264 [info]: AQ Result Middle MB:50.85% QP Up: 5.24% Down:17.13%
x264 [info]: AQ Result Dark MB: 7.44% QP Up:33.78% Down: 3.29%
x264 [info]: AQ Result M.Dark MB: 2.40% QP Up:99.40% Down: 0.00%
x264 [info]: AQ change value 4:0.26% 3:0.48% 2:6.81% 1:12.70% 0:69.09% -1:8.32% -2:2.34%
x264 [info]: SSIM Mean Y:0.9796792
x264 [info]: PSNR Mean Y:43.917 U:46.584 V:46.367 Avg:44.442 Global:42.429 kb/s:679.34
encoded 6891 frames, 0.43 fps, 679.49 kb/s

2-pass目:

x264 [info]: slice I:88 Avg QP:21.86 size: 5765 PSNR Mean Y:53.93 U:71.86 V:70.85 Avg:54.78 Global:48.77
x264 [info]: slice P:3576 Avg QP:24.07 size: 4674 PSNR Mean Y:44.38 U:46.40 V:46.25 Avg:44.86 Global:43.55
x264 [info]: slice B:3227 Avg QP:24.59 size: 900 PSNR Mean Y:43.68 U:46.30 V:46.04 Avg:44.21 Global:42.74
x264 [info]: mb I I16..4: 63.0% 29.8% 7.2%
x264 [info]: mb P I16..4: 7.0% 5.9% 0.8% P16..4: 44.0% 11.7% 18.3% 0.2% 0.1% skip:12.1%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 41.9% 0.4% 2.1% direct: 1.5% skip:54.0%
x264 [info]: 8x8 transform intra:40.9% inter:64.4%
x264 [info]: direct mvs spatial:83.9% temporal:16.1%
x264 [info]: ref P 73.5% 11.8% 7.3% 3.6% 3.8%
x264 [info]: ref B 81.7% 11.0% 5.6% 1.7%
x264 [info]: AQ Result Bright MB:38.94% QP Up:31.37% Down: 4.45%
x264 [info]: AQ Result Middle MB:51.12% QP Up: 5.04% Down:17.32%
x264 [info]: AQ Result Dark MB: 7.51% QP Up:33.46% Down: 3.32%
x264 [info]: AQ Result M.Dark MB: 2.43% QP Up:99.39% Down: 0.00%
x264 [info]: AQ change value 4:0.26% 3:0.47% 2:6.27% 1:12.73% 0:69.44% -1:8.45% -2:2.38%
x264 [info]: SSIM Mean Y:0.9816183
x264 [info]: PSNR Mean Y:44.177 U:46.678 V:46.467 Avg:44.682 Global:43.184 kb/s:700.92
encoded 6891 frames, 0.65 fps, 701.07 kb/s

200pass

x264

うーん、完全にネタとしか言いようがない。
つっこみは箱Pが入れてるみたいなんで僕は適当にフォローに回ります。
ログのスクリーンショットを見る限り197Pass目からのSSIM/PSNRは抽出できるので手始めにしてみることにする。

PASS数 PSNR(Y) PSNR(U) PSNR(V) PSNR(Avg) PSNR(Global) SSIM ビットレート
197 43.956 46.235 46.095 44.501 41.629 0.9820936 700.59
198 43.957 46.323 46.099 44.502 41.630 0.9820884 700.57
199 43.954 46.318 46.102 44.500 41.626 0.9820942 700.75
200 43.956 46.322 46.092 44.501 41.624 0.9820838 700.58

…当然のことながらあまり変わらないようだ。
一方、エンコード結果とソースには大きな違いが出ている。
(キャプチャ画像は様々な都合上元動画のリンクから拾っていただければ…)
MPEGソース側は著しいブロックノイズが出ている一方、200Passの動画の方はブロックノイズが消されて少しぼやけて見える。
一番目立って見えたのは001.PNGのクドリャフカの帽子のボタン部分である。
これはおそらく、H.264デブロックフィルタのせいとも考えられるが、マルチパスによる影響もなきにしもあらずと私は考えている。*1
で、ソースについて。
箱Pのエントリから引用。

リトバスEXを検索してみたら、デモ動画は公開されてないんだね。
高画質実験と銘打つなら入手しやすい動画を使ったほうが、他の人が追試しやすくていい。
敢えてリトルバスターズエクスタシーを使う意味が分からない。
デモ動画は高画質で、かつ入手しやすいからエンコード実験に使われることが多い。
入手しにくいデモ動画は実験に向かない。

このように記載されてるようですが普通に入手できました。*2
ただ、MPEG系って結構デコーダによる誤差が出やすいと思ったりしなくもないんだけど、どうなんだろう？*3

*1:どこかのサイトにマルチパスをしすぎるとアーティファクトが発生すると聞いたことがあったような…

*2:念のため18禁注意:リトルバスターズEXデモムービー

*3:デモ動画を再生してみてもスクリーンショットみたいにブロックノイズで破綻してない。

ニコニコ動画モバイルの仕様

ニコニコ動画

ここ最近箱Pがx264に関する非常に興味深いデータをあげてくれている。*1
とりあえず今回はこのエントリのこの節について。

Baseline Profileではビデオ会議や携帯端末を想定する。
ニコニコ動画向けには、HDを想定したHigh Profileでないとダメとは言わなくとも、
放送や保存再生を想定したMain Profileでいいと思うんだけど、うーん、ニコニコモバイルはよく知らないんだよなあ。

以下見苦しい文が続くのでさらっと書いてしまうと「モバイル端末については一切考慮しなくて良い」という結論になる。
元々ニコニコ動画モバイルはドワンゴのパケットラジオをベースに作ってあると考えられ、
内部の仕組みはJPG画像を高速に切り替えて、音声を同期させているだけにすぎない。*2
このため、MP4ファイルからJPGへのトランスコードはニコニコ動画側の変換サーバで実行されるのでx264デコードの負荷は考える必要が無いと言えるだろう。
ただし、ニコニコ動画モバイルでの解像度は320x240以下に変換されるので画質の面では残念なことになってしまう。*3
このため、VGA対応携帯などを所有していて高画質で見たいと思う人はコメントを諦めて自分で携帯向けにトランスコードするのでこれも考えなくて良い。

*1:どれくらいかというと私はいらないんじゃないかと思うほど（笑

*2:内部の詳しい仕様については中の人が講演で話したりしている。ニコニコ動画でも公開されているので、音声付きで見たい方はこちらをお勧めする

*3:VGA対応機種でもスケーリングが行われるが汚いので以下略

THE IDOLM@STER WAKAMURA RECYCLE VOL.02に見る長時間ニコマス動画のエンコポイント (2)

x264

ずいぶん間が空いてしまいましたが，とりあえず考察続行．
前回に引き続き，エンコードのときのポイントに移りたいと思います．
まずニコニコ動画にアップロードする場合，長時間の動画になってしまうとたいていの場合には容量限界が先に来てしまいます．
そのため，1kbps単位を重要にすることがさらに要求されてしまいます．
で，ソース時点でやることとしてはノイズは極力減らし，レベル補正を行って色分布の間引きをしておきます．
次にエンコード段階についてですが，通常のエンコードに加えて，とりあえず以下のオプションを使ってみてはいかがでしょうか．
・submeは7くらい．(--subme 7)
・trellisオプションも常に有効に（--trellis 2)
・Bフレームを10フレくらいにして使う (--bframes 10)
・IDR間隔を10秒くらいに広げる（--keyint　300）
・AQを弄る（--aq-mode 3，ソースに応じて--aq-strengthの調節）
パス数については，2PASSか3PASSくらいで十分だと思います．
ただ，殆どが推測で書いているので，実際の場合にはどうなるかまだ検証しておりませんので，
間違っている/ここはこうした方がいいというところが有れば是非匿名で構いませんので突っ込みを．

#Zoome版が公開されたので，そっちのほうをソースにして見ていたりします．
#Zoome版は容量制限なし，映像ビットレートが1.3Mbpsっぽい感じです．
#もしかすると，Zoome版をソースにしてエンコード実験をするかもしれませんが…