どうやら、新しいエンコード方式は以下のようなことがわかってきているらしい。
・公式には「1.5GBへuploadサイズを拡張」「HTML5プレーヤーへの布石」とされている
・必ずサーバー側でエンコードされる。
・動画の長さにより4段階にエンコードされる。
～15分 720p, 2Mbps
～30分 540p, 1Mbps
～60分 360p, 600kbps
それ以上 360p, 300kbps
・最大で60fps。
・音声は最大で192kbps、48kHzは44.1kHzに変換される。
つまり、グラフにするとこんな感じだ。100MBの場合は音声は192kbpsとして計算してある。
問題なのは、かならず720p以下にされてしまうということと、おおむね6分15秒以下の動画については、これまでより割り当てられるビットレートが減ってしまうということ。もちろんビットレートが減るだけでなく、サーバー側での画一的なエンコードが行われるため、つんでれんこによるエンコードよりも画質が低下するのは間違いないだろう。
一方で、6分15秒を超える動画については、従来よりは割り当てビットレートが増えるし、ファイルサイズも100MBを超える。ファイルサイズのほうをグラフでみるとこんな感じ。
15分のところでは240MB程度まで引っ張れることが分かる。長時間動画は新方式のほうが恩恵があるかもしれない。
ただ、もちろん実況動画などは長時間の動画が多いだろうけど、ニコ動全体で見れば「6分以下の短時間の動画」というのが圧倒的に多いことが予想される中で、やはりこれらの動画を圧縮して帯域を削減したいのではないかと思えてしまう。
次に、720p 2Mbpsのサーバー側のエンコードをもう少し確認してみた。
昨日使わせていただいた動画をチェック。(
sm29472334)
1280x720 5.3Mbps 496MBの動画が、1280x720 2Mbpsに変換されている。
H.264ヘッダーの確認
Nal length 26 start code 4 bytes
ref 3 type 7 Sequence parameter set
profile: 77
constaint_set0_flag: 0
constaint_set1_flag: 1
constaint_set2_flag: 0
constaint_set3_flag: 0
level_idc: 32
seq parameter set id: 0
log2_max_frame_num_minus4: 0
pic_order_cnt_type: 0
log2_max_pic_order_cnt_lsb_minus4: 2
num_ref_frames: 4
(中略)
Nal length 9 start code 4 bytes
ref 3 type 8 Picture parameter set
pic_parameter_set_id: 0
seq_parameter_set_id: 0
entropy_coding_mode_flag: 1
pic_order_present_flag: 0
num_slice_groups_minus1: 0
num_ref_idx_l0_active_minus1: 2
num_ref_idx_l1_active_minus1: 0
weighted_pred_flag: 1
weighted_bipred_idc: 2
pic_init_qp_minus26: 4
pic_init_qs_minus26: 0
chroma_qp_index_offset: -3
deblocking_filter_control_present_flag: 1
constrained_intra_pred_flag: 0
redundant_pic_cnt_present_flag: 0
Nal length 171 start code 4 bytes
とあるので、
H.264 Main Profile @ Level 3.2
参照距離: 4
CABAC : オン
重み付きBフレーム : オン
重み付きPフレーム : オン
ピラミッド参照: オン
デブロックフィルタ : オン
8x8整数dct: オフ
という感じかなと思う。なのでひとまずMainプロファイルに含まれない8x8dctを除き、H.264の主要な機能は有効になっていることが分かる。
pic_init_qp_minus26の値から初期QP=30がわかるが、まあ初期値だけの話なのであまり参考にならない。一方、chroma_qp_index_offsetが-3なので、やや色差のQP値を下げていて、多少色差を保護しようとしていることが分かる。
GOP構造の確認どういうわけだか
30フレームの固定長GOPであるのは前回調べた通り。
GOP構造を見てみると、例えば以下のようになっている。
ざっと見てみたが、どうやら連続Bフレームは最大でも3と、やや控えめな感じ。フレームタイプの決定はP,Bフレームについては適応的に行われていて、例えば静止画のようなPフレームのほうが有利な箇所ではほとんどがPフレームとなっていた。
マクロブロックの確認たとえば、sm29472334の12フレーム目を確認してみる。以下はその中央部分を抜き出したもの(全体を見たい方はクリックで拡大してください)。
マクロブロックを確認。以下はさっきと同じ箇所を抜き出したもの。
(全体を見たい方はクリックで拡大してください)
↑sm29472334(サーバー側エンコ)のブロック構造
赤がイントラブロック、緑・青がインターブロック。ここは車載動画の部分なので、標識は大きく移動してきていて、動き予測が効かないことからイントラブロックとしている一方、それ以外の部分は動き予測が効くのでインターブロックとして符号化されているのだろう。
このsm29472334を再度x264guiExのニコ動用設定でエンコードして、同じフレーム(12フレーム目)のブロックの様子を確認してみた。ソースが違うので厳密な比較ではないが、参考にはなるだろう。
(全体を見たい方はクリックで拡大してください)
↑x264guiEx ニコ動用設定のブロック構造
これを比較すると、x264guiEx ニコ動用設定でエンコードした場合には、4x4/8x8/16x16のイントラブロックがそれぞれ使用されており、より柔軟なブロック選択が行われていることが分かる。一方、サーバー側エンコのほうは、イントラブロックで4x4ブロックが多く、8x8ブロックが使用されておらず、ブロック選択に制限があることがわかる。このようにサーバー側エンコで8x8イントラブロックが使用されないのはMainプロファイル準拠で8x8dctが使えないためと思われ、圧縮率にある程度影響すると思われる。
動き予測は?動き予測の探索もエンコード設定によって圧縮率が大きく変わる要素で、エンコード設定として重要だが、エンコード後のファイルからはよくわからない。動きベクトルとかを見ることはできるが、それを見てもよしあしはよくわからないので…。
ソースファイルがあり、かつ自分で投稿できれば、いろいろな設定でエンコードしてみたのと比較して…とかできるのだけど。IDががががが…。
実際に動画をみるとそれほど悪い画質ではないが、やはり劣化している部分があるのと、1秒おきにキーフレームがはいるので脈動ノイズのようなものが感じられることがあった。
まとめると、
新方式について・必ずサーバー側でエンコ
・最大でも720p, 60fps, 2Mbpsと厳しいエンコード
・これまで100MB以内だったら可能だったfullHDなども不可
・「6分以下の短時間の動画」では従来よりビットレートが低下
・長時間動画には恩恵あり?
新方式のエンコードについて・CABAC、デブロックフィルタ、重み付きB/Pフレーム、ピラミッド参照などの主要なH.264は有効化されており、極端に軽い設定のエンコードではない。
・P/Bフレームは適応的に挿入されている。
・Iフレームは固定間隔での挿入で、シーンチェンジによる適応的な挿入は行われていない。
・参照距離は4、連続Bフレーム数は最大3と控えめ。ただ、ここはそこまで大きな影響はなさそう。
・固定長GOPで1秒に1回キーフレームを入れるといった制約があり、ビットレート割り当ての柔軟性を損ね、圧縮率が低下しているおそれがある(
ビットレート分布参照)。
・Main Profile準拠という制約があり、High Profileの機能が使用できておらず、圧縮率が低下しているおそれがある。
・色差の保護はやや強め。
・動き予測の探索については、よくわからない。
ちょっと記事書くのに疲れたのでここまで…。
と、なんかいろいろ見てしまったが、そもそもx264guiExの設定をどうすればよいか考えるために始めたということをやっと今思い出した。サーバー側でエンコードされるなら、x264guiExはもうニコ動向けにはお払い箱か、あるいはあまり圧縮率を上げずになるべく高画質で出力する、といた感じにする以外ない。サーバー側のエンコード設定とか調べても実は意味なかったのだ (ぇ)
とりあえず、x264guiExの新方式用プロファイルは、使う人がいるかどうかはともかくとして、1.5GB上限付きのcrf=19～20あたりで適当にエンコするのがいいかなと。そしてできれば動画を720p以上でかつ15分以下にすると現状で望める範囲内ではもっともよい画質になると思う。まああとはzoomeで昔やった経験としては、短い動画なら動画終了後15分ぐらいまで静止画を貼って時間を延ばしてですね…
これまでニコ動は自分でエンコードすることで、uploadする動画の画質をコントロールできるというメリットがあったのだが、今回の変更でそのメリットは失われてしまった。今回調べたような制約がある中での720pで2Mbpsというのは、動きの多い動画にとっては十分とは言えず、MAD動画やMMD動画では、画質の残念な動画が増えていってしまうのではないかと思うと残念である。
関連記事
ニコ動の新しい動画エンコード方式について その1 (ビットレート分布調査)
ニコ動の新しい動画エンコード方式について その3 (今後、投稿動画はどうするべきか)
