A’s Video Converter を再び試したらかなり良くなっていた件

本記事は最終更新日より 1 年以上経過しております。
スポンサーリンク

 約 1 年半前にもエンコードネタで A’s Video Converter を用いたハードウェアエンコードを紹介してみたが、昨晩 GIGAZINE が同ソフトを紹介していたのを見て、もう一度試して設定を詰めてみたらどうなるかなと試してみた。
 目的は TS ファイルの AMD VCE を用いた H.265 エンコードということに。

GPUを使ってH.265で爆速エンコードが可能な無料ソフト「A’s Video Converter」を使って4Kムービーをエンコードしてみた
CPU以上に並列処理が得意なGPUを使うと爆速でエンコードできます。無料エンコードソフト「A's Video Converter」は、Intelの「Quick Sync Video(QSV)」、N

A’s Video Converter の導入

 導入方法に関しては上記 GIGAZINE の記事が分かりやすく解説しているので割愛するが、筆者はインストーラー無し版を適当なフォルダに展開して使用している。
 ダウンロードは次のオフィシャルサイトより行える。特に Avisynth のフィルターを使用しないのであれば 64bit 版で問題無い。

A's Video Converter
AMD VCE、Intel QSV、NVIDIA NVENCに対応した動画変換ソフトで、ハードウェア(GPU)を利用したデコードやフィルタ処理にも対応しています。また、バッチ処理、簡易編集および自動変換機能等も搭載し、外部キャプチャソフトにも対応しています。

 TS ファイルのエンコード目的なので要点としては MARUMO ISDB Splitter をきちんと導入してスプリッタとして設定する事だろうか。

筆者の詰めた最終設定

 何を以て「詰めた」かというと筆者が日頃 HandBrakeCLI で x264 エンコードした動画の画質、ファイルサイズへ如何に近づけるかどうかである。HandBrake では「適当温存エンコ」と銘打って画質よりも何よりも速度とある程度見られる画質、そして適度に大きすぎないファイルサイズとなる調整をしている。HandBrakeCLI のオプションとしては「–cfr -q 21 –decomb –detelecine」をベースにリサイズやあれこれしている。

 エンコード/トランスコード設定は UI 上部にある「設定」より「トランスコード設定」から行う。
 順に説明してみよう。

ビデオエンコード


 変更箇所は赤線で囲ってある。
 筆者の GPU は Radeon RX470 なので H/W エンコードとしては AMD VCE による H.265 エンコードを指定した。
 レートコントロールは固定 QP とする。他にもある VBR だとビットレート指定しても指定した通り上手く行かなかった為。
 QP は I:24 P:26 B:25 とした。B フレームに関しては 25 固定となっていて弄る事が出来なかった。
 最大参照フレーム数は 6 としたが再生側の環境及びデバイスで問題が起きたら数値を下げた方が良いかも知れない。
 アスペクト比を PAR 4:3 としたのは後から理由を書いてみる。

 ・2017/03/13 画質調整に関する補足
 QP にある I フレームの値のみを順に下げていくと段々と綺麗になっていく感じとなった。動画の圧縮では I フレームを元に P フレームを生成し、更に P フレームから B フレームを生成するので、ベースとなる I フレームの画質を高める事で全体的な画質も高まる要領で。P フレームの画質を上げると途端にファイルサイズが大きくなるので敢えて弄らずにおいた方がいいだろう。
 この追記をしている時点では I:22 P:26 B:25 という設定をファイルサイズや画質との落としどころとし、エンコードを幾つか試している状態となる。
 エンコードされた画質をどう捕らえるかは個人によって変わってくるので、この辺を試行錯誤していくのも面白いかも知れない。

オーディオエンコード

 こちら割愛。デフォルトのままで可。筆者は NeroAAC を指定して LC-AAC にしている。

フィルタ

 フィルタのタブから「ハードウェア プリプロセッサ」にチェックを入れて設定をクリックする。
 出てきたウィンドウから次の様に設定した。

 筆者はエンコード速度を確保する為に 720p 再生するようなタイプなのでこの値にしている。TS ファイルに収められた映像は 1440x1080 となっており PAR 4:3 と指定されているので、実表示は FullHD の 1920x1080 になる。
 よってこの 1440x1080 をそのままの比率で 960x720 に縮小、PAR 4:3 とする事で実再生では 1280x720 になる仕組み。
 リサイズ設定で直接 1280x720 とするよりも映像データが小さくなる分だけエンコード速度を稼ぐことが出来る仕組みだ。

 デインターレースに関してはモード自動、フレームレート 2 倍、プルダウン検出とする事が一番インタレ解除の誤爆もなく、Fluid Motion を用いてもカク付かずヌルヌルになる事が確認出来た唯一の設定だ。
 以前本ソフトを試した時にはこのデインタレの性能に悩まされていたが、やっと今回解消出来たので記事を書く気になったと言うのが本音。それくらい重要な部分だった。
 フレームレート変換は 23.976 と指定する。理由は一番 Fluid Motion の補完するフレームが増える分、ヌルヌル度が増すから。

デコード


 重要な事は「ハードウェアデコードを使わない」という事。GPU にハードウェアエンコードをさせたいのにその一部リソースをデコードに使われるとエンコード速度が半減する為だ。必ずチェックは外しておく。その分 CPU が使われるが、その折り合い次第ではチェックを入れても良いかも知れないが。
 スプリッタには Marumo ISDB Splitter を指定。TS ファイルをエンコードするなら取りあえずこれにしておけば良い。

ファイルフォーマット

 基本的には内部 Muxer で問題はない。ただ、筆者はソース落として来て L-SMASH を自ビルドしつつ使っているのでそれを指定している。

実際にエンコードを

 ここまででやって来た設定通りに TS ファイルをエンコードする。
 ソースとしては偶々検証していたときに録画が終わった亜人ちゃんでもやってみるかなで行った。

 エンコード速度を求めつつファイルサイズを気にし、ある程度見られる画質に調整したらここまでになった!!
 同ファイルを HandBrakeCLI.exe でエンコードすると 15 分 51 秒かかり、ファイルサイズは 296MB になった。
 しかし、今回の設定による A’s Video Converter を用いた H/W エンコードでは 1 分 28 秒で終わってファイルサイズは 233MB と HandBrakeCLI の x264 エンコードよりも小さく出来た。
 これで求めている速度とファイルサイズの要件は軽くクリア。

 参考までに複数ファイルを突っ込んでエンコードを行うと、2 つ同時に処理するようで GPU をフルに使ってくれるようだ。トータルで見ると微妙に速くエンコードが終わるかも知れない。

 上記スクリーンショットのエンコード処理は TS ファイル 5 本で 2 時間 32 分の再生時間だが、全てのエンコードと Mux にかかった時間は 13 分 47 秒と爆速だった。エンコード速度より Mux 処理の時間の方が気になる状態に。

画質に関して

 AMD VCE エンコだと色深度が 8bit なので流石に 10bit と比較すると暗部のバンディングが気になってしまうが、それは HandBrakeCLI とも似た傾向であるし「適当温存エンコ」としているのだから気にするほどでも無い。
 一番の懸念事項は大きな動きのあるシーンチェンジに於ける大量のブロックノイズで絵が潰れてしまうことだったが、それも今回の設定弄りで凄く押さえ込むことが出来た。
 それでもやはり赤系の動きがある部分にはノイズが散見されたが、昔検証した時よりも遙かに検討している画質となった。故に画質面に於いても筆者の求める要件はクリアしたと言える。

 あまりエンコードした物を静止画として載せても参考になるか分からないが、細かい線なんかは次に載せるサンプルで多少わかるかなと思う。最終的な評価は動画として動いている物を見た上で行った方が良い。

 筆者個人としては HandBrakeCLI に取って代わってこっちで適当温存エンコをしてしまおうかと考えている状態である。
 しかし、どうもこの AMD VCE はゲーム配信の為のリアルタイムエンコードを目的としているような感じであり、TS ファイルなどのエンコードは今一苦手な感じもするので、そこは今後のアップデートでなんとかなってくれると良いなと。

 nVidia の H/W エンコードとかは今となっては分からないので、取り敢えず AMD VCE エンコ対応の Radeon を使っている人は是非一度こう言った設定で試してみると良いだろうかと思う。

VCE エンコのその後

 記事を書いた後もひたすら VCE エンコードを繰り返し、様々なソースの画質を見てみた。
 やはりというか暗くて動きのあるシーンがもの凄く弱く、いくら設定を上げてもブロックノイズやバンディングが発生してニコニコなんかでストリーミング配信動画を見ている感じに近い状態となるソースもあった。
 明るさのあるシーンばかりなソースだと特に問題となるレベルにまで画質が落ちているというような事はないので、VCE エンコではソースを選ぶという事になるだろうか。
 画質に関わる基本的な部分は AMF (AMD Multimedia Framework) という SDK なので A’s Video Converter 側ではどうしようも無い部分だろう。やはり AMF 側の改善を待つ他ないのかなと思う。

スポンサーリンク

『A’s Video Converter を再び試したらかなり良くなっていた件』へのコメント

  1. 名前:h265 変換 投稿日:2018/01/15(月) 10:29:52 ID:05d82f809 返信

    とても役に立つ情報でした。スッキリしました。
    ありがとうございます。

  2. 名前:new-designers 投稿日:2018/08/10(金) 12:17:12 ID:f4765172f 返信

    情報ありがとうございます。