handbrake 265で再エンコ

ハードディスクの空容量確保のため、264なmp4を265へ変更する計画その2。
前回ビットレート3600kbps程度の30分映像をhandbrakeでエンコしまくったおかげで、画像劣化も(見た目)なく1/3程度に圧縮できた。
ryzen 1700のおかげで時間も想像よりも1本10分以下と、かなり早く終了することができた。

今回は6000kbpsなフルHDをエンコしまくる計画。
前回と同じhandbrakeのエンコ設定だと、若干輪郭が破綻する箇所が見えた。
品質を26から21へ変更。
字幕も今回は設定し、音声の5.1chはステレオに変更。
品質が22とどう違うか比較してみたがどうも違いがわからないし、容量も差異が大きくなかったうえ、目標の元映像の1/3程度になったので品質はこれで良しとした。

ただ、要注意なのはQSVを利用した265。
これは常用している仮エンコと同じ傾向で、処理が早い代わりに圧縮率が犠牲になるようだ。
10bit QSVも似たもので、264から圧縮率が2/3程度にしかならない。
品質を26まで上げると264よりも容量が増えてしまう…。

実時間2時間半の映像だと、
QSV では0.8時間
265 では1.1時間
となり、画像並びに処理時間を考慮すると、あまりいいところがない。
やはり小さい動画の仮エンコにはQSVはもってこいなのだが、保存用には向かないように感じる。

265は今回coffee lakeな8gen i3でエンコしているので時間がかかっているが、ryzen 1700ならもっとはやくできるはず。
cpu使用率は98%程度でほぼフル活動。

QSVを使うと60%程度になり、代わりにGPUが90%近くになる。

タスクの開始を遅延させる

以前から続くパソコントラブルに、泣きっ面に蜂な出来事。
そんな波乱に満ちた日々に、少々呆れかえるとともに悲嘆に暮れる暇もないわけで、しかしそれは今度の記事にとっておくとして…。

エンコマシンとして退役させたAMDなパソコン。
仕方なくメインPCとして復帰してもらうことにした。
もちろん臨時である。
とはいえバトンを渡すべきRYZENが本体&マザー共に入手不能な状況がしばらく続きそうな状況(在庫無し)なので、しばらくはこれを快適に使えるようにしておかねばならない。

さて、本題。
エンコマシンとしてはCPUがパワフルにエンコ処理でき、編集画面ではSSDでストレスなくスクロール可能だが、他方のもろもろは年代物ばかり。
とくにシステムを入れているハードディスクは、260GBの古いノートPCからはぎ取ったもの。
スリープ必須なわけである。
しかも、不意の電源断でも電源ボタン一押しでエンコは処理していかないとHDDがいっぱいになってしまう。
なので、TMPGencをタスクスケジューラに登録している。
バッチエンコードツールはエンコのためであり必須、それとプリフェッチ用に仮に起動しておくための本体のソフト二つ。

起動ごとにその二つが重なって起動してしまい、ただでさえ遅いシステム起動が重なって、ライセンス確認が通らず(タイムアウトかな?)、バッチが止まってしまう。
タスクのトリガーで、「遅延時間を指定する(ランダム)」にて一分を共に設定しているのがまず間違い。
時間差を設定、特にバッチツールを優先的に早く、システムがアイドリングに到達する頃に起動する必要がある。
なにしろ、電源断でも深夜電力時間帯にBIOSから起動するようにしてあるからだ。(スリープ解除も同様に設定してある)
まずはタスクの遅延設定を変更してやろう。

ん?
30秒間、一分間、30分間て…。
間隔開きすぎですよ…。
一分ですらシステム安定しないし、30秒なんて意味をなさない。
30分は…(唖然)。

色々探してみるが、イベントとかを見てもそれらしい項目はどこにもでない。
おや?
イベントやログの項目にxmlのタブがあるでわないこぉ。
さらにここで、タスクのエクスポートが目にとまる。
試しで該当のタスクをエクスポートしてみる。
「編集」で中を見る。
ビンゴ!
既述を楽にするためにあのようなプルダウンメニューにしてあるが、マニュアル設定ができるようだ。
一分間に設定した場合、

<triggers>
中略
<delay>PT1M</delay>

