はい。
この記事はKaku-tail THE@TERやMSC2019 Re:で本編動画制作を担当した際に使用した、ニコニコ動画にできるだけ高画質な動画を比較的少ないエンコード時間で投稿する方法について述べる記事です。
下記がこの方法でエンコードし、投稿した動画です。
この記事はあくまで投稿用の動画エンコードの労力を少なくする方法であって、フルHDでの動画制作そのものが厳しい性能のPCである場合は想定していません。
3行で
- 再エンコードはどうしても必要という事実を受け入れる
- そのかわり、フルHDの超高ビットレートにして3GBという投稿サイズ制限をギリギリまで使う
- エンコードの待ち時間を短くするためにQSVやNVEncを使ってハードウェアエンコードする
Flash亡き今、再エンコードはどうしても必要
しかし、H.264にはパラメータが膨大な数あり、再エンコードされない一定の条件を守るのも大変で、結果としてパラメータの解説記事が膨大な数書かれたり、つんでれんこという偉大なx264のラッパー*1が誕生したりしました。
しかし、AppleがFlashをサポートしない方針になったことで再エンコードをしないという非常に特殊な仕様の根底となっていたFlashに頼れなくなり、ChromeでもFirefoxでもSafariでも、さらには2011年発売の携帯ゲーム機である3DSでも(!)等しく再生できるようにするという担保をニコ動と動画投稿者のどちらかが負う必要が出てきたと。
mp4やH.264というのは非常に複雑なもので、動画投稿者があらゆるデバイスで再生できることを担保するのは事実上不可能です。
一か所指定を間違えたり忘れたりしただけであっさりと、特定のデバイスでだけ再生できないmp4が出来上がったりします。
ので、ニコ動がその辺を全て請け負うために再エンコードをするようになったわけです。
これはもうそういうものとして受け入れるしかないです。Flashはもう帰ってこない。
3GBという投稿サイズ制限をギリギリまで使う
さて、再エンコードから先に干渉できないならどこを変えるかというと話は単純で、ニコ動のエンコーダに渡すフルHDの動画の画質を良くしましょう。
フルHD指定なのは単純に、ニコ動の投稿動画は投稿されたファイルがフルHD以上かつ30分以内という条件を満たしたときにフルHD画質の動画が生成され、これが最もビットレートが高いためです。
とすると「良い画質」って何、という話になるわけですが、ものすごく簡略化すると、
- ビットレートが同じ場合、エンコードに長い時間(正確には演算量)を使うと画質は良くなる傾向にある
- が、長い時間をかけるようにしても増えた時間に対して少しずつ効果は減っていく
- 時間を2倍使っても画質が2倍良くなるわけではない*2
- エンコーダの設定が同じ場合、ビットレートを高くすると画質は良くなる傾向にある
という関係になっていることは直感的にご存知かと思います。
つんでれんこはそこそこの長い時間(多くの演算量)を使って、数十から数百MB程度のファイルサイズの範囲内でできるだけ良い画質を実現できるように実写向け、アニメ向け、など複数のプリセットを用意していました。 *3
数百MB程度のファイルサイズに収まるようにしているのはかつてのニコ動には投稿した動画のファイルサイズの合計に制限があったからですが、現在その制限はなく、単純に投稿動画の数に上限があるのみとなっています。*4
であるならば、ビットレートを高くして3GBギリギリまで使えば、それほど多くの演算量を使わずとも、より良い画質の元動画をエンコードできるでしょう。
ハードウェアエンコードを使う
3GBがどれくらい大きいサイズであるかと言うと、5分の動画であれば81.92Mbps、20分の動画でも20.48Mbpsもの高いビットレートにできます。
ニコニコ動画のアイドルマスタータグには2019年9月23日時点で411,952個の動画が投稿されており、そのうち5分以内が268,880個、5分より長く20分未満が115,056個、20分超は28,016個であり、97％くらいの動画は20.48Mbps以上のビットレートを元動画で使用できる計算です。
ブルーレイの規格上の上限が40Mbpsで、多くの場合は25Mbps程度ですから、ここまで来るとたかが数時間程度多めの時間をソフトウェアエンコードに使ったところで人の目で見分けるのは難しい領域になってきます。
そこで選択肢として浮上してくるのがハードウェアエンコードです。
ハードウェアエンコードと言うと画質が悪いというイメージを持たれる方がいるかもしれませんが、数十Mbpsの領域になってくるとそもそも人の目で見分けるのは難しい領域ですから、ハードウェアエンコードでエンコードにかかる待ち時間を短くしたほうが制作過程でのストレスが少なく済みます。
aviutlを使用している人はrigayaさんのハードウェアエンコードによる出力が可能となるプラグインシリーズ、NVEnc、QSVEnc、VCEEncを使うとよいでしょう。 拡張編集で編集した動画をハードウェアエンコードで直接H.264として書き出せるので、投稿直前の修正とチェックのサイクルを短時間で回すことができます。
実際の設定例
下記がMSC2019Reの決勝ブロックの動画で実際に使用したNVEncの設定です。
このうちビットレートの項目のみ動画の長さによって変わります。
実際どれくらいの画質劣化があるのか
「数十Mbpsの領域になってくるとそもそも人の目で見分けるのは難しい」と一旦書きはしましたが、実際どの程度の劣化があるのか気になったので検証してみました。
下記の6枚のpng画像は、Ut Video YUV420 BT.709で書き出した可逆圧縮のaviファイルと、NVEncを使用してエンコードした実際に投稿に使用したファイルの差分*5を取り、それを16回重ねて目視できるようにしたものです。
いずれも動画中のどの箇所であるか判別はできますが、16回重ねて目立たせてやっとこの程度なので、「数十Mbpsの領域になってくるとそもそも人の目で見分けるのは難しい」と主張できるのではないかと思います。
ここからどのような画質の動画が再エンコードによって生成されるかはニコ動のみぞしるところですが、少なくとも元動画まではそれほど頑張らずとも十二分な画質を実現できていると思います。
まとめ
ということで、ニコニコ動画にできるだけ高画質な動画を比較的少ない労力で投稿する方法でした。
なんか大仰な記事タイトルにしてしまいましたが、やってることは別に凄いことでもなんでもなく、単に「画質面は3GBの投稿サイズ制限ギリギリまで使った高ビットレートの力技で、数十Mbpsのビットレートではもはや画質を人の目では区別できないのでハードウェアエンコードでエンコード待ち時間を減らす」というだけのことです。
ソフトウェアエンコードの所要時間はCPUの性能に大きく左右されますが、ハードウェアエンコードはソフトウェアエンコードほど所要時間に差が出ませんので、古めのCPUでソフトウェアエンコードを頑張っていた人ほど待ち時間が短くなると思います。
ハードウェアエンコード、うまいこと使っていきましょう。
余談
x264でpreset veryslowでcrf 0(=ロスレス)のエンコードを試したところ、i9 9900Kで0.3倍速という激遅エンコードでしたが9.42GBになりました。
つまり、ニコ動の投稿サイズ制限が10GBくらいになったら「x264でpreset veryslowでcrf 0(=ロスレス)のエンコードを頑張りましょう」が画質面での最適解になります。
所要時間も考慮に入れると、画質面では次善になりますが今回ご紹介した「投稿サイズ制限ギリギリのビットレートでNVEncを使ってエンコードする」が引き続き候補になると思います。
更にNVEncのロスレスモードを試したところ、28.8GBになったのでニコ動の投稿サイズ制限が30GBくらいになったら「NVEncでサクッとロスレスエンコードしましょう」が画質、所要時間両面での最適解となるでしょう。
※ストレージの転送速度やインターネット回線の上り速度は考慮しないものとする
*1:扱いを簡単にするために包む(wrap)ものという意味
*2:まず画質が2倍良くなる、の2倍って何という定義の話も今回はしない
*3:いわゆるつんでれんこ完結版、TDEncのリリースノートに「1080p制限緩和(30分、3GB)に対応」と書いてあるのですが3GBいっぱい使うような挙動にはなっていないように見える https://tdenc.com/blog/2018/04/27/tdenc-tdenc2-298/
