はっきり言って謎需要でもあるし、最初から4Kで録画して処理している人からすればそんなことで騒ぐのかという話でもある。
だが正直3840*2160で4K動画を作ろうとしたら、自分のr7-3700Xですら5分の動画→40分x2(2-pass)エンコードにかかるし、その間ずっとCPUは100%でアチアチである。定格固定クロックで頑張っているなら別だが、自動OCで4GHz到達しようものなら80℃の超高温に跳ね上がってしまうだろう。
一応映像と音声のエンコードの順番を決められるAviutlみたいなソフトなら”同時にエンコード”することで100%にならないので超高温に跳ね上がるのを抑えられる。がエンコード時間は若干延びる。
なのでCPUの冷却に自信ニキではないというなら、なんちゃって4Kや3Kで動画をつくった方がまだパソコンにもやさしいし、これから先夏場になれば部屋の温度も上がるのでパソコンにガンガン排熱されるとしんどくもなる。なので一助になればよいと思い表を作ってみる。
4K動画のエンコードなんぞ屁でもないという人は帰っていいです。
画像解像度 ヨコ |
画像解像度 タテ |
備考 |
1600 | 900 | HD+ |
1760 | 990 | |
1920 | 1080 | 1080p (FHD/Full-HD) |
2560 | 1440 | 1440p (WQHD) |
2880 | 1620 | 3K |
3008 | 1692 | 3K (QHD+) |
3072 | 1728 | |
3200 | 1800 | QHD+ |
3520 | 1980 | |
3840 | 2160 | 4K |
当初このセルをエクセルでつくっていたのだが、「TAG index」というサイトの「ExcelのHTMLテーブル化」(web便利ツール)を使って簡単にブログ用の表に変換できた。謝謝茄子!
勘のいい人は気づいたかもしれないが、これは[タテ+18/ヨコ+32]の比率を守って足し算すれば最適な画像解像度を計算することができる。
”最適な”というのも、H265の場合は画像解像度が奇数になっても動画エンコードがうまく行くが、H264の場合奇数が入るとエラーでエンコードできない。ましてアップコンバートする場合、指定の画像解像度に合わせて元動画を伸ばした際に、この縦横比が維持されてないとたてながだったり横長だったりして元動画と形が変わってしまう。なので適当に計算せず、なおかつ偶数・偶数で画像解像度が設定できるのが良いのである。
まあ身も蓋もない言い方だが、1920x1080の出力が難産でないのなら2560x1440もそこまで厳しいコンディションにならない。
差分を考えれば想像しやすいが、例えば1920x1080を2560x1440にアップコンバートするというのは、タテヨコを各々1.33倍に拡大処理することに等しい。つまり面積的には1.33^2=1.7689倍、2倍に満たない程度の拡張だ。なので3K(2880x1620)ですら1.5^2=2.25倍程度の拡大処理で済む。そう考えると1080pを4Kに変えるということは縦も横も2倍にするわけだから面積は4倍に膨れ上がる。処理が手間がかかるというのも当然といえば当然である。
※コメント投稿者のブログIDはブログ作成者のみに通知されます