ニコ動の新しい動画エンコード方式について その2

もうすこしいろいろわかってきた & 調べた。

関連記事
ニコ動の新しい動画エンコード方式について その1 (ビットレート分布調査)
ニコ動の新しい動画エンコード方式について その3 (今後、投稿動画はどうするべきか)

どうやら、新しいエンコード方式は以下のようなことがわかってきているらしい。

・公式には「1.5GBへuploadサイズを拡張」「HTML5プレーヤーへの布石」とされている
・必ずサーバー側でエンコードされる。
・動画の長さにより4段階にエンコードされる。
~15分  720p, 2Mbps
~30分  540p, 1Mbps
~60分  360p, 600kbps
それ以上 360p, 300kbps
・最大で60fps。
・音声は最大で192kbps、48kHzは44.1kHzに変換される。

つまり、グラフにするとこんな感じだ。100MBの場合は音声は192kbpsとして計算してある。
nicoenc_new201608_01.png

問題なのは、かならず720p以下にされてしまうということと、おおむね6分15秒以下の動画については、これまでより割り当てられるビットレートが減ってしまうということ。もちろんビットレートが減るだけでなく、サーバー側での画一的なエンコードが行われるため、つんでれんこによるエンコードよりも画質が低下するのは間違いないだろう。

一方で、6分15秒を超える動画については、従来よりは割り当てビットレートが増えるし、ファイルサイズも100MBを超える。ファイルサイズのほうをグラフでみるとこんな感じ。

nicoenc_new201608_02.png

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構造を見てみると、例えば以下のようになっている。
nicoenc_new201608_03.png

ざっと見てみたが、どうやら連続Bフレームは最大でも3と、やや控えめな感じ。フレームタイプの決定はP,Bフレームについては適応的に行われていて、例えば静止画のようなPフレームのほうが有利な箇所ではほとんどがPフレームとなっていた。

マクロブロックの確認
たとえば、sm29472334の12フレーム目を確認してみる。以下はその中央部分を抜き出したもの(全体を見たい方はクリックで拡大してください)。
nicoenc_new201608_06_nicoenc.png

マクロブロックを確認。以下はさっきと同じ箇所を抜き出したもの。

(全体を見たい方はクリックで拡大してください)
nicoenc_new201608_04_nicoenc.png
↑sm29472334(サーバー側エンコ)のブロック構造

赤がイントラブロック、緑・青がインターブロック。ここは車載動画の部分なので、標識は大きく移動してきていて、動き予測が効かないことからイントラブロックとしている一方、それ以外の部分は動き予測が効くのでインターブロックとして符号化されているのだろう。

このsm29472334を再度x264guiExのニコ動用設定でエンコードして、同じフレーム(12フレーム目)のブロックの様子を確認してみた。ソースが違うので厳密な比較ではないが、参考にはなるだろう。

(全体を見たい方はクリックで拡大してください)
nicoenc_new201608_05_x264guiEx.png
↑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 (今後、投稿動画はどうするべきか)


スポンサーサイト

コメントの投稿

非公開コメント

No title

6分15秒以下の動画はこちらの動画のように、長さに応じたサイズに圧縮されてしまうのですね・・。(sm29477779:34.6MB)
外部ツールを使うと95MBのmp4がダウンロードできますが、こちらはブラウザからは再生できません。
対象者でも動画サイズを100MB以下に抑えた場合、再エンコを免れたファイルは一応残っているようですね。

静止画で尺を埋めて15分に近づけるのは良い方法ですね、ちょっと試してみようと思います。

No title

いつもソフトを利用させていただいております。多謝。
検証お疲れ様です。

ニコニコ初期からのユーザですが、エコノミーモードが導入以来の仕様変更でしょうか。
HTML5やモバイルに配慮した仕様なのでしょうが、生ファイルが公開されないのは寂しい限りです。

初期の頃はGPU再生支援がなかったので、CPU負荷の軽いVP6の動画を上げてましたが、もうそういうのも出来なくなるんですね。
たしか、当時のFlashの仕様か何かに、H.264だとPentium4の2.4GHz以上でとか推奨が書かれていた気がします。
大学で動画サイトのデモをやるときに、発表用のノートがPentium3世代のCeleronで難儀しました。

このままだと、画質面ではYouTubeに勝てないでしょうから、エコノミー回避みたいな抜け道が見つからないですかねえ。

Re: No title

ああ、たしかに昔は再生負荷軽減も重要でしたね。その次は動画再生支援で破綻しない設定の調査とか、いろいろやった記憶があります。

flashは次第に収束に向かっていて、HTML5対応が重要なのは理解できますが、もう少しよい方法がなかったのかな…という気がします。(HTML5の動画再生に詳しくないので、結構難しいことなのかもしれませんが…)

動画 エンコード

詳しいです!

大変勉強になりました。

シェアありがとうございます!
プロフィール

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先(@を半角にしてください!)
rigaya34589@live.jp
github

最新記事
最新コメント
カテゴリ
月別アーカイブ
カウンター
検索フォーム
いろいろ
公開中のAviutlプラグインとかのダウンロード

○Aviutlプラグイン
x264guiEx 2.xx (ミラー)
- x264を使用したH264出力
- x264guiExの導入>
- x264.exeはこちら>

x265guiEx (ミラー)
- x265を使用したH.265/HEVC出力
- x265.exeはこちら>

QSVEnc + QSVEncC (ミラー)
- QuickSyncVideoによるH264出力
- QSVEncCはコマンドライン版
- QSVEncC 導入/使用方法>
- QSVEncCオプション一覧>

NVEnc + NVEncC (ミラー)
- NVIDIAのNVEncによるH264出力
- NVEncCオプション一覧>

VCEEnc + VCEEncC (ミラー)
- AMDのVCEによるH.264出力

ffmpegOut (ミラー)
- ffmpeg/avconvを使用した出力

自動フィールドシフト (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: aji様

エッジレベル調整MT (ミラー)
- エッジレベル調整の並列化/高速化
- SSE2~AVX対応
- オリジナル: まじぽか太郎様

バンディング低減MT (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: まじぽか太郎様

PMD_MT (ミラー)
- SSE2~FMA3による高速化版
- オリジナル: スレ48≫989氏

透過性ロゴ (ミラー)
- SSE2~FMA3によるSIMD版
- オリジナル: MakKi氏

AviutlColor (ミラー)
- BT.2020nc向け色変換プラグイン
- BT.709/BT.601向けも同梱

○その他
x264afs (ミラー)
- x264のafs対応版

aui_indexer (ミラー使い方>)
- lsmashinput.aui/m2v.auiの
 インデックス事前・一括生成

auc_export (ミラー使い方>)
- Aviutl Controlの
 エクスポートプラグイン版
 エクスポートをコマンドから

aup_reseter (ミラー)
- aupプロジェクトファイルの
 終了フラグを一括リセット

CheckBitrate (ミラー, 使い方, ソース)
- ビットレート分布の分析(HEVC対応)

チャプター変換 (ミラー使い方>)
- nero/appleチャプター形式変換

エッジレベル調整 (avisynth)
- Avisynth用エッジレベル調整

メモリ・キャッシュ速度測定
- スレッド数を変えて測定

○ビルドしたものとか
L-SMASH (ミラー)
x264 (ミラー)
x265 (ミラー)

○その他
サンプル動画
その他

○読みもの (ミラー)
Aviutl/x264guiExの色変換
動画関連ダウンロードリンク集
簡易インストーラの概要

○更新停止・公開終了
改造版x264gui
x264guiEx 0.xx
RSSリンクの表示
リンク
QRコード
QR