402 Payment Required - お金が必要です
動画変換・編集ソフト Pegasys TMPGEnc Video Mastering Works 6
直販で12,200円（ダウンロード版）。4K/8K 時代に求められる機能を備えた定番の商用エンコードソフト。2014年12月19日発売。
略称は TVMW6 。まず目につくのは H.265/HEVC のサポートと 64 ビットネイティブ化だけど、4K/8K 出力に対応するなら当然の強化ポイント。エンジンは順当に x265 だが、前バージョンでは H.264/AVC の設定の際、x264 エンコードに慣れてる人から TVMW 上の詳細設定項目と名称やパラメータを一致させるのに頭を悩ませた、なんて話をよく耳にした。他にもペガシスは疑問を感じたり腑に落ちないような機能や設定の割り当てをすることがあり、今回も親切心？が仇となる罠が潜んでそうな悪寒。
HEVC と 4K/8K にばかり目が行きがちだけど、H.264/AVC も YUV 4:4:4 10 ビットの入出力や NVENC を利用したハードウェアエンコードが可能になり利便性が向上している。地味なところでは WebM、Ogg の出力だけど、これは HTML5 の canvas で必須になってるコンテナで、ウェブ標準への対応を意識してのことか。さらにもの珍しいところではファイルベースのノンリニア編集などに採用されている桃井はるこイチオシのカートリッジメディア、 iVDR 向け出力（映像は iV VIDEO, コンテナは AVS）なんてものまで追加されている。コンシューマにどれだけ利用者がいるのか知らんが、いろいろ頑張ってるのだ。
エンコーダとしての側面以外にも各種フィルタやタイムラインモードの機能も大幅に増え、ちょっとした映像であればプロユースでもイケそうなくらい動画編集ツールとしてもかなり充実してきた。わしにゃとても使いこなせそうにない。あと細かい点ではようやく DVD や Blu-Ray のトラックイメージを直接読み込めるようになったのが嬉しい。わしのようにこれでもかと外付け HDD 繋いでるとドライブレターの空きがなくて同時に仮想マウントできる台数も限られてくるのよね。
機能強化が著しいだけに求められるマシンスペックのハードルも高く、特にタイムライン編集の推奨環境は Core i7 2.66GHz 以上と Yorkfield 以前は切り捨てられた。さらに今バージョンより 64 ビットOS専用となったので、32 ビット環境については TVMW5 を使い続けるしかない。まあ動画エンコードをガツガツやるような人だったらまずは 64 ビットに移行するのが先だわな。HD 以上の高解像度になるとソースや出力ファイルからして 10GB オーバーが当たり前だから、メモリ空間の狭い 32 ビット環境じゃちょっと扱い切れないし（ 64 ビットでも RAM 16GB 程度じゃ苦労するよ！）。
TVMW5 からのアップグレード価格は7,320円、Ver.4 以前を含むその他のペガシス製品を対象とした優待販売価格は9,760円で、Ver.5 を平行して使うのであれば後者。FLV1/4 ファイルの入力や DV キャプチャといったニーズのある人は Ver.6 で削られてるため現状維持で。
2016-03-21
4TB はもう当たり前で 8TB すら2万円台で手に入るようになるとストレージのゆとりが感覚を鈍くするみたいで、最近はもう DVD は MPEG-2 ストリームをそのまま MKV コンテナに突っ込んでる。たいていは 4GB 程度だし、片面2層でも 8TB あれば 1000 本イケるからね。エンコードやカット編集もいっときはデジ一眼で撮った動画くらいしか出番がなくなりつつあったけど、さすがに Blu-Ray まで考え無しに MKV 化するわけにもいかない。元映像の長さにも拠るけど2時間ものの FHD で 5～6GB 程度に抑えたいところ。あ、同じビットレートなら当然 H.264/AVC より H.265/HEVC でエンコするほうが画質は上だわな。まだ BD ソースがそれほどないうちに少しでも HEVC に慣れておくとしますかね。
そんなわけで、Ver.3 から愛用してる TMPGEnc をバージョンアップすることにした。けっこうバグが残ってるリリース初期ならまだしもさすがに発売から1年以上経てば落ち着いてるはずで、旧バージョン残す必要もあるまい。とアップグレード版をポチリ。ミッションコンプリート。なおポチってからタイムライン編集の推奨環境、CPU は余裕でクリアしてるけどグラボが GeForce GT 650 以上
で、うちは GTX 650 だからけっこうギリギリだったことに気づいた（つか GT 650 ってあるの？）。TVMW7 の頃にはマシンごと入れ替えだな…。GOM Player での HEVC 再生どんなもんか試してないことに気づいてドキドキ（ Intel Media SDK HEVC Software Pack の再生支援が使えるんだけど、内蔵デコーダーを無効にしないと画面真っ暗だった）。
2016-03-23 同一条件でのエンコーダー比較
さっそく手持ちのイメビでお試しうんこだー、もといエンコーダーの違いによる処理時間を条件を変えながら比較してみる。ソースは DVD（MMR-AK-002 MODEL 長谷川あや）のトラックイメージでサンプル映像の部分のみ使用。
- a) ノーマルエンコ（解像度 720ｘ480 の SD）
- b) アップコンバート（エンコード時に 1920ｘ1080 の FHD にリサイズ）
- c) b＋フィルタ処理（輪郭強調、ガンマアップ、ソフトフォーカス）
当然ながら下にいくほど演算量は増えるわけだ。比較しやすいようそれぞれ High Profile / 自動 Level（4.1）の 1pass VBR で統一、エンコーダーが x264、NVENC、x265 の合計9パターン。ただ実際に x265 を使うとなったらビットレートを x264 と同程度の画質まで絞ることになるので、ここはひとまずソフト任せのオートビットレートにしてみる。そのほかの設定はデフォルトのままエンコード。
自動算出された平均ビットレートは H.264 が SD：2.05Mbps の FHD：12.4Mbps で、H.264 は SD：1.2Mbps の FHD：7.45Mbps となった。どうやら単純に H.264 を BPP＝0.20、H.265 を同 0.12 としてるっぽい（上限ビットレートは選択 Level の MAX になる）。たぶん TVMW6 は H.265 について H.264 のおおむね6割で同等のクオリティを得られる、と考えているのだろう。
なお処理に用いたマシンは Core i7 4770、RAM 16GB のグラボは GeForce GTX 650。導入から2年近く経つが今でもまずまずのスペックと思われる。CPU に対してグラボが弱いのは、わしがゲームやらないため（詳細についてはお買い物コーナーの記事を参照）。GM204 コアの GTX 970 でもあれば H.265/HEVC ＆ NVENC の組み合わせで 4K アップスキャン、なんて検証できるんだけどねえ。
わかりにくいのでグラフにしてみる。参考までに、ソースの再生時間と WMV9、WebM（VP8＋Vorbis）、ogg（Theoma＋Vorbis）それぞれノーマルエンコ※注、TMSR5 による MKV コンテナへのストリームコピーに要した時間も載せてみた。
注）WMV9 の 1pass VBR はビットレート指定不可（品質固定のみ）なので今回は 2Mbps の CBR でエンコードした。また WebM と ogg は SAR を設定できない。これは YouTube などの受け入れ解像度がアスペクト比によって決まっているためと思われる。今回は解像度を 720ｘ480 に固定したが出力映像はレターボックス表示になる。
さすがハードウェアエンコード、NVENC の効果は絶大でノーマルエンコの15秒（！）はもちろんのこと、アプコン＆フィルタ3枚掛けでもほぼ実再生時間なんだからたいしたもんだ（うちのグラボがギリギリ Kepler 世代で助かったぜ）。CPU 負荷も2割以下でまったくストレスを感じなかった。x264もノーマルエンコでは実時間の半分以下となかなか優秀だが、アプコンやフィルタを加えるとずいぶん待たされてしまう（条件 b と c で逆転現象が起こってるけど、バックグラウンドで何か動いてたのかも）。普段は 2pass なのでこの倍くらい掛かるんだよねえ…。またどの条件も x265 がダントツで時間掛かってるけど、H.264 勢に比べて処理負荷による伸び率は低いのが興味深い。あと気になる画質は BPP 0.20 ＆ 0.12 と自動算出値がずいぶんと余裕みてる感じなのでいずれもはっきりした体感差は確認できず。これは参考の3つも同じで、気が向いたら条件揃えた上で画質比較をしてみる。
参考の3つのうち WMV9 はわりと健闘して及第点に収まってるけど、WebM は x264 の倍、ogg に至っては実時間を超えている（WebM は VP9 じゃない、VP8 だからな）。積極的に使うことはないにせよもう少しなんとかならないものか。なお TMSR5 はエンコード開始をクリックしてから処理が始まるまでの待ち時間のがずっと長かった。ソースが MPEG 系でストレージの心配無用な人はこれ一択。
ファイルサイズをみるとオリジナル（MKV）の 72.2MB に対し、H.264 の SD が 25.3MB、FHD が 146MB。x265 は SD が 16.3MB で FHD が 89.5MB。参考の3つはいずれも 26MB。
おまけ：NVENC で FHD にアプコンした映像を YouTube にアップしてみた。
オリジナルは 156MB だけど 48MB に再圧縮されてるしこれだけで結論づけるわけにもいかないけど、おおまかな参考にはなるのでは。
ひとまず傾向をまとめると、多少ビットレートを盛ってやる必要はあるが TVMW6＋NVENC は想像以上に使える。ただ低ビットレートで苦しいのは否めないので（BPP 0.1 とかにすると惨いｗ）画質と圧縮率ともに譲れない場合は x264 の 2pass。x265 はさらにその倍の時間掛かるだけのことはあって BPP 0.12 でも十分イケることがわかった。時間掛かるといってもノーマルエンコなら実時間の4割増し程度で、倍を要した WMV9 や初期の H.264/AVC よりはずっとマシだ。限界までファイルサイズを抑えたいとき、あるいは時間を掛けてでもクオリティを落したくない場合にご登場願おう。具体的には DVD の片面一層はストリームコピー、片面二層は NVENC、BD は HEVC、ニコ動は x264 って使い分けになりそう。
…とにかく NVENC の処理速度と画質のバランスにはビックリした。今までハードウェアエンコは画質いまいちで敬遠してたけど、初期の QSV や CUDA の画質にガッカリして食わず嫌いしてる間にずいぶん置いてけぼりにされてしまったらしい。しかも NVENC より QSV のがさらに上ってんだろ？ Pegasys も製品ラインナップに NVENC なり QSV 前提で“TMPGEnc Realtime Streaming Edition”とか増やしてもいいんじゃないかと思ったり。
BPP 0.1 程度まで圧縮するような前提だとハードウェアエンコは使い物にならないだろうけど、わしはエロ動画専門なので 0.2 までは許容範囲だから問題ない、というお話（ストレージ容量より処理時間に追われるんだよ。
2016-03-26 DVD ソースからのエンコード
NVENC MP@3.1 BPP=0.20 で 60分の Vシネ（DVD）を 7分でエンコ完了、実に素晴らしい。ついでに HD にアップスキャン＆スマートシャープかけてみたところ、さすがに 40分くらい掛かったけどそれでも実時間の6割強で済んでる。
そんなわけで、元の DVD、SD エンコ、HD エンコ、それぞれを MPC-BE の全画面表示で比べてみた。SD と DVD とでチャプターポイントからピッタリ2秒後に位置を合わせた。SD と HD はフレーム番号を揃えてるので全部同じシーンのはずだけどフリッカーがちょっとずつ違うような。そもそも HD だけ横に伸長してるような…あれか、SD と DVD は 704ｘ480 にクロップされてんのか。SD と DVD のスクショをを左右 21 ピクセルずつ削って 1920 ピクセルに伸ばせば揃うはず…だよな。中間作業は TIFF、最後に JPEG で保存（画質95）。
なおソースはアルバトロスの脱衣シリーズ『野球拳キャノンボール』。主演はおつむのユルすぎる早大生として引退後むしろ知名度を上げることになった川原里奈。お芝居の演技力もユルユルだったけど馬鹿正直で裏表のない子は案外嫌いじゃない、人生緩みっぱなしの元早大生、ギガ男爵である。ほか川菜ひかるに桃宮もも。お馴染みの川連廣明は残念ながら今回は姿を見せず。
ソースの DVD。もともとあんまり画質良くないようだ。
続いて SD。画像内のモニタの縁とか4回戦の文字見るとオリジナルよりきれいに感じる。単に質感が潰れただけの可能性もあるか。
HD リサイズ。スマートシャープ通しただけに SONY の文字とかコードとかのエッジはいちばんはっきりしてる。質感のディテールは SD より失われてるのがわかるけど流して見てるぶんには気にならんだろうな。
今回は元ネタのクオリティがイマイチで比較に適さなかった、というオチ。
2016-03-28 HD ソースからのエンコード
そろそろわしにとっての本線であるエロ動画に着手。まず前後半に分かれたエロ動画をひとつにまとめ、MP4 にしてみる。1本あたり 2時間で中身は VC-1 の Windows Media（ 5744Kbps の HD）、ASFbin で無劣化結合後のサイズは 10.1GB。コイツを NVENC でざっくりエンコード。自動ビットレートだとたいしてファイルサイズ変わらないけど、画質云々よりも処理負荷がどんなもんかを調べるのが目的。
ソースはアイエナジーの『「入れて」みたくてお股がヒクヒク！姉の愛液でチ◯ポはヌチュヌチュ！お姉さんに弟のチ◯ポを素股してもらったらこんなヤラしい事になりました。』（IENE-423）。この監督の作品、企画はともかくガサツで威圧的なしゃべりが目立ち癇に障るのが難点。
処理時間は 70分で実時間の3割以下。CPU の使用率は GOM Player で SD 動画を再生し、ブラウザも Chrome を 3つ開いてるのでエンコードそのものでこうなってるわけじゃない。エンコード中に GOM で再生中の動画がコマ落ちしたりシークが重くなるようなことはなく、Chrome もタブ 50個くらい開いてたけど何の影響も感じなかった。HD でも作業の妨げにまったくならない。
ただ 10GB はさすがにちょっと扱いづらいので、解像度はそのままにビットレートを半分の 3Mbps に落としエンコーダーを変えて同一圧縮率での画質比較してみた。といっても4時間丸々だといつ終わるのかわからんし、本編を載せるのはいろいろアレなので先頭の 30秒くらい。
エンコーダーは NVENC、x264、x265 で、NVENC 以外は 2pass。さらに x265 だけエンコードパフォーマンスを標準に加え高速、SuperFast、UltraFast も試してみた。
グラフにするとこうだ。
標準では実時間の 3倍を必要とする x265 だけど、パフォーマンス次第で処理時間にかなりの差が生じるようだ。高速（Fast）で実時間の倍、Ultra Fast に至ってはなんと実時間を切り、x264 の標準設定よりも速かった。こりゃ文字通りの爆速仕様だわ（ただエンコード範囲が変化の少ないシーンなので、実際にはもう少し伸びると思われる）。使うツールをかなり絞ってるとかかなあ。
パフォーマンスは 9段階（日本語と英語混在させるなよｗ）。x264 は 7段階だったけど、x265 で SuperFast と UltraFast が新たに加わった。なお“とても遅い”にするとツールをフルに使い各種検出精度も MAX に高められるので、文字通りとても遅い。標準と比べて処理に要する時間（まじハンパないぞ、ほんとにこれ動いてるのか？って感じ）に見合うほど画質が向上するわけじゃないし、他の設定に不備があれば破たんを起こすことだってある。同一画質でファイルサイズを極限まで小さくしたい場合には有効。
問題は画質である。GOM Player で 5秒後（150 フレーム目）の全画面表示をキャプって TIFF 保存したものを見比べてみた。ちなみに普段 H.264/AVC はデコードに CoreAVC 使ってるんだけど、CoreAVC は H.265/HEVC をサポートしていない（なんか CoreCodec、潰れちゃったみたいだね）。条件揃えるために今回はすべて GOM 内蔵のデコーダーを指定することにした。
条件揃えるなら DXVA なりの再生支援という選択もあるんだけど、GOM Player でハードウェアデコードする場合、レンダラーが EVR 限定という制約がある。わしはレンダラーに madVR を使っていて、ハードウェアデコード＋EVR と内蔵デコーダー＋madVR のどちらにするかちょっと迷ったけど、もともと GOM Player はデコーダー関係なくあんまり画質よくないので後者にした（だったら MPC-BE 使えよ、というお叱りはごもっとも。
縮小画像だとよくわからんが、拡大してもよくわからん。
これがオリジナルの VC-1（フレーム指定してキャプったんだけど他と微妙にズレてる）。
x264 2pass。ほんの少しだけ彩度が落ちてる。あとシャドウが多少甘い（地面のタイルの境界がところどころ緩んでる）。
NVENC。正直 x264 との違いがわからない。
x265 2pass。x264 とは逆に彩度が濃い。シャドウの再現は x264 よりしっかりしている。またオリジナルで白トビしかけてる輝度の高い部分が掘り起こされてる。
x265 2pass Fast。標準との違いはほとんど感じない。
x265 2pass Super Fast。ところどころディテールの再現が甘くなってる。
x265 2pass Ultra Fast。これもディテールが甘いけど Super との差はわずか。
ひとめでわかるのは彩度の違いで、H.264 と H.265 で逆なのは面白い（個人的には濃いよりは薄いほうが好み）。ディテールに関しては 1pass の NVENC が予想以上に健闘、x264 2pass とどっこいのレベルだが、どちらも x265 には劣る。彩度はともかく、わし的に x265 Fast まではぜんぜんおｋ。Super ＆ UltraFast もスチルで見比べると NG だけど劣化がなだらかで再生中ならスルーできそうだし、処理速度がこれだけ違うとものによっては画質とトレードオフしても選ぶ価値はあると思う。あるいは標準でもっとビットレートを削るという選択もあるか。
そんなわけで、間を取って丸々エンコは最速（Fastest）でトライ、コンプリートまで 8時間1分28秒掛かった。元が 4時間56秒なので倍ならまあどうにか我慢できる範囲だが処理中は CPU 使用率 100％なんだよね。やっぱ x265 は寝る前に放り込むような運用にせざるを得ないか。
“高速”との画質の差はプラシーボの範疇かな？
改めて先頭 35秒だけの処理時間を測ったところ、64秒とこれまた“高速”とは誤差の範囲。うーむ。
設定メモ：GOP 長とシークについて
わしのメイン使いの GOM、セカンドプレイヤーにしてる MPC-BE、検証用の VLC、いずれも基本シーク（キーボードショートカットの[→]）の移動量を 5秒に設定しているのだが、GOP あるいは IDR フレームの間隔が長いとシークがもっさりするわ“シークをキーフレーム単位”にすると K点超えジャンプの連続だわ、どうにもイライラする。TVMW6 のデフォルトだと標準 GOP 長は 250 で、30fps なら約 8秒、24fps なら 10秒。映画やアニメならいざ知らず、ピンポイントサーチした AV の抜きどころを GOM のブックマークに記録し続けているわしとしては、長い。長すぎる。
ウイルス混入騒動やら本国撤退やらあっても GOM Player を使い続けてる理由はちゃんとあって、GOM 以上に柔軟なカスタムブックマークを備えたプレイヤーが他にないんだよね。そのブックマークを記録してる関係上、設定で多重起動を許可してないので（ブックマークポイントをファイルへ反映する際、干渉してめんどくさいことになるのを避けてる）再生中に別の動画をチェックする場合は別のプレイヤーを使わざるを得ない。で、セカンドプレイヤーは定番の VLC よりフィルタまわりの融通が利く MPC-BE に落ち着いた。もちろん VLC も使うし、他に Qonoha とか Pot Player もインストールしてある。何も考えずに使ってる人もそりゃいるだろうが、GOM ＝情弱と決めつけるほうがよっぽど乱暴で情弱じゃないのかな。たぶん GOM に限ったことじゃなくて。
そんなわけで、普段わしは標準 GOP 長を 30 に設定してる。先の 30秒エンコも変化の少ないシーンが続いたこともあって 5秒後の 150フレーム目がピタリ I フレームだった。ちなみにアニメや濡れ場のない映画などピンポイントサーチの必要がない場合は 300 にしてる。短い GOP は全体の I フレームの枚数が増えるぶん P と B への割り当てが減って画質が悪くなるから、ビットレートを限界まで切り詰めるのではなく多少余裕を持たせてやるようにしてる。
...H.264/AVC の P フレームは GOP を超えた参照ができるのでシークは GOP や I フレームではなく IDR フレーム単位になるけど、少なくとも TMPGEnc シリーズに IDR 間隔の設定はない。シーク間隔に影響するのは標準 GOP 長のほか、“シーンチェンジ検出”関連の設定。
シーンチェンジ検出が有効だと検出したタイミングで IDR を挿入する。つまり GOP の境界になるので固定長 GOP にする場合はチェックを外しておく。わしは固定長にはこだわらないが、検出感度はいぢらないようにしてる。GOP 長が 30 なのであまり敏感すぎても困るのだ。
検出の強さを[弱い]、検出時間を[1秒]。GOP 長が 30 なので（ｒｙ映画やアニメの場合は 5秒にしてる。その次のキーフレーム情報云々だけど、ここにチェック入れるとカット編集画面でチャプターポイントをきっちり設定してもズレる可能性があるので、わしは無視してる。
参考：ソフトウェアによる評価測定
わしの目じゃ違いがよくわからなかったので、今回の各画像を SSIM で比較してみた。SSIM の計算結果は類似率なので以下のグラフもオリジナルに対するパーセンテージで示してある。巷では「ボーダーは 0.95 で 0.98 以上なら見分けがつかない」といった解説も見かけるが、1％の違いでも見た目にけっこう影響出てくるのでナメてはいけない。
全体の傾向はいずれも RGB より YUV のほうが優秀な値で、言い換えれば輝度よりも色の劣化が目立つということか。個別にみると RGB、YUV ともに最も高評価だったのは x265 2pass Fastest、低評価は x264 2pass という結果に。条件的に x265＞X264 となるのはわかるがトップが Fastest ってのはちょっと意外。まあ x265 2pass の標準、Fast、Fastest の3つは実際に見た目の違いもほとんど感じられなかったので、Fastest までは積極的に使っても大きく外すことはなさそう。あと NVENC の頑張りもきちんと証明されたｗ。
…画像比較のアルゴリズムの中でも SSIM はいちばん実用的だけど万能ってわけでもないし、動画の評価は時間軸の一箇所だけ取り出して判断できるようなものでもない。それを承知の上で使うなら便利じゃないかな。
2016-03-30 プリレンダリングキャッシュについて
TMPGEnc はプリレンダリングキャッシュ（カット編集時のプレビューとかな）の保存先を RAM か HDD か選べるんだけど、デフォルトが 16GB で RAM は物理的に不可能だから HDD にしてる。
これサイズ減らして RAM に置くのと量を維持して HDD に置くのどっちよいのか。ソースに拠る？そりゃごもっともだが、何か目安がほしい。ヘルプもそこまで触れてないのでひとまず概算してみると、フル HD 解像度の場合 JPEG 圧縮したフレームを 1枚 100KB 程度とすると 30fps なら 1秒あたり 3MB になる。1分で 180MB、1時間で 10GB。こりゃアカン、2時間超えるソースなんていくらでもある。レンダリングキャッシュだけで何十 GB も持ってかれてたまるか。
ま、必ずしも頭からお尻までバッファに溜め込んでおく必要はないから 2GB 程度でもそれなりに有用なのかもしれんが、そもそもわしのような使い方だと HDD でも今まで不便に感じたことはない。ほっとこう。これはたぶん、仕事で 4K ソースな複数クリップのタイムライン編集をするような人向け。X99 チップセットで RAM を上限の 64GB まで増やしレンダリングキャッシュ 32GB くらいにすると快適なのだろうが、幾ら掛かるのかソロバン弾く気にもならん。
既存ファイルのうち、Xvid＋MP3 や Vorbis な AVI でうまく MKV にコンテナ変換できないもの（この手の取り合わせは Mencoder が多いけど、不具合抱えてるのは PotEncoder が目立つ）をせっせと MP4 に移行中。自炊ブームが盛り上がった頃は選択肢が他にないので AVI コンテナのハックが流行ったのも仕方ないけど、未だに AVI コンテナを積極的に選ぶ理由ってあんのかねえ？
2016-04-06 YouTube
ニコ動向け動画はよく研究され再エンコード回避の条件も判明してるけど、YouTube では再エンコードは不可避のようだ。どうやら解像度によって割り当てビットレートの上限が決まっており、端的にいえば高解像度ほど BPP が大きいらしい。そのため YouTube 向けの動画はビットレートを上げるよりもできるだけ高解像度でアップしたほうがよい、とされる。
YouTube ヘルプ｜アップロードする動画の推奨エンコード設定
高さが倍＝面積は 4倍なので理屈でいえば 720p は 360p の 4倍、1080p なら 9倍だが、YouTube の推奨値は一定比率になっていない。
| タイプ | 標準フレームレートのビットレート | 高フレームレートのビットレート | BPP（標準 FR） |
|---|---|---|---|
| 2160p（4k） | 35～45 Mbps | 53～68 Mbps | 0.141～0.181 |
| 1440p（2k） | 16 Mbps | 24 Mbps | 0.145 |
| 1080p | 8 Mbps | 12 Mbps | 0.129 |
| 720p | 5 Mbps | 7.5 Mbps | 0.181 |
| 480p | 2.5 Mbps | 4 Mbps | 0.203 |
| 360p | 1 Mbps | 1.5 Mbps | 0.145 |
見事にバラバラだが、これはあくまでも推奨値であり、実際に再エンコードされた映像のビットレートは別の話。TVMW6 には標準の出力テンプレートに YouTube 向け設定が用意されていて、おおむね推奨値に近いビットレートがセットされる。そこで1280ｘ720 の HD 映像（30fps）をテンプレートの設定のままエンコードし、YouTube にアップしてみたのがこれ。
アップしたオリジナルのファイルサイズは 5.12MB だが、ダウンロードしてみると 1.45MB …ビットレートでいうと 5350Kbps から 1342Kbps まで圧縮されてしまった。推奨値はなんなんだって話だよなあ。
ここまではいろんなサイトで記事にしてるので、ほかにどんな差分があるか調べてみたところこんな感じ。
| 項目 | オリジナル | YouTube |
|---|---|---|
| プロファイル＆レベル | High@Level 3.2 (HDMV 互換) | High@Level 3.1 (HDMV 互換) |
| ビットレート（最大/平均） | 22 Mbps/5.702 Mbps | 21 Mbps/1.431 Mbps |
| VBV バッファサイズ | 2685 KB | VBV バッファ無し |
| 最大GOP長 | 30 フィールド (15 フレーム) | 120 フィールド (60 フレーム) |
| バッファリングフレーム数 | 5 | 1 |
| 最大参照フレーム数 | 5 | 1 |
| Pフレーム重み付け予測モード | 明示的 | 無し |
| Bフレーム重み付け予測モード | 明示的 | 無し |
ビットレート以外にもけっこう簡略化されてるのがわかる。
次は解像度を変えて割り当てられるビットレートの違いを検証してみるか。
2016-04-16
どうもおかしいと思ったら、UFEI で内蔵グラフィックスが無効になってた。
これでよし。
ざっと比較してみた感じでは、 QSV の“遅い”と NVENC の“標準”が同じくらいのパフォーマンス＆画質かな。ただ QSV はモノによって完走しないときがあるのが気になる。今のところ完走しない条件はまったく見当つかないが、映画など1時間を超える長時間ソースで引っかかることが多い。
そんなわけで、 YouTube ほか手持ち動画の Web 再生向けエンコで 30分以下の短時間のものは QSV , それよりも長時間のものを NVENC という使い分けをしている。
2016-06-02
先月24日の Ver.6.1.5.26 アップデートに今ごろ気づいた。まあ錬成するネタがなければ立ち上げないからねえ。大きな修正点は Intel Media SDK Hardware や NVENC による H.265/HEVC ハードウェアエンコードまわりのようで、わしにはあまり関係なさそうでごじゃる。ごじゃるが、手元に BD ソースがけっこう溜まりつつあるのでこれを機に片づけておくか。
2016-07-23
6月9日のプレスリリースに出たばかりの GTX 1080 によるエンコードベンチマーク結果が載ってるんだが、なんで H.264/AVC で比較してんの？比較対象も GM104 の GTX 980 ti ならそこは H.265/HEVC でしょうが。
H.265/HEVC で思ったほど差がつかなかったのかもしれんが、H.264/AVC は x264 標準設定で実時間切ってるわけだし、画質面で見劣りするハードウェアエンコードの恩恵イマイチと思うわけよ。意味があるとすれば NVENC を初搭載した Kepler 世代のボードや Radeon もベンチマーク対象にできることかな。GTX 650 / 680 / 750ti / 780 / 950 あたりも加えたらかなり参考になると思う（逆に Maxwell 以降しか載せないなら H.264/AVC で比較する意味はないよ。
それはともかく、アッパーミドルにGTX 1060 なんていう狼の皮を被った虎製品が登場したおかげで H.265/HEVC ハードウェアエンコ環境がけっこう現実味を帯びてきた。実勢 3万円台もさることながら、TDP 120W なら 550W 電源でもギリギリどうにかなる（ GTX 970 は 145W で補助電源が 6ピンｘ2なのよね。
ポイントは GTX 950 ( GM206コア )が H.265/HEVC ハードエンコをサポートしているかどうか。アンダー 2万円で補助電源不要ってやっぱ現実的なのよね。先まで見据えて 1060 奮発するか、無理せず 950 でいくか。まあノンサポートなら GTX 1060 一択なので「GM206 どうなんよ？」とペガシスに問い合わせ中。
2016-07-25
さっそくお返事が。GM206 コアで問題なく使えるとのこと。これで GTX 950 も選択肢に入ってきたわけだ（何せ GTX 1060 の半値だからなあ）。ついでに H.265/HEVC のエンコード比較も教えてもらえた。
Windows7 + Intel Core i5 6600 + GTX 1080 環境にて HEVC 速度を確認した情報（約 5 分の FullHD ビデオカメラ撮影映像を素材として出力）
- GTX 1080：75秒
- GTX 980Ti：92秒
- GTX 960：101秒
- x265 標準：901秒
- x265 UltraFast：457秒
Core i5 6600 を用いたのはひょっとして 4770 にパフォーマンスが近いのを考慮してくれたのかな？
さすがに速い！まあ圧縮率どんなもんかわからないので手放しで喜ぶわけにもいかんのだが、QSV より速いってのはほんとかも。GTX 1060 なら FHD でも 3.5倍速（ 100fps ）くらいは出そうだな。
それとすっかり忘れていたが大事なことがひとつ。NVENC の H.265/HEVC ハードエンコでは B フレームが使えない。リアルタイム配信であればレイテンシ面で有利にせよ、保存用エンコがそれでいいのか少々悩ましい。
あくまでも NVENC の H.264/AVC との比較ではあるが、Bフレームなしなのに H.265/HEVC のほうが画質がよいようだ。ただこれは（ほぼ）同一ビットレートでの比較なので、圧縮率優先だと厳しいかも。それでも“最速”設定で実時間の倍掛かる x265 よりはソソられる。
2016-12-11
職場復帰して懐に余裕ができつつあるのと、GTX 1060 6GB 版の最安値が 2万5千円くらいまで下がってきてることから、そろそろグラボ入れ替えかな。エンコのためだけに Pascal とかもったいないかもしれんけど、HEVC エンコードに対応した Skylake は LGA1151 だからマザーから入れ替えで最低でも 5万くらいはかかるわけだし、そこまでやって GTX 650 ってのも変な話なので結局十万円コースだろうし、Haswell 世代のテコ入れとしてはたぶん最適なんじゃないかな。
『サイボーグ 009 vs デビルマン』を BD からスマホ用に HD リサイズ中（浅沼晋太郎は、よい）。QSV で実時間の 5倍速くらいかね。
2017-01-20
公約通り GTX 1060 に換装。MPEG 系の処理は格段に速くなった！詳しいことはそっちで見てくれ。
上には上がおるよ！
2017-04-22
タイムライン編集モードで複数の画像クリップをサクッと均等配置する方法がわかんなかったんだけど、スライドショー使えばいいんだな。
ただこの場合も“均等配置”とか“等間隔に配置”ってオプションがあるわけじゃなく、クリップ（スライドショー）の全体設定で“ 全体の秒数÷画像の枚数 ”を自分で計算してやらないといけない。
ラジオボタンで“等間隔に配置” or “表示時間を直接指定”が選択できるようになるとええのう。
ちなみにスライドショーは全体でひとつのクリップとみなされる。タイムライン上で個別の画像を直接操作することはできない。
んまあ個別に操作したければ“クリップの編集”で追加も削除もできるから、さほど困るようなことでもない。
サントラ買う金なんてないもん
そんなわけで、ここんとこ毎日ゲームやってる。
脚注
- NVENC
- NVIDIA 製 GPU に搭載されているハードウェアエンコーダー。専用回路を利用するため高速なのはもちろん CPU や CUDA によるエンコードよりも低負荷かつ消費電力も低いといいことづくめだが、ハードウェアエンコーダーの常として同一ビットレートにおけるソフトウェアエンコードとの画質比較では劣る。また低ビットレート条件での画質は柔軟性に優れる QSV が勝る傾向にある。
- サポートしているのは Kepler アーキテクチャー、型番でいうと GeForce GTX 600 番台＝コアでいうと GK100 番台以降の製品。当初は H.264/AVC のみだったが現行の Maxwell 第二世代（ GeForce GTX 900 番台＝コア GM200 番台以降）から H.265/HEVC にも対応、理論上の処理能力は HD 解像度で 900fps、地デジの 30 倍速に達している（ B フレームを無くすことで処理を簡略化しているためレイテンシ面で QSV よりも有利に働くようだ）。
- 各種エンコードソフト以外にも rigaya 氏がフロントエンドを公開しているので、丸々エンコならこちらを使うのもありだろう。
- 参考：rigayaの日記兼メモ帳 NVEnc
- BPP
- ピクセルあたりのビット数。Bit/Pixel の略。解像度に依存しないビットレート割り当ての指標。BPP で確実に判断できるのは圧縮率で、実際に得られる画質はストリームの内容（シーンの動き）や用いるコーデック、解像度によって変わってくることに注意。
- アルバトロス
- プライムウェーブの関連会社。作品の配給及び販売やレンタルを行う。業界の冷え込みとともに21世紀のVシネをリードしてきた TMC、レジェンド ピクチャーズ、GP ミュージアムの旧御三家は失速していったが、入れ替わるように頭角を現すと彩プロや AMG エンターテイメントとともに新・Vシネ御三家の座に着いた。プライムウェーブ、アルバトロスに製作のニューゲート、声優・タレント事業のネクシードを加えた四社でひとつのグループを形成している。ただこのグループそれぞれの社の役割がいまいち外からだとわかりにくいので、あんまりアテにならないかも。
- SSIM
- Structural SIMilarity、構造的類似性指数。代表的な類似性の評価方法だった PSNR は画像全体の差分と部分的な差分の違いが表れにくく、さらにブロックノイズやぼけた画像であっても輝度の平均二乗誤差が近い値であれば指数が高くなるので人間の視覚と一致しない評価となってしまう。SSIM は座標のX軸Y軸方向の差分も判定材料にしているので人間の目の特性に近い評価を得られる。
- 注意が必要な点としては鑑賞基準となる値が非常に高いこと、わずかな差でも見た目にわかる違いと成り得ること。高画質と呼べるラインはおおむね 98％ で、画面でわかる違いが SSIM だと小数点以下の差でしかないこともある。
- x264 には SSIM を計算しながらエンコードするオプションがあるが TVMW6 は見事に無視している。ただ x264 の SSIM は演算をかなり簡略化してること、破たんしたフレームが混じっていても全体では高い指数と成り得ることには注意（フレームチェックは SSIM でやることじゃない）。
- 参考：AviUtlプラグイン「SSIM計算ツール」
- こちらは全フレームの平均値を算出するイマジン氏の AviUtl プラグイン、SSIM Calculater（※本記事で用いた SSIM Calculater は別のツール）。ざくっと傾向を把握するのに便利だが個々の値の分布まではわからない。