8/18から、ニコ動で投稿可能なファイルサイズが緩和されたのだが、この仕様がいろいろ残念。
再エンコ回避ができるのかどうかについては、100MB以下ならOKという話と、100MB以下でも問答無用で再エンコされるという話があって、よくわからないことになっている。まあそもそもは公式にこういう情報を出さないからいけないのだが…。やっとのことですこし情報が出たけど、
必ずサーバー側で再エンコがかかるとのこと。
再エンコされると強制的に1280x720にリサイズし、それを2000kbpsでエンコードするらしい(これが上限で、それ以下の画質も用意されるらしいがそんなもんに興味はない)。なんというか、720pで2000kbpsって足りないんじゃないの、という気がするのだけど。というか、fullHDでアップロードしてもfullHDでは残さないんですかね…。
わたしはIDが対象外なのでuploadしてテストとかはできないのだけど、実際にテストしてくださっている方がいるので、そのファイルを見て、再エンコの状態を確認した。
854x480 再エンコなし sm29420582ビットレート分布
GOP長最大: 300
平均: 255.3
標準偏差: 81.76
かなり激しくビットレートが変動している。100MB以下で再エンコが回避され、適切なビットレート配分が行われているのかな、という感じ。また平均GOP長も長く、標準偏差も大きいということで、動的なキーフレーム挿入も行われていて(可変長GOP)、圧縮率が高い動画となっていることがわかる。
1280x720 再エンコ sm294723341280x720 5.3Mbps 496MBの動画が、1280x720 2Mbpsに変換されてしまっており、画質が低下してしまっていることが分かる。
ビットレート分布
GOP長 ※最終GOP除く
最大: 30
平均: 30.0
標準偏差: 0.0
動画情報 (MediaInfo)プロファイル : Main@L3.2
CABAC : はい
RefFrames : 4 フレーム
まずビットレート分布から。うーん、ある程度ビットレートが変動していて、それでも平均2Mbpsに合わせてきてるってことは、一応2passなのかなあ…。
とはいえ、sm29420582と比べるとビットレートの変動はかなり抑えられてしまい、必要な箇所にビットレートを割り振れていないかも、という気がする。例えばsm29420582ではほとんどビットレートが割り当てられていないところにもsm29472334では無駄に割り当てが行われている…。
原因はたぶんGOP長にあって、GOP長が短いため(なんとキーフレームを1秒に1回必ず入れてる…)、静止画部分でもビットレートを必要としてしまったのかな、という感じ。おそらくシークをしやすくするためなんだろうけど、にしても毎秒キーフレームを入れると圧縮率にわりと影響しそう。まあビットレートが十分ならそれでもいいのだけど、720pで2Mbpsなので、十分とは言えない気がする。
また一般的に多少圧縮率の向上する(はずの)可変長GOPでないのは謎。
あとは、H.264 Main Profileなので、High Profileで有効な機能(8x8 整数dct)とかは使われてないのかなーとか。
まあ、そんなこんなで以前よりはビットレートが増えた分ましとはいえ、やはりサーバーエンコはサーバー負荷低減のため軽めな設定なのだろうし、期待しないほうがよさそうな感じ。
今回、ファイルのuploadサイズの上限を拡大したといっても、結局サーバー側でつぶしてしまうことが前提なのだとすると、そこになんの意味があるのか正直よくわからない。100MB制限を撤廃した風に言ってるけど、尺の短い動画(6分40秒以下)では再エンコすることで100MBを下回れることから、尺の短い動画が相対的に多い中で、サーバー側の動画容量の削減をしたいのだとしか思えない。
まあ、100MB以下でも再エンコ食らい、今後新エンコード方式の対象者が広がっていくのだとすると、ニコ動は静止画動画以外は残念な画質ばかりになるのだろうし、ニコ動用にx264guiExを使う必要はもうなくなるような気がする。
関連記事
ニコ動の新しい動画エンコード方式について その2 (サーバー側エンコード調査)
ニコ動の新しい動画エンコード方式について その3 (今後、投稿動画はどうするべきか)
スポンサーサイト
