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

8/18から、ニコ動で投稿可能なファイルサイズが緩和されたのだが、この仕様がいろいろ残念。

再エンコ回避ができるのかどうかについては、100MB以下ならOKという話と、100MB以下でも問答無用で再エンコされるという話があって、よくわからないことになっている。まあそもそもは公式にこういう情報を出さないからいけないのだが…。
やっとのことですこし情報が出たけど、必ずサーバー側で再エンコがかかるとのこと

再エンコされると強制的に1280x720にリサイズし、それを2000kbpsでエンコードするらしい(これが上限で、それ以下の画質も用意されるらしいがそんなもんに興味はない)。なんというか、720pで2000kbpsって足りないんじゃないの、という気がするのだけど。というか、fullHDでアップロードしてもfullHDでは残さないんですかね…。

わたしはIDが対象外なのでuploadしてテストとかはできないのだけど、実際にテストしてくださっている方がいるので、そのファイルを見て、再エンコの状態を確認した。

854x480 再エンコなし sm29420582

ビットレート分布
bitrate_sm29425082.png

GOP長
最大: 300
平均: 255.3
標準偏差: 81.76

かなり激しくビットレートが変動している。100MB以下で再エンコが回避され、適切なビットレート配分が行われているのかな、という感じ。また平均GOP長も長く、標準偏差も大きいということで、動的なキーフレーム挿入も行われていて(可変長GOP)、圧縮率が高い動画となっていることがわかる。



1280x720 再エンコ sm29472334
1280x720 5.3Mbps 496MBの動画が、1280x720 2Mbpsに変換されてしまっており、画質が低下してしまっていることが分かる。

ビットレート分布
bitrate_sm29425082.png

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 (今後、投稿動画はどうするべきか)


スポンサーサイト

コメントの投稿

非公開コメント

No title

解析おつかれさまです
推奨フォーマット2Mbps以上という公式発表は
単に可変ビットレートによる変動を想定した文言だったのですね
5Mbpsとは言わない、せめて3Mbpsまで対応して貰えれば
720pでも2Mbpsと比較して圧倒的にノイズの少ない動画ができるというのに・・・

No title

あーあ……ユーザー側でエンコードを完全にコントロールできるのが、もはやようつべに勝る唯一の点だったのに

仮に脱flashに必要な手順だとしても、ならどうして鯖エンコ設定が微妙なのかと
https://twitter.com/meso/status/766648117676511233

No title

鯖エンコをH.265とかでやってくれたらまだ希望はあった

No title

よくわからんのですが、脱Flashと再エンコって必要条件なんでしょうか。ユーザーが好き勝手にH264+AACでエンコした動画では、HTML5化に支障がでるとか?

今回の件は、スマホなどから無編集で動画を投稿しやすくするためにサイズ制限をゆるくした、一方でサーバーのストレージ消費を抑えるために数の多い6分以下の動画を圧縮したかっただけのようにも見えます。

ニコニコはMADやPVなどの動画職人を切り捨てても、ライトなユーザーを取り込みたい、Instagramのような存在になりたいと方針転換したものと受け止めています。

No title

ニコニコの今の形式でSNSみたいな運用はチグハグ過ぎて無理だろう……
何もかも大改装するというなら別サービスでやらない理由もないし

No title

たしかに、シークのためにキーフレームを1秒に1回いれる(圧縮率はどうしても低くなる)というなかで、2pass VBRだとしても720p 2Mbpsというのは無理があると思います。例えばMMDみたいな動きの激しいやつは間違いなく破綻すると思います。実際に再生してみると、それなりの画質にはなっているので、これまでのようなひどいエンコード設定ではなくなってはいるようですが…

実際はどうなのかわかりませんが、ニコ動はこれまでもサーバーを増強するのではなく、動画以外の分野の拡充とサーバー負荷を抑える施策ばかりに投資を行ってきたように見えます。

こういうこれまでのニコ動の動きを見ていると、終わりの見えているflashからHTML5に移行するのは必須だとしても、その仕様変更にあわせて、ついでに数の多い6分以下の動画を圧縮し、かつ低解像度版を用意することで再生環境によってはさらに帯域を絞れるようにしたい、としか思えないです。

HEVCは、たしかに端末等の動画再生支援対応は進んできているのですが、ライセンスとかの問題で難しいのかもしれませんね。高圧縮には向いていると思うので、本当は採用できればよいのでしょうけど…。

No title

恐れていたことが全て現実になってしまった…
前は 100MB までなら 10Mbps だろうが 120fps だろうがそのまま投稿できたのに…

Re: No title

おっしゃる通り、これまで可能だったことが、かなりの部分できなくなっていて、とても残念です…。

記事内のリンクについて

いつもx264guiEx使わせていただいています。ありがとうございます。
ニコ動の新仕様についてブログで公開されている詳細な情報とても参考になりました。

ニコ動の新しい動画エンコード方式について その1 (ビットレート分布調査)
http://rigaya34589.blog135.fc2.com/blog-entry-821.html
ニコ動の新しい動画エンコード方式について その2
http://rigaya34589.blog135.fc2.com/blog-entry-822.html

上記記事内に記載のある
【ニコ動の新しい動画エンコード方式について その3 (今後、投稿動画はどうするべきか)】
へのリンクが~blog-entry-823.htmlではなく~blog-entry-821.htmlとなっていて読み進めるとその1その2その1その2…とループしてしまいました。
お手数ですがお時間のある時に修正をお願いします。

Re: 記事内のリンクについて

たしかにループしてました…(汗


リンクを修正しました。教えていただきありがとうございました。

プロフィール

rigaya

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