となっていて、PT1M=1ミニッツですな。
これを書き換えて、バッチを2分、本体を4分に書き換えて、タスクのインポート。
びんびんビンゴ。
現在ばっちり時間差で起動できるようになっている。
まぁ、ちょっとしたことだし、本体の起動なんて30分後でも良いっちゃ良いのだが、これで快適になったのだし、全て丸く収まった。
うんうん。

しかし、SSDになれると、古い2.5インチHDDは現状拒否感が湧出するほどに遅い。
なるだけ電源を落とさないように使っていこう、RYZENが来るまでは。

win10 にリモート

RDP パッチをあててwindows7 homeで通常使えないリモートのホストを使えるようにして運用してきた。
ある時期のウィンドウズアップデートにより、使えなくなる事象にぶち当たり、以来アップデートを無効にして使ってきた。
もっぱらエンコのみの稼働なので問題は感じなかったが、画面のポップアップもうざいし、ものは試しとwindows10にアップグレードしてみた。
もちろん、アップ後のwin10も無印なのでホストは不可。

しかし、事前に使えるであろう対策は検索済み。
mubiの日記: Windows10 Home でもRDPのホストに
上記を筆頭にいろいろ出てきて、どれもRDP Wrapper Libraryに繋がっていくし、ヒット数(=試行数)もかなりのもの。
(ちなみに参考にしたサイトを忘れてしまった…)
そんなわけで、同様のプロセスを実行したわけである。

すんなりできた…、わけではなかった。
接続はできるのに、ログインできない。
なんで?
パスワードを使わないログインを許可していたからかと思って、パスを設定してから接続してみたが同じ結果に。
何か他に設定が必要なのか?としばらく混乱。
と、画面を眺めていて気づく。
ログイン資格情報のユーザー名に、「マイクロソフトアカウント¥ユーザー名」とある。
このユーザー名の前がいらないんじゃ…。

ビンゴ。
ユーザー名の扱いが問題だった。
接続する側はアップグレードしていたわけでなし、何故かはわからないがとにかく解消できた。

大事な使用感の方であるが、以前より劣る、かな。
パッチでwin7を運用していたころは違和感なかったが、映像編集に肝要なスムーズな画面遷移が若干カクつくようになってしまった。
とはいえ許容範囲でもあるし、7に戻さずこのまま行こうかと。

J1900でQSV

tmpegenc vmw5ではAMDのFX8350を使っているのでQSVを使うことができない。
エンコを早くしたいからといってQSVのためにintel cpuを買うのももったいない。
それに保存用ならエンコードにQSVは使わない。
でも一時視聴用ならやっぱり速いQSVがいいなぁ。

そんなことも考えてQSVが使えるQ1900B-ITXを選んだ。
とはいえ、TMPGenc VMW5をもう一個買うのはちょっと違う気がするので、MediaEspresso7を試用してみた。

フルHD(1920か1440)をHD(1280*720)に、ビットレートは3Mとしている。
29.97fpsにして、他の細かい設定はデフォルト。
TS → mp4

早速QSVを使用してエンコ。
さすが速い。
放送時間1時間の番組が、8分弱で完了。
30分の番組が、4分弱で完了。
他にも数本試してみたが、エンコード設定が変わらないからか、大体7.5倍速でエンコードできる。
若干カクツキがあるように見受けられるが、問題なさそう。
mediaespresso
ファイルサイズは、1/2から1/3になる。
過去調べてきたQSVの特徴から予想できた通り。

80plus gold電源に交換してから、消費電力が一番高い結果になったのがQSVエンコードだった。
アイドルで20W程度なのだが、エンコード中は33W。
それでも電力効率で言えば、FX8350のTMPGencよりも良い。
エンコード対象を画質と圧縮率で選考すればTMPGencとmediaespressoを使い分けができそう。

FXの電圧を再設定

TMPGenc VMW5でのエンコのために使っているAMD FX-8350。
これの動きがおかしい。
以前は3バッチ同時処理くらいでシステムが落ちていたのだが、2バッチで落ちるようになった。
2バッチで落ちることは無かったのだが…。

タイミング的には水冷CPUクーラーの導入が怪しい。
そう踏んでHWMonitorで温度をモニタリング。
prime95でCPUに負荷をかける。
しばし静観。
室温が冬場で低いことを考慮しても、最大34℃程度で安定している。
ラジエターを全解放の5インチベイに設置とはいえ、筐体内にレイアウトしているせいで長く負荷をかけていると筐体内に熱がこもってくる。
そうなるとごくゆっくりと(35℃以上)温度も上がってくることを確認。
だが、止まるほどのことではない。

が、しかしよく見るとCPUコアが何個か、負荷テストを停止している。
最大で2個停止。
あれ?

早速BIOSで確認してみると、ほとんどがAUTO設定に…。
turbo coreとかcool ‘n quietとかdisable設定してなかったっけ?
いつの間に…。
最近はまとめて一気にエンコすることが無くなったので、負荷も大したこともなく、そこまで気が回らなかった。

電圧をデフォルトより少し上げてprime95でテスト。
止まる。
またBIOSで電圧を上げてテスト、と繰り返すこと数回。
coreを1.4Vで設定すると数時間の負荷テストでも問題なくなった。
うちのはこの電圧が最適の様子。

試しに、prime95で全コア負荷をかけながらエンコを試してみたが、落ちることなく完遂。
どのタイミングでデフォルト設定になったんだろう。
ともかく現在快調。 😎

待ってたぞ、TMPGEnc Movie Plug-in Commercial Candidates Detector for TVMW5

タイトル長い…、商品名長い…。
もっと短くできなかったのかね。

TMPGEnc Movie Plug-in Commercial Candidates Detector for TVMW5
アドレスから推測するに、短縮名はTPCDなのか?
ともかくこのTPCD。
今まで知人のTMPGEnc MPEG Smart Renderer 4の機能に指をくわえてよだれを垂らしてやせ我慢をしていたのだが、どうやらよだれを拭き取る機会に巡り会えたようだ。 😳

一週間試しで使ってみて、「これはイイ!」 😯
バッチ登録して検索をする時間を含めて、最終的に自分で編集する時間を以前と比較するに、編集作業に慣れた身には残念ながらやはり手動の方が断然早い。
しかし、他の動画をエンコード中についでにバッチ処理できる、つまりは離席しても作業をしてくれているというのは助かる。
これが一番いいところ。
試す価値あり。 😆

<2013.12.22追記>

試用期間と実期間で10日くらいか?
使ってみてとても便利。
ただし、万能ではない。
ものによっては無駄なキーフレーム乱造で、見落としもある。
それでもやっぱり便利だなぁ。
ついでにいえば、取りこぼしてエンコードした部分はレンダラーの方で後から修正できるという安心感もある。
😉

エンコード用SSDの容量

AMD phenom 960T BE(6コア化)からFX-8350へ変更してからハードのマッチングがずれた。
どうずれたかというと、全く持って私の環境独自のものであるのだが、割安な深夜電力を利用できる時間内で処理できるCPU能力とそれに付随するSSD容量のバランス。

SSD_youryou
TSファイルからmp4へTMPGencVMW5を使用してのエンコード。
120GB(実質111GB)で960Tだとちょうどの時間で完了できる能力だったが、今では二時間程度早く終了する。
それだけ効率化した証左なのだが、今までがわかりやすかっただけに使いづらい。
単純に計算して20~30GB増やせればいいが、そんなサイズのちょうどいい容量がない。 🙁

ちなみに、エンコードを速くするためにSSDを導入する効果は少ないと思われる。
結構な処理能力のCPUで、同時処理エンコード数を上げていけばHDDのシークタイムよりも絶対的に短いから効果があるだろうが、それはむしろ記録ハードがCPUなどに追いついていないだけのことで、SSDにすればそれを解消したに過ぎないだろうし。
それよりも編集画面での表示スピードが向上するおかげで効率が上がるというメリットの方が大きい。
RAID0なHDDならSSDと遜色ないが、私はシークの多発を抑えるために一度SSDに転送してからエンコードするように変更した。
RAID0なうえにマスターのバックアップがないので、リスク回避目的で。

<2013.09.17追記>

windows7のシステムディスクとプログラムファイルフォルダ、エンコードtempフォルダなどを40GBのHDDでまかなっていたが、たまにtempフォルダから溢れてエンコードがエラーで終了することがあった。
やはり容量が少ないのは厳しい。
そこで上記の検証も含めて、250GBの2.5inch HDDへお引っ越し。
そもそもちょうどよい容量のSSDがあればそれが一番だったが…。

todo backupで移動。
変更はHDDのみ。
ADATA AS510S3-120GM-Cやramディスクは変わらず。

ただし、40GBのHDDの転送速度が遅いからといって、検証に使うには少々古すぎる。
実用に耐えない、現実離れした小容量HDDは検証しても意味がない。 🙄
単純にシークの発生する同時処理で検証。
TMPGencの設定「先読みキャッシュの設定」
「エンコード時に映像の先読みを行う」&「エンコード時に音声の先読みを行う」をオンオフで似た環境を作る。
cache

実情に合わせて三つのTSファイルをバッチ処理で同時処理。
サイズはフルHDからQHDへ縮小リサイズ。
cpu_fuka
フルHDのTSなので10~20Mbps前後、これが三つ同時(縮小リサイズでCPU負荷は小さい)にキャッシュ無しで読み込み、グラフを一目見てはっきり解るほどの違いではないが、全く同じ状況にも関わらずCPU負荷は若干少ない。
キャッシュオフだとHDDがボトルネックになり得る。

hdd
目で見てすぐ解るのがHDDアクセスランプ。
キャッシュ無しだとHDDランプが延々と点滅を繰り返す。
シークが間に合っていない。
一方、最大サイズ512MBのキャッシュオンだとほとんどアクセスがない。

これから至るに、サーバーCPUでなければエンコードのスピードアップのためにSSDの必要性はあまりなく、HDDで比較的新しいものなら必要充分な性能を有している可能性が高い。

tmpgenc vmw5でintel vs amd

知人のintel core i7 3770Kと今回導入したAMD FX-8350をTMPGenc VMW5で比較。
同一のTSファイルを同じ設定でベンチ。
わかりやすいように6分ジャストにカット編集してチャレンジ。 😛
両者ほぼCPU負荷100%。

i7 3770K
4:40
180W

FX-8350
4:52
260W

hikaku

ハード構成
i7 3770K
geforce GTX 660Ti
3.5HDD x2(たしか…)
80plus Bronze電源

FX-8350
geforce 210
3.5HDD x1
SSD x1
無印電源

結構肉薄している。
消費電力を見ると、無印電源であるのを勘案しても妥協できる。
経験上、無印を500W前後の80plus bronze電源に変更したら240W前後までいけるんじゃないかと。

いつもエンコでフル稼働しているなら比較するまでもなくintelの方が電力効率が良いので充分選択肢になるが、ほどほどの使用率なら出費からしてAMDでも良さそう。
AMDのマザーでスペックアップを狙うなら、intelに移行の夢を見る前に、i7より安いFXにしてその浮いた分を80plus Goldに回してしまうというのも現実的でありだろうと思った次第。

ちなみに、メインPCのスペック
i3 3225
geforce GTX 660(4画面出力)
SSD x1
2.5HDD x1
80plus Gold電源

i7 + 660Ti のアイドルが73Wくらいまで下がる(ディスプレイオフではない)ので、i3とi7(こちらは2画面出力)はほとんどアイドルでは違いがない。 🙂

960T→8350

メインPCで消費電力を下げるために短い期間で退役させた960T、結局TMPGenc VMW5でエンコにしか使ってこなかった。
エンコはそれで満足だったが、アンロックして6コア化していたものの、それでもintelの3770Kとは一段も二段も格下だった。
十年近くAMDのCPUばかり使ってきたのに、最近は急激にintelに傾倒。
でもエンコPCまでintelにするためにのマザーから一新するのももったいないし、そもそも3770Kや4770KだったらメインPCで使いたい。
ならここは一つ、エンコは深夜電力帯だし、あえてAMDを試してみようと画策。

FX-9000の5GHzな超ハイエンドCPU搭載PCがリリース発表されたものの、高値なのは間違いない。
で、現状手ごろな価格で且つスペックの良いもので更に手に入るCPUになると、興味も加味して、自然FX-8350となる。

で、エンコでベンチ。
10分のTSファイルをいつも行っているエンコ設定でベンチ比較。
CPUは100%でほぼ張り付き。
出力先は、速度の違いが出ないようにRAMディスク上に設定。
8350

phenom 960T BE(6コア)
11:00

FX-8350
7:46

ワットモニターで消費電力もチェック。
phenom 960T BE(6コア)
195W

FX-8350
260W

これを実時間と処理時間、消費電力量で計算すると、
phenom 960T BE(6コア)
実時間+10%
214W/本

FX-8350
実時間-25.4%
186W/本

効率は順当に向上している様子。 🙂
実際のエンコに関しては解像度などの設定によっては、バッチ処理で2~3同時処理とした方が良い場面に遭遇。
960Tだと2個同時がmaxだったのに…。
intel core i7 3770Kのようで、ニンマリ、である。 😛

遅くなったtmpgenc vmw5

先日ようやく
Ver.5.3.1.85

Ver.5.3.4.96
に更新した。

取り立てて不満はないし、何より「・x264エンコーダーを更新しました。」という更新内容も気になっていたからだ。
しっかり前後を確認してみたいと思っていたからだ。

で、実時間15分程度の動画をいつもの264なmp4ファイルにエンコ。
12.18(分、秒)

12.56
と数%ほど時間がかかるようになった。
そんなわけで更新当初はまぁこれくらいなら別にいいかって感じだったが…。 😐

phenomなエンコマシンで私の設定の場合、バッチ処理で2個同時までが有用な使い方だったのだが、数%ではないほどの時間がかかるようになってしまった。
感覚的には1.2~1.4倍程度時間が上乗せになった感じか。
128GBのSSDに入れた動画が深夜電力時間帯に終了できていたのが、現在完全に足が出てしまった状況。

で、調べたら、あった。
TVMW 5.3.4.96になってエンコード遅くなりました?
中でも「設定」のところで、1パスと2パスの違いがあるのでは?というところが気になっている。
何せ私も以前のバージョンの設定を覚えていない…。
というか、今更バージョンアップする遅さであるなら、エンコーダ更新がどうだったのか先に調べておくべきだった。 🙄
この記事、先に読んどけば…。

試しに1パスにしてバッチの並列処理を試してみようと思う。
なんだよ、比較用のプロジェクトも動画ももう消しちゃったよぉ…。 👿

<2013.06.08追記>

設定を1パスにしても変化なし。
そもそもエンコードで1パスを指定していたので、まぁ当然と言えば当然か。
友人の方(同じエンコ設定)でも試してもらったが同じエンコード時間という結果。
となれば、うちのエンコ設定の場合だとエンコーダーの更新自体の方が結果に関連あるということだ。

CPU負荷率に注視していると、以前は100%張り付きだったのが、80~90のあたりをふらついている。
バッチ処理で2個並列の場合もやはり100%だったものが、100弱くらいになっており、さらに23.976fpsなもの二つ同時エンコの場合に至っては何故だか80%前後の使用率。
以前なら100%張り付きだったが…。
仕方ないので現在は同時処理数を2→3に変更している。
今のところこれで以前と同じ時間で終わっている様子っぽい…。
ただし、正確な比較ではないので自信なし。 😥
プロジェクトを継承できない(更新履歴に記載)はずなので、ダウングレードしてエンコ時間チェック(プロジェクト保存)してから、アップグレードしてまたチェックという手間を惜しまなければ試せるが、しばらくは現状を静観しようと思う。

<2013.07.17追記>

現在の最新verが5.4.0.100。
割と短いスパンで出てきたので、対処されたのかもと思いリリース直後にテストした。
それの記録。
5.4.0.100
5.3.4.96
5.3.1.85

version

同じハードウェア構成で、同じファイルを同じ設定でベンチ。
CPUはいずれもほぼ100%。
変換元ファイルはTSファイルで、カット編集後の時間がうろ覚えで確かではないのだが、5分ジャストのもの。

以下pegasys更新履歴より
><不具合修正>
>・Ver.5.3.3.95以降でインタレース解除やリサイズ、または時間軸映像ノイズ除去が使用されている場合に出力速度が低下する問題を修正しました。

エンコ設定で「必要な場合インタレース解除」を有効にしているので、これが影響したものと思われる。
100はむしろ以前より早く終わっている。(ただし、マスターが短いためにこれが確証とも言えないなぁ)

上記結果から、現在は100で稼働中。 😉
ちなみに…、

以下pegasys更新履歴より
><機能更新>
>・TSファイル詳細読み込み時に、異なる音声チャンネルモードが混在している DolbyDigital 音声のデータを認識するようにしました。

以前までのverでは同じTSファイル内であるにも関わらず、5.1chの時に数コマほど2chになる現象にたびたび見舞われたが、手元にファイルがないので対処されたか不明。
そのまま結合して5.1chとして出力するとつなぎ部分で数コマぶっ飛ばされるので、仕方なく今まではTSを6chとして扱うことで回避していたが、もし改善されたのならうれしい。

<2013.07.31追記>

残念ながら、相変わらず異なるコンテンツと判断されることが多いようだ。 🙁