ニコニコ動画のH.264対応に関するメモ。
手許には妥当な素材～公衆送信可能化権に掛からないものが無く、実のところニコ動もヨウツベもすてろくもデイリーモーションもほとんど見ないのですが、もしかしたらこの点をクリアにするかもしれない存在が現れつつあるので、ちまちまとメモってます。てゆうか、随分長くHTMLとCSSに手間取ったんで、リハビリっす（IE6め！）。
■公式アナウンス
2008年03月05日 ニコニコニュース‐【SP1】H.264、800kbps、容量アップ -SMILEVIDEO の新機能- の要約、およびメモ。
■**推奨**ってナニ？もしかしてHigh Profile行けるんちゃうか？
■H.264/AVCのプロファイル※Highは「Mainの悪評」に応えて追加された。
カスタム量子化マトリクスと8x8サイズブロックは、Xvidなど前世代のMPEG-4
ASPでも使えたもの。Mainは新技術に頼り過ぎてバランスが悪くなってしまったのかもしんない。オープンソースのx264はとことんHighに対応し、いまやSD解像度でも
Highで作った方が縮むし奇麗という変態さんになっている。Apple
はMainに留まっているので、HD画質に不安アリ。Apple自身もそう見ている可能性アリ（後述）。
※「MPEG-2の２倍の圧縮率」は、ケースバイケース。
この決まり文句は、試作コデックH.26Lのテスト結果を指すと思われる（後述）。時期的に見てMain相当。
■x264 VS. Other
※実はニコ動クラス（Vmax700, 512x384）て両者の中間的な領域なのじゃまいか。もしかしてNeroやMainconcept（現 Divx）が総合チャンプ獲れたりしないかとも思うのだけど、PPCマカなので手は出ません。
巷間流布しているVFRの作り方に原因があるかもしれない。作り方が多彩でありすぎる場合、どこにどんなハックが仕込んであるか解らないので、公式サポートは謳いにくい（cf. MPEG-4ASP.AVI ）。企業としては用心深い書き方をしとくのが無難だろう。ただしこの書き方は、サポートされる作成手法もあると言う事。実のところ、動き補償系のインタレ解除で30fps固定にしちゃって複数参照をウマく使えば、VFR要らんつう気もするんだが。
データの細かいディテイルをごまかす。「ごまかしかた」が人気の秘訣。
ロック・ポップス等に向く。こういう曲（"音域がせまい"と言うらしい）では「データの細かいディテイル」は、ほぼ「雑音」に相当する。ジャズ、クラシック等は不向き。いろんな楽器がいろんな音出すから（"音域がひろい"と言うらしい）。各楽器のびみょ～な音色とか言いだすと「こまけぇな」とごまかす。したがって「静止画＋オーケストラ」で「クラシックっていいものなのだぜ？」とやりたい人とかは、AAC-LCの方が向いてるのかもしんない。
元々の目標が「48kbpsでCD音質」なので、ビットレートを与えても音質向上を実感しにくいらしい。また高音域の音が単調だと、 ノイズが聞こえる事があるとか。
むつかしく言うと：
実は人間のセンサーはすっげぇショボいのだけど、脳内データベースが補間しちゃうのではないかといわれている。例えば網膜は100万画素しかないらしいが、もうちょっと見えてる気がする。耳を研究して「ここから先は聴こえません。だからCDとレコードは同じです」と決めても、クラシックファンがぶいぶい言うのは、そのへんかもしれない （cf. 画質の構成要素その１「視覚の個人差」 - 2006/07/31 ageha was here）。
とか言って手許ではHE-AAC使った事ないです。マカだしPPCだしネロデジタル動かないし。ちなみにHE-AAC非対応プレイヤは「こまかくないぶぶん」つまりAAC-LC部分だけ再生する。手許のFirefoxで聴こ えてんのがちゃんとしたHEなのか差分抜きの超低ビットレートLCなのかは、わかりません。
ちなみに着うたは、全部HE。
一応、オールラウンド？
ちなみにiTunes Storeで買えるのは全部LC。ようつべのH.264版もこっちのもより。
公称サイズよりやや余裕あるかも。なぶら投資帖 | ドワンゴ(3715) ニコニコ動画(SP1) によると、今回発表された機能追加群は全て鯖負荷軽減に繋がるとの事。ニコニコは国内トラフィックの十分の一とか、なんかそのくらいスゴい渋滞になってるらしいので、控えめにするとそっち方面の風当たりが減殺するかもしれない。とくにアニメのように落差の激しい映像は、平均ビットレートはむしろ低くして、ピークレートの触れ幅を大きく取るほうが画質を実感し易いとも言う。
「H.264やVC-1のように、コーデックに十分な実力がある場合、全体のビットレートをとにかく高くしてもさほど効果はないようです。むしろ画質を向上させるために重要なのは、アベレージを低くして、難しいシーンに、エンコーダがピークのビットレートを十分な帯域で割り当てられるようにした方が、画質が向上する。今回も、平均ビットレートは低いものの、ピークレートには24Mbpsくらい割り当てています」と大塚氏は説明する。
西田宗千佳のRandomTracking 「狙うは最初から究極」。FREEDOM/パトレイバーから見る「アニメ向けHD DVDオーサリング」の秘密 - 2007年2月15日
512x384で作るのが一般的なようなので、BPP=0.10になるのは590kbps (fps30)。SAR=1:1でダラ見ならそれで十分ダロてゆうか毎秒590万画素で700て随分余裕あるなヲイ（委細後述）。
＊＊＊
■ビットレートとBPP（Bits Per Pixel）
まず始めに「画質」とは（＊次の句読点まで一息に＊）、fps と解像度とビットレートと映像内容とデコーダの性能とOSの動画インフラとモニタドライバの出来と周囲の明るさとモニタの物理サイズと応答速度と色彩再現性と個人の視力と動体視力と色覚と視距離と最後に感性、のバランスで決まる。コレは式にできない。計測出来ない。確かなものがなんにもない。
しかし、H.264/AVCのプロトタイプ（H.26L）は720x480@1Mbpsで、"素材と見分けがつかない"という評価を出している。時期やサイズからみて、現在のMain Profileに相当すると思われる。このテストはJVT発足以前、おそらくは2000～2002年頃にMPEGが行ったもので、「標準画像」と呼ばれる一連のテスト素材をエンコしてブラインド・テストにかけて統計学的な手法で客観性を加えたものだ（改訂版 H.264/AVC 教科書 (インプレス標準教科書シリーズ)
同じ頃、世間ではエンコ厨というものが増えつつアリ、その筋では MPEG-4 ASPがちと熱かった。現在のlibavcodec MPEG-4, Divx, そしてXvid。当時MEncoderのメーリングリストでは、BPPというものが「画質の目安」に使われていたようだ。BPPが「いくつなら良い/悪い」というのは、エンコ厨の経験則から来た目安に過ぎず、特にオープンソースではコデックの進化でずんすん下がっていくので2008初春現在、もはや画質指標としては使われていない。
手許ではこのBPPと２節の実験結果を勝手に混ぜてビットレートを決め打ちにしている。その範囲 でできるだけ画質がよくなる設定を見つけましょうという、なんだろ。趣味？
スペルはBits Per Pixel。意味は1ピクセルあたりのbit数。式は bpp
= vbitrate *
1000 / (width * height * fps)。
これで、解像度やfpsが全然違っても、大雑把に画質の予想がつく。他人様の設定読むときとかちょっと便利。またbitrate弄るか！って時の目安にもなる。要するに解像度とfpsとbitrateでできた式だから、その三つの比較や調整に関しては、少しだけ合理的になれる、、、と思う。
H26Lの720x480（30fps）@ 1Mbpsは、BPP0.10に相当する。 x264で 512x384（30fps） を作る場合はこうなる。
| [2] | BPP | Vbitrate(kbps) | 備考 |
|---|---|---|---|
| ↑ 画 質 良 画 質 不 良 ↓ |
0.15 | 883.85 | 512x384@29.97fps[1] |
| 0.14 | 824.93 | 〃 | |
| 0.13 | 766.01 | 〃 | |
| 0.12 | 707.08 | 〃 | |
| 0.11 | 648.16 | 〃 | |
| 0.10 | 589.23 | 〃 | |
| 0.09 | 530.31 | 〃 | |
| 0.08 | 471.39 | 〃 | |
| 0.07 | 412.46 | 〃 | |
| 0.06 | 353.54 | 〃 | |
| 0.05 | 294.62 | 〃 | |
| 0.04 | 235.69 | 〃 | |
| [1]
30000/1001で計算。便宜的に30fpsとも言う。 [2] あくまでも相対的なめやすに過ぎない。 |
|||
つまり 589kbps に押し込んで「素材と見分けがつく」なら x264 は試作機以下って事だ。ウソだいそんなのありえねー。劣っているのはオレの設定だ。実際にはインタレ解除とかあるから見分け付きまくるんだけど、同じビットレートでもオプション次第で画質は大きく変わるし、せっかくだからそこを目指そうと言うか、有象無象の区別無く無駄なbitはゆるさないわというか、なんだろ。悲劇ですか喜劇ですか。
その他の解像度/fpsは「BPP とは」参照。
■見つけたファイル
１）2008-03-07 - 阿川のひとりごと - ニコニコのH.264（60fps、シューティングゲームのボス戦？ぽいもの）
仮にこれが512x384@60.00fpsとすると、BPP=0.061。720kbps でも楽ではないと思われる。
60fpsだけなら複数参照をウマく使えばそう厳しくないハズだが、一こまずつ弾幕が動くとなると話が違って来る。実際に見てみると動きの無い両サイド、得点とか出る部分の文字まで潰れている（動くものがbitを喰い尽くしている）。いずれにせよ「ハイ・モーション、ハイ・ディテイル」の連続で、"bitの草苅場"が無い。
画面中央とマイシップ周辺に、縦長のおおきなブロックが頻繁に出るが、ちょっとああいうノイズは見た事が無い。元のゲーム画面にスプライト領域が出てるのか、只の通信遅延や再生遅延かは不明。有り難い事に設定が公開されている。
MeGUI 0.2.6.1044使用
映像: CE-Mainprofileベース / --bitrate 720 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1,-1 --subme 6 --trellis 2 --analyse p8x8,b8x8,i4x4,p4x4 --me umh
http://www.nicovideo.jp/watch/sm2542480（※上記のリンク先は当ブログ内）
とはいえ、どう転んでも画面が弾幕に覆われっぱなしなので「bitの草苅場」が無い。2パスのキモは動きやディテイルの少ない部分を高圧縮して、稼いだbitを動きやディテイルの多い部分に回す事、なのだが、高圧縮できそうなコマが無い。この素材では平均レートを下げても効果はあまり無いと思う。唯一動きの少ない両サイドからエリアを手動指定してでもbitを搾り取りたいところだが、空間軸zonesなんてないしなぁ。しかも背景透過したりするし。となると、
でもこれがニコ動で奇麗に見れたらスゴいよなぁ。いやニコ動的にはリソースの浪費か。
２）[H.264 画質テスト] 新海誠作品予告編 - 理性全壊の雑記帳-goodtimes & badtimes
※BPPは24.00fpsで概算。
全４分３８秒。BPP=0.065の画質を見ると上記１）の難物ぶりが解るが、コレもぜんっぜんラクな素材でわない。やたら細かい描き込みとか雪とか桜吹雪とか吐息とかそよぐ草むらとかそのへんは驚かないが、カットでパンでピントでマルチで鬼だ鬼。テレビアニメぢゃあんまり見ないが、"カメラワーク"はかなり手強い。地味なくせにbitを喰う。
まずカットはそこに正確にI/IDRを入れる必要がある。後続のP/Bが間違ったI/IDRを参照すると、クソデカイクセに画質の悪いコマが続いてしまう。特に短いスパンでぽんぽんカットが入る箇所でI/IDRをミスったx264はXvidにも劣る。→ --scenecut上げ、--min-keyint下げ。
この調整はBPPを下げるほど厳しくなってく。もしかしたらこのひとI/IDRの挿入位置確認しながら設定弄ってる。ffdshowとかそういう再生オプションがあるらしい。だがそれでも３番はシーン切り替え時に若干のブロックが出ている所がある（たぶんこれが原因）。Apple-H264ではまず起きないので、自動マルチパスでフレームタイプ判定をとことんやるのだと思う。
次にカメラさんが「きゅいっ」とボケからクリアにピント合わせるみたいなとこは「はいみなさんここに視線集中！このスピードで」って意味。なので、ボケ具合もその収束速度もびしっと素材通りでないとマズい。そこでコマ毎のQP変動幅が不足だったりすると作り手の意図がぐだぐだになる。→ --qpstep上げる。
パンはどんなに低速でも画面内の全ピクセルに差分情報が発生する。ゆっくり、つまり一コマ毎にピクセルが移動する距離が短ければ短いほど、動き予測とモーションベクトルの算出精度が重要。 → --me、 --submeなど。
全て3パスを掛けているが、これは1st passで十分な精度のビットレート統計が得られない場合に効く。目安は1000フレーム以下、23.976fpsなら40秒程度のハズだが、この動画は４分余ある。この判断の根拠推測できない。やっべーリハビリだー。
実はこのへんの低ビットレート域になると、ビットレートと画質スライダ程度の設定だけでデブロックやパス数を勝手に調停してくれるApple-H.264が俄然強い。Apple-H.264はストリーミング、iChat、iPodを主目的に含めているのに対し、x264はDVDバックアップ以外はほぼ眼中に無い為。
自分の視覚では、手許のBPP=0.1に最も近い3番が一番馴染んだが、書いてる間にエコノミー（？）なるものに入ったようで（なんだかよくわかってない、オレが何回も見たせいだったらごめんなさい）、表示画質が著しく劣化している。せっかく気合いを入れてもこうなってはbitの無駄だ。ん～もったいない（矢沢永吉っぽく）。
＊＊＊
もちろん、絶対的な画質はBPPが高いほど良いが、それではbitがいくらあっても足りない。趣味的には光学ディスクに追い出したり、ぽんぽんHDを買い足すと後が面倒、ってゆうか無くすので。「bitで画質を稼ぐ」方向はカベにブチ当たる。「モノ」の限界はすぐくるが、ソフト（知恵）はそうでもない。
動画共有サービスのカベは通信遅延や鯖の負荷、トラフィック、最後は、ネットインフラ方面からのニコ動ワルモノ論だ。隙は少ないに越した事はない。
ええ、待ってますよ。角川デジックスがニコニコと組むのを。うっぷして、権利者の審査通過すりゃ、その広告費が直に製作者（著作利権者）に回るってのは、今よりはマシに見えるから。繰り返し何度も再生されるのが良いサクヒン！シチョーリツよりそっちが儲かる！って事になりゃ、それを作るのが良いクリエイタ、って事になりますから。ちったぁそういう制作者（価値の創造者）の取り分が増えそうです。現状ぢゃ何をどうやっても作り手にカネが回らないからね。