ニコニコ大百科

>>750
動きを少なくしたり、コマ間の差分を減らしゃ、そりゃー画質も良くなるさ。
特段凄い動画でもなくね？
まぁ"ビットレート"、"コーデック"が何なのか知らない人には凄いのかもね

冷静に考えたら、この掲示板じゃ常識みたいに語られてる、
黒尺追加法なんかが記事に書かれてないのに気づいた。
元々の項目に足すのは難しそうなんで、こういう項目はどうだろう。

「とにかく高画質にしたい！(項目名)」
以下の記事を参考にして作成。
http://ch.nicovideo.jp/tamazou/blomaga/ar1109929
1.基本的には、動画時間を15分59秒までに抑えて2Mbps以上にして、
最新のエンコツールでエンコードすれば極端な劣化は起こらない。
2.しかし、MMDを始めとした動きが激しい動画などは、
基本的な設定を守っても画質が激しく劣化することがある。
以下、対策。

I.動画の最後に、動画時間の半分の黒背景(5分の動画なら2分30秒)を追加する。2Mbpsがだいたい3Mbpsぐらいのビットレートになる。(参考 http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3364.png)
II. 新仕様は暗転やフェード時に特に劣化するらしいので、こうした特殊効果を避ける(劣化の程度については検証中)。
III.fpsを削る。30fpsならAviutlなどで24fpsまで削る。動画情報が減っているので、画質の向上が期待できる。
IV.カメラモーションを工夫する。詳しくは前述の記事(URLリンク ar1109929)を参照。

fpsについてだけど、公式の推奨フォーマットも「24fps もしくは 30fps」なのね…

あと、掲示板でけっこう色々な資料が貼られてるけど、
これってもし記事内に入れるなら関連リンクかな？
これは「アップロード後の動画について」でよさそうだけど。
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3365.jpg
この辺とか。
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3367.png
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3368.png
あとアップローダーなんで、その内削除されるのかと思ったら、
思った以上に長持ちするロダなのね。基本的に消えないのか？

>>752の黒尺法に追加。

この方法でビットレートを引き上げた場合、
普通のアプリ(真空波動研など)では正確なビットレートを見ることはできない。
この手のアプリは黒背景部分も含めてビットレートが計算され、表示される。
そのため、だいたい2Mbpsを割った数字が表示される。
黒背景を除いた部分のビットレートを調べたければCheckBitrateを使うのがいいだろう。
また、黒背景以外にも、静止画にも同じようにビットレートを上げる効果がある。
見栄えを気にするなら、一枚絵を貼るのがいいだろう。

情報源 >>sm29918805

これをCheckBitrateにかけたもの。3Mbps越えてるよね。
https://www.axfc.net/u/3740349.csv

「高画質にしたい」→無理
「可能な限り画質を良くしたい」→可能
だと思ってるのだけど・・・どうよ

>>754
おまえのその考え方、イエスだね！

>>753
リンク先の動画の場合、２：１の法則を無視してるけど、
静止画で平均1Mbpsも消費されてるから動画部分も平均3Mbpsに収まってるようだ

逆に、静画を入れてしまうとギリギリが読めなくなるデメリットがあるかも

>>756　訂正
静止画で平均1Mbpsも消費しているから全体で平均2Mbpsになり、問題なく視聴できているようだ

>>756,757
黒ベタとそれ以外は区別されるけど
静止画と動画部分は区別されないので
静止画＋動画の長さの半分まで黒尺を足せば
静止画と動画を合わせて平均3Mbpsまで出せる
ということでいいでしょうか？

758の前提で黒ベタを(静止画+動画)の半分にして
2000kエンコードギリギリを狙ってるんだけど
映像平均2100kbps以上あっても1800k(1880ぐらい)でしかエンコードしてくれない。
もう一度記事と掲示板を読み直してみたら200kbps刻みという説明と
1800～2000kbpsのクラスっていう記述を見つけた
もしかして高画質は2000kbpsってのは
条件として2Mbps以上推奨(公式情報)って言っておいて
エンコードしたら1800kちょいかも知れないってことなのかな
誤差としたら仕方ないのかもしれないが自分は2000kbpsでエンコードされると思ってたし
高画質200kbps違い、中低画質100kbps違いってのは
動画にもよるけど結構画質に影響あるような気がするんだけども
俺みたいに勘違いしてる人いないんだろうか？

>>758,759
黒ベタだと見た目がアレだから「代わり」に静止画を使うのであって
静止画と黒ベタを両方使う意味はあるの？

そもそも静止画でなく黒ベタをなぜ推奨しているか？というお話になるのだけど・・・
そこまで詳しく知りたい？

うっさい、初心者は黙って2(動画):1(黒ベタ)で作れば画質は良くなるんだよ！
と切り捨ててしまえば、いっそ楽。

静止画と黒ベタは動画エンコの性質も有ってビットレートが10倍から1000倍違うのよね(切り替えもビットレート食い)
食費を節約したいのに10円で済むところを1000円掛かるとしたら払う気になる？
黒ベタbitrate検証はは>>586 にある

ついでだから投稿とエンコードのビットレート比較
rigayaさんのとこにあるけど自分でもやってみた
http://2sen.dip.jp/cgi-bin/upgun/up1/source/up3177.png
冒頭の静止画(黒地に白文字テロップ)をエフェクトでスクロールしたのが
予想外にエンコード後のビットレート食ってた

>>759投稿する予定の動画を２Ｍｂｐｓちょうどに調整しても何も良いことないぞ。
5Mbpsだろうが10だろうが気にせず投稿すれば、エンコ後に全体で2Mbps（黒ベタとかで対策すれば動画部分の映像ビットレートは３Mbpsくらい）+音声分ビットレートになる

100MB投稿 再エンコ後100MBは無理だから2Mbps 90MB位を目指してるんだけど
ギリギリ無理なんですよ　1.8Mbps84MBになってしまう

>>760
あくまでイメージなので正確ではないけど、黒ベタだと黒のブロックが一つという感じでエンコードできる。
エンコードアルゴリズムは動き検知はするけど、一定時間全面静止画かどうかの判定は行わないので、黒ベタの方が圧倒的に圧縮に有利。

多重再エンコードしてる動画を見かけた。言われてみれば、やってなかったね。>>sm30031214

一応、動画内では、「オリジナル動画」→「再エンコ動画」と並べられてるけど、
この動画自体が再エンコードされてる。
なので、厳密には、
再エンコ動画(一回目)→再エンコ動画(二回目)の順で表示してるようだね。
まぁ結論部分とかは眉唾なんで詳しい人に投げる。

>>765
2Mbpsで90MBなら６分くらいの動画を想定してるんだろうけど、
500MBくらいの高品質mp4を投稿すればそれでいいのでは？
それとも何か高度な実験をしてるのか

>>765
なにがしたいのかいまいちよくわからないけど、
　・smile鯖にオリジナルファイルを置いておきたいから100MB以内で投稿したい
　・よく動く部分は黒ベタ効果で実質3Mbpsにしたい
　　　→>>763を見る限り40秒～240秒あたりはちゃんとそうなってるのでこれはOK
　・2Mbps以上で投稿し、再エンコード後の平均ビットレートも2Mbpsになるようにしたい
　　　→>>763を見ると1700kbpsくらいになってしまっている。（※これが疑問）
ということでいいのかな？

だとすると、
　・>763の動画については再エンコ後の平均ビットレートの曲線と
　　2Mbpsラインとの交点が330秒前後のとこだから、黒ベタを
　　そのあたりで終わらせて投稿すれば平均2Mbpsになると思う。
　・投稿ファイルの映像ビットレートが2Mbpsあるのに
　　再エンコ後の最終的な平均ビットレートが1700kbpsくらいになってるのは
　　ビットレートをあまり必要としない静止画や黒ベタ部分が多いから。
　　というか必要より黒ベタが多いから。
という回答になるけど。

「動画部：黒ベタ部」が「２：１」になるようにというのは、
「動画部に全体的に動きがありビットレートを多く必要としている場合」に、
「動画部分が実質3Mbps、平均ビットレートが2Mbps」にするためのバランス。

動画部分に「静止画」「ほぼ動きのない場面」「黒ベタ」がそれなりに含まれるなら、
それらの部分はあまりビットレートを必要としないので黒ベタ的な役割を果たし、
平均ビットレートを下げる方向に働く。
黒ベタが必要とするビットレートはゼロに近いが、
静止画が必要とするビットレートは絵の複雑さによるので、
その部分がどれくらいのビットレートになり、
どれくらい平均ビットレートを下げるのかは絵の複雑さ次第。

>>765
>>769の続き。
以下の動画は、4:15の動画に11:44秒の黒ベタ(長すぎ)をつけたもの。
>>697の方法で調べると「archive_h264_2000kbps_720p」とあり、
サーバとしては平均2Mbpsでのエンコードを目指してるけど、黒ベタ部が
長すぎるため平均ビットレートが引き下げられ、840kbpsになっている。
現象的にはこれと同じこと。
なおこの動画は映像部は実質3Mbpsになっているので画質確保はできているが、
平均ビットレートが低すぎるので視聴時の読み込みが遅く、止まりまくる。
>>sm29523977

>>768,769,770
330秒だとこんな感じですね。
http://2sen.dip.jp/cgi-bin/upgun/up1/source/up3178.png
確かに再エンコビットレートは1980kbpsになりました。
769さんの言うとおりsmileに100MBの再エンコ回避を残しdmc側をビットレート高めに
（出来れば動画部分3Mbps）にしたい
と思っていたのですが、この動画で動き部分3Mbps難しそうですね
冒頭の40秒は仮にもし3Mbps以上になっても止まりにくくするための予防でした。
冒頭から動画部分が有る方が3Mbpsに近づくんですがそれでも動きの激しい部分が
短すぎて100MBにはならないので(今だと画質がちょっと不満)
頭に静止画類を入れればうまくいくんじゃないかという実験でしたが
あまりうまく行かなかった　と言う感じです
なぜ100MB投稿かというと生放送リクエスト優先という個人的な都合です。(再生数のほぼ全部がそれｗ)

>>771
>この動画で動き部分3Mbps難しそう

多分トータルの平均ビットレートのラインを見て
考えてるんだと思うけど、根本的に勘違いしてる。

動き部分に3Mbps割り当てられているかどうかは、
「動き部分だけの平均ビットレート」で考えるべきもの。
>>769の最初でも書いたけど、CheckBitrateで動きのある40～240秒のデータだけ
切り出して平均ビットレートを計算してみれば多分3Mbpsくらいになるはず。
（グラフ見ると3000kbpsラインを中心に上下してる感じだし）

新仕様の高画質720p2000kbps再エンコの場合、いくら黒ベタを入れようが、
動き部分は「ある程度の区間の平均ビットレートが3Mbpsを超えないように」制御される。
冒頭40秒にほとんどビットレートを食わない部分が入ってる以上、
(0秒から計算している)トータルの平均ビットレートが3Mbpsに至らないのは当然。

５秒分を切り出して単純化して考えた場合、最初から動きまくるならば
　３ ３ ３ ３ ３　←区間の平均ビットレート(Mbps)
　１ ２ ３ ４ ５　←秒
ということでトータルの平均ビットレートは（３×５）÷５＝３Mbpsになるけど、
冒頭にあまり動きがないなら、
　１ ３ ３ ３ ３　←区間の平均ビットレート(Mbps)
　１ ２ ３ ４ ５　←秒
ということでトータルの平均ビットレートは（１＋３×４）÷５＝2.6Mbpsになる。
区間の平均ビットレートは３以上にはなれないので、
冒頭が１ならどうあがいてもトータルの平均ビットレートは３にはならない。

>>772
＞「動き部分だけの平均ビットレート」で考える
なんてことがエンコソフトに出来るはずがない（2パス程度で）
という考えのもとにやったんですけどね　間違ってたみたいです

＞ゲーム実況のような長時間になりやすい動画では便利になった一方

頼む、仕様についてのこの一文せめて「影響がそこまで出ない」ぐらいにしてくれ
色々分かった今でも長時間動画で全く便利になったと思えない

新仕様になってビットレート数的には得してる人も居るかもしれないが、
実画質的に得してる人は本当にいるのだろうか？

「前より綺麗になった、うれしー」
なんて言ってる投稿者を見たことが無い
知ってる人いたら紹介して欲しいわ

>>774
長時間系は旧100MB仕様よりビットレートが使えて有利なので、
そこを否定するのはフェアじゃない気がする。
便利になった気がしないという理由はこれまで主張されている
　「ドットがぼけたりフェードに弱い」
という点なんだろうけど、それについてはデメリットの最初の項目に
以下のような感じで追記した方がいいんじゃないかと思う。

・強制的にサーバ側での再エンコードが行われるようになった。
　　→エンコード設定がいまいちで、ドットがぼけたりフェード時に乱れやすいといった弱点がある。
　　→ユーザが思い通りに画質制御できなくなってしまった。

ところでドットがぼけるという件、こちらでも検証してみたいんだけど、
高画質な元動画の提供または心当たりがあればそのURL提示などできないだろうか？

>>775
新仕様では基本的に長時間系が有利というのは既に色々書かれてる通りだと思うんだけど、
元々旧100MB仕様時代にアップされてた長めの動画というのは、
あまりビットレートを必要としない系統のものが多かったわけで、
それと同じような動画投稿を続ける場合は、新仕様の恩恵を感じにくいと思うんだよねえ。
せいぜい「もうちょっと長くして投稿しても大丈夫だな」とかで、
逆に>>774のようにフェードの乱れが気になったりというケースもあると思う。

「そこそこ動きのある長めの動画」をアップすればそれなりに
恩恵を感じるのかもしれないけど、そういう人が少ないのかもねえ。

>>776
それもあるけどツイッターで「運営によるゲーム実況優遇」って反応する人が多くて正直あまり気分良くないのよ…
俺ゲーム動画結構見るんだけど今の所文句言ってる投稿者しか見てないし
総統閣下は「1.5GB投稿可能！」にお怒りのようですの人も実況プレイヤーだし便利になったってのは少し違う気がする

ドットがぼけた動画は削除されちゃってたからURLしか貼れないけど一応
>>sm29906904

ゲーム自体はフリゲみたいだからDLして録画すれば検証は可能

>>776
いや、画質も目に見えて良くなったってほどでもないから欠点のみが意識されてると言って問題ない
画質が通常の視聴している際に気づかない程度だけ良くなったってそれ全然メリットじゃないし
まあ俺も沢山の種類の動画を見てるわけじゃないし、投稿してるジャンルはもっと少ないから
間違ったこと言ってるかもしれないけど

「長時間動画以外の投稿者が得している可能性が皆無、
　残りの万が一の可能性は得した長時間動画投稿者だけ
　だがそっちは不明」」
って感じでこれ以上変化しそうにないなあ
動画のコメント見ると喜んでる視聴者は一定数居ると思う。
が「今までの投稿者」で得した人は居るのかってのが不明
何か少しでも損を減らす方法はないか？ってのをここで
色々検証してるんだと思う。