ニコニコ大百科

>>689
散々試してダメだった上、他の人の30分以上の動画も確認した上で言ってる
思うけど、じゃなくて実際やってみてくれ　無理だから

もしあなたが30分以上で以前より高画質の動画投稿する事に成功したらここに設定と共に貼ってくれると助かる
というか救世主になれると思うわ

今思えばエンコ回避できてた頃は幸せだったんだな

>>690
そもそもビットレートが高い＝高画質ではないからなぁ
映像300kbpsの動画を下限1000kbpsでエンコすれば1000kbps動画(再エンコされてるので画質は下がってる)だし
ニコニコ側のエンコードが雑すぎるから数字高くても全然駄目だし
数字は全くあてにならないよ

え？そのケースも含めるの？
新仕様の検証の話だから、とりあえずそれは無しでしょ

視感検証は元動画（ソース）のビットが分からない以上、
自分でUPするかソース情報の申告がある動画でないと判断できないな
ビットが基準にならないとはあまり考えたくないな・・・
いずれにしろ31分～は360pになるから避けた方がいいと思う

投稿者からしたら問題あるんだろうが実際どうなんだろうな
俺主にゲーム実況見てる見る専だけど
仕様変更後見た動画の画質が軒並みクソになったという感覚は別にないんよね

>>689絡みで、再エンコードの解像度・ビットレートを大雑把に確認する方法を書いた。
「archive_h264_2000kbps_720p」「archive_aac_192kbps」とかの一覧を見る方法。
検証のお供にどうぞ。他に簡単な方法があれば情報求む。
　http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3365.jpg

>>691
後で試してみる予定だけど、>>689について上の方法で
ちゃんとarchive_h264_600kbps_360pになってるか確認したり、
そちらが試した設定や内容、サンプルなどを示してほしいかな。
念のため聞くけど、旧仕様向けに100MB以内にエンコードして投稿したりはしてないよね？

キーフレーム密度やその他のオプション設定の違いもあるけど
自前の2パス可変ビットレートだと全体平均が1000kbpsでも
内部で変化大きいとこだと3000使って少ないとこだと500に節約してとかやってるから
常時2000kのサーバーエンコードだとかなり無駄が出るんだよ

ニコ動の再エンコと自家エンコをSSIM的な指標で比較する人求む（他力本願）

>>698
勘違いしてるよ。さすがに常時2000kbpsなんてアホエンコにはなってない。
サーバエンコも全体平均が決まってるだけで、普通にレート制御してる。

>>699
>>484

>700
確認不足で申し訳ない
再エンコの2000kbpsは、自家エンコの1500kbpsに相当するって理解でいいのかな。

人気投稿者でも新仕様の事あんまり理解してない人多いなぁ
サーバーエンコで画質落とされてたりしてすごく勿体無い

サーバーエンコが固定ビットレートなのかCheckBitrateで調べてみた。
https://www.axfc.net/u/3738861
調べた動画は>>sm29626678


ファイルを見てもらえば分かるけど、3432から11kbpsとか出てるんで、固定ビットレートじゃないっぽい。
…調べ方、これで合ってるよね？

あと>>569で調べたけど、うちの環境ではサーバーエンコはだいたい15分で済むみたい。
…15分で済むエンコってどんな設定でやってんだ？
俺のPCだと最速設定(画質を犠牲)でやってそんぐらいなんだが。
スパコンでも置いてるのか、複数のPCを繋いで同時に処理する…
並列処理って言うんだっけ？ そういうのでもやってんのかね。
YouTubeなら5分ぐらいでサーバーエンコ終わるからそんな、無茶な時間でもないんかな。

ただ本当に不思議なのはYouTubeに960×540 500kbps 23分で上げてもクッキリしてるのに、
ニコニコに960×540 1300kbps 23分で上げるとぼやけて見えるのはほんと謎。
やっぱGoogleは技術力が違うって話なんかね。

>>703で上げたエクセルファイルに個人情報が入ってたので、上げ直し。
https://www.axfc.net/u/3738867

そーなのか
可変でも思った以上に画質落ちるんだな

>>691
動きの激しい360pの40分動画で画質比較してみたけど、普通に新仕様が勝利。

360p40分動画での新旧仕様の画質比較
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3366.png

１つ気づいたけど、もしかして「画質悪い」と言ってるのは

　・旧仕様の頃は「動き少なめで30分以上の動画」を
　　360pよりも高い解像度(例えば480p)で投稿していた。

　・新仕様でも30分以上の動画を480pで投稿したが、
　　プレーヤーを大画面やフルスクリーンにすると前よりぼやけて見える。

ということかな？
もしそうなら、新仕様では31分以上の動画は必ず360pに縮小エンコされるので、
それにともなう再生時の拡大ボケはどうしようもない。

ちょっと気になったので>>703で書いたYoutubeとの比較。
http://imgur.com/a/4efnX
うーん… あんまり変わらんね。動きが少ないのもあるんだろーけど。
違和感あったんだけど、あれなんだったんだろ。

>>706
相変わらず凄い検証だねぇ。前から気になってたんだけど、SSIMってどのソフト使うと計れるの？
ググってもPSNR出せるソフト(mPSNR)しか出てこない。
せっかく計ったので、一応貼っとく。PSNRは元画像と較べてどれぐらい違うか調べるもの…でいいんかな。
数字が大きいほど元画像に近い。ただ精度云々で最近SSIMに取って代わられてる…までググった。
比較対象は自前エンコ前のaviファイル。YouTubeは動画サイズが違うので計れなかった。

再エンコード前
PSNR 29.15549548 dB
YCbCrPSNR 33.26004932 dB

再エンコード後(ニコニコ)
PSNR 21.51873292 dB
YCbCrPSNR 26.13034289 dB

元動画(自前エンコ後)
960x540 1289.22kb/s AAC LC 436.57kb/s
22分51秒 252MB

>>706
いや、360pで書き出したよ　検証ではUndertaleを使った
ドット中心の動画だと再エンコで輪郭が前よりボヤける箇所が出るしフェードが死ぬ
ちゃんと条件書くべきだった　すまない

30分以上は360p縛りがキツすぎるんだよなぁ
これさえ無ければ前より良くなるのに

>>706
確かに新仕様の方がマシだね
でもこのレベルなら分割して上げて欲しいなと思う

なるほど
画質悪く見えるのは新仕様が解像度ショボすぎるせいか

>>707
SSIM計測にはffmpegを使ってます。

　2つの映像の画質評価をする SSIM | ニコラボ
　http://nico-lab.net/compare_two_videos_ssim_with_ffmpeg/

上記ページにあるように、
　ffmpeg -i original.avs -i encoded.avs -lavfi "ssim;[0:v][1:v]psnr" -an -f null -
でSSIMとPSNRをあわせて計測。

original.avsは、エンコードソースにしたAvisynthスクリプト(avs)。
素材動画をL-SMASH Worksで読み込んで解像度やフレームレートなどを加工したもの。

encoded.avsは、自エンコまたはサーバエンコされた動画をL-SMASH Worksで読み込んで、
フレーム位置やフレームレートなどがoriginal.avsと一致するように
Trim()やAssumeFPS()等で調整したもの。
サーバエンコされた動画は、前後に余分なフレームが入って数フレーム増えることがあり、
その場合フレーム位置がオリジナルとずれてしまうので、
Trim()で削ってオリジナルと一致させる必要があります。
また、59.9401(60000/1001)fpsだったものが59.9405(5035/84)fpsに
なったりすることもあるので、その場合はAssumeFPS()でフレームレートを
オリジナルと一致させる必要があります。
avsの編集・確認にはAvsPmodを使い、infoで情報を見たり、
オリジナルのavsの映像と見比べたりして調整してます。
確認が面倒ですが、フレーム位置やフレームレートが一致しない状態で
SSIMを計測してしまうと正しい結果が出ないので・・・。

SSIMは指標の１つに過ぎないので過信せず、あくまでもただの参考値として扱い、
最終的にはちゃんと目で見て画質評価しろと言われてますね。

>>701
たしかに>>484の720p60のグラフでは再エンコ2000kbpsが自エンコ1500kbpsに
劣る感じになってるんだけど、グラフ右下に書いたように
テスト手法がいまいちなので、はっきりそう言える状況ではない感じ。

>>708
なるほど、ドット系動画とフェード・・・。
時間やビットレートによる解像度縛りは本当に撤廃してほしい・・・。

>>709
>>706でテストに使った動画は>>484でも使った動きの激しいMMD動画。
x264のデフォルト設定でエンコードすると360pの29.97fpsでも
2600kbpsも必要になるというもの。
テストのためにあえてそういう動画を使ったのだけど、ここまで複雑な動画を
600kbpsでなんとかしろというのがそもそも無理な話。
30-60分ゾーンで投稿できるのは、動きが比較的少ないものに限るだろうね。
30分までなら360pで1000kbpsまで使えるのだから、そこまでに収めるか
分割したほうがよいだろうというのは同意。

自分の調査じゃなく引用で申し訳ないけど
サーバエンコのビットレート可変の振り幅については
x264guiEx作者のここ見るとよくわかると思う(振り幅が小さい)
http://rigaya34589.blog135.fc2.com/blog-entry-821.html
他に空間的圧縮(１フレーム内での圧縮)についてはこっちの画像のとこ
http://rigaya34589.blog135.fc2.com/blog-entry-822.html
使ってないマクロブロックがある(mainプロファイルだから)ので圧縮効率が悪い
って感じかな

自分にとって分かりやすい用語で言うと
Main＠L3.2 bframes 3 ref 4 keyint 30
ローカルエンコと数値的にかなり違う
他にも8x8dctオフとかあるけど
自分はその調整しないのでよくわからない

MMDerだけ殺す投稿システムかよ！

画質はどうでもいいので、音声を確保したい動画でうｐっても10分にしかならんのだが・・・フォーマット制限でもあるの？
なお、LC-AACでエンコ
HE-AACは糞だと思ってるのでなるべく使いたくない

>>716
「10分にしかならん」の意味がよくわからん。ちゃんと説明してくれ。

>>717
要点がなかったｽﾏｿ
30分超の動画（音声メイン）をうｐりたいんだが、ニコに上げてエンコかかった段階で10分の動画が出来上がってくる。解像度ミスってるかもしれんが・・・

>>718
フォーマットが変なら投稿エラーになるし、解像度などの制限で
30分の動画が10分になるようなバグは今のところ報告されていない。
投稿前のエンコードミスも考えられるので、
　・投稿に使った動画ファイルをMediaInfoのテキストモードで調べた情報
　・エンコードに使ったツールや、その設定
　・晒してもよいならアップした動画のURL
といった情報をテキストファイルに書いてどこかにアップロードしてもらえれば
アドバイスはできるかも。

さっきちょっと投稿テストしたら、
　　1280x720/59.9401(60000/1001)fps/3597frames/1:00:009
でアップした動画が再エンコによって
　　1280x720/59.9401(60000/1001)fps/3594frames/0:59.959
にされてて、調べてみると
　　・冒頭の7フレームが削られた
　　・末尾に4フレームの黒画面が追加された
ということがわかった。
前後に黒フレームが少しつくことがあるのはこれまでも確認してたのだけど、
動画本編のフレームが削られてたのは初めてなので、一応報告。