Photo Gallery

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
今回は、x265 エンコード設定の中の、CTU サイズと動き探索範囲について
テスト結果をまとめてみた。
ソースは 720p の 24fps


-s/--ctu Maximum CU size (width and height)
Values: 16, 32, 64 (Default)



merange Motion search range
Range of values: an integer from 0 to 32768
Default: 57



予測ブロック階層 (intra/inter) は 4 分割に設定し、CTU サイズを 32 or 64 のパターンで検証。
そのほか ⇒ me=umh, subme=7, max-merge=5, rect, amp, bitrate=1500



■ CTU=32


動き探索範囲 は 16 - 64 の範囲で、8 ずつカウントアップ。
計 7 回のテスト結果がこちら。














ctume-
range
TIME(m)SSIMPSNRQPTIME
÷(SSIM×100)
RANKTIME
÷PSNR
RANKTIME
÷QP
RANK
321629.937 0.976341.88925.510.30610.71571.171
322432.4680.976742.00425.290.33220.77361.282
323234.6380.976942.07225.160.35560.82321.386
324033.8550.977142.12225.080.34640.80441.354
324833.0700.977242.17024.990.33830.78451.323
325634.268 0.977342.20224.930.35150.81231.375
326435.595 0.977442.22524.890.36470.84311.437

エンコードにかかった時間に対して、各画質評価の成績のコストパフォーマンスが良かった物に対してマーキングをした。
これによると、merange が小さいほど SSIM と globalQP 値の時間対効果は良く、 PSNR はその逆の結果を概ね示している。


ctu32graph.jpg

こちらは エンコード時間 と SSIM のグラフ。
いくらコストパフォーマンスが良くても、やはり SSIM にはそれなりの期待値を持ちたいので、こちらのグラフを参考に最適値を決定したほうが良いかもしれない。
個人的には --ctu 32, --merange 48 がベストな組み合わせだと判断した。



■ CTU=64


CTU サイズ 64 では、動き探索範囲 16 - 96 でテスト。




























ctume-
range
TIME(m)SSIMPSNRQPTIME
÷(SSIM×100)
RANKTIME
÷PSNR
RANKTIME
÷QP
RANK
641631.2150.97677 42.11126.140.32020.741101.192
642430.2230.97713 42.22125.920.30910.716111.171
643231.3930.97739 42.28925.790.32130.74291.223
644033.8630.97753 42.33625.700.34640.80081.324
644834.9500.9776842.38225.610.35760.82561.366
645633.9880.9777542.39725.580.34850.80271.335
646435.9970.9778442.42825.520.36870.84851.417
647239.3280.9779042.44725.490.402110.92711.5411
648038.3470.9779742.46325.450.39290.90331.519
648837.6180.9780042.47725.420.38580.88641.488
649638.5480.9780242.48825.400.394100.90721.5210

傾向としては CTU=32 の時とほぼ変わらない。
全体的に、 SSIM, PSNR の結果は向上し、エンコード時間は延びている。
QP 値が CTU=32 に比べて伸び悩む結果となった。


ctu64graph.jpg

CTU=32 の時ほどパターンが掴みづらいグラフになった。
CTU の柔軟さに対してテスト件数が少ないのかもしれないが、これ以上やってもキリがないので merange=96 で中断。
merange は増やせば増やすほど SSIM 向上、処理時間の増加。 x264 と変わりませんね
私は --ctu 64, --merange 56 がベストかな、と判断。
ほぼデフォルト値…




■ 結論


SSIM のコストパフォーマンスを求めるなら 動き探索範囲 は小さいほど良い
PSNR のコストパフォーマンスを求めるなら 動き探索範囲 は大きいほど良い
QP の向上を目的とするなら CTU サイズは 32 >64

個人的にバランスが取れていると思ったパラメータは下記
--ctu 32, --merange 48
--ctu 64, --merange 56







twitter
↑参考になったという方は、是非記事のツイートをお願いします



関連記事
【HEVC】 仕様についての走り書き
【HEVC】 HEVC と AVC でエンコード比較してみた
【HEVC】 RD(レート歪み最適化)についてのまとめ




スポンサーサイト

Tag:HEVC H.265 x265 比較 動き探索範囲 --ctu --merange

x265 の RD (レート歪み最適化) について、検証してみたのでまとめ


--rd Level of RD in mode decision
Range of values: 0: Least - 6: Full RDO Analysis
Default: 3


このオプションは、離散コサイン変換で失われた情報の回復を図るもので
今回 HEVC x265 では 0 - 6 の 7 段階調整することが可能であったため
それぞれの値について、速度SSIM を比較してみた。

今回も固定のシングルビットレート 1500kbps で検証。
その他のオプションも、ほぼ 前回 の記事と同様のものを使用した。

rd.gif

こちらがその結果をグラフにまとめたもの。
横軸が --rd の設定値、縦軸左がエンコードに要した時間 (分)、横軸右が SSIM
同一ソースだが 3 回ほどテストをして、大体同じ軌跡を描いていたので速度と画質の相関関係に誤りはないと思う。


<Original>
rd_original.png

<RD=0 最適化なし>
rd_0.png

<RD=6 フル解析>
rd_6.png

<RD=3 最高成績値>
rd_3.png




数値が大きければ大きいほど良いという訳ではないらしく、今回の実験ではデフォルトの 3 が最良という結果になった。
エンコード時間も 1 番短いようだし、3 以外を選択する理由が皆無。





twitter
↑参考になったという方は、是非記事のツイートをお願いします



関連記事
【HEVC】 仕様についての走り書き
【HEVC】 HEVC と AVC でエンコード比較してみた
【HEVC】 CTUサイズと動き探索範囲についてのまとめ



引用元:TVアニメ「変態王子と笑わない猫。」
©2013 さがら総・メディアファクトリー/「変猫。」製作委員会

Tag: HEVC H.265 x265 比較 RDO --rd レート歪み最適化 SSIM 変態王子と笑わない猫。

2014 年夏から ニコニコ動画 が HEVC に対応する らしいという話を聞いて、そろそろかなと思いテストをしてみた。
バージョンは下記を使用

HEVC: x265 1.0+85-f39484bb3eec 32bit 2014-05-21
AVC: x264 core 138 r2358M+r755[x86] release 1



■ オプション


可能な限り公平な評価ができるよう、同一ないしは近似値を指定した。
青色が同一パラメータ、赤色が差異パラメータ。
表記がない物に関しては、デフォルト値を使用している。

映像は 1 分 30 秒の OP アニメーションを使用し、どちらもシングルパスの固定ビットレート 1500 kbps でエンコードした。

・HEVC x265

動き予測:--me umh, --subme 7, --merange 64, --max-merge 5
Iフレーム:--scenecut 60, --min-keyint 24, --keyint 320
P,Bフレーム:--ref 9, --bframes 6, --rc-lookahead 40, --b-adapt 2, --bframe-bias 25, --weightb, --weightp, --b-pyramid
レート制御:--aq-mode 1, --aq-strength 1.1, --psy-rd 0.8, --cutree, --rd 4
ループフィルタ:--lft, --sao
ブロック・ユニット:--ctu 64, --tu-intra-depth 4, --tu-inter-depth 4, --wpp, --rect, --amp

・AVC x264

動き予測:--me umh, --subme 7, --merange 64
Iフレーム:--scenecut 60, --min-keyint 24, --keyint 320
P,Bフレーム:--ref 9, --bframes 6, --rc-lookahead 40, --b-adapt 2, --b-bias 25, --weightb, --weightp 2, --b-pyramid normal, --direct auto
レート制御:--aq-mode 1, --aq-strength 1.1, --psy-rd 0.8, --mbtree, --trellis 2
ループフィルタ:--deblock 0:0
ブロック・ユニット:--8x8dct --partitions all



■ ログ


I, P, B フレーム数が揃わなかったが、どこの調整を誤ったのかよく分からない。
内部処理的にこういうものだと言われればそれまでだが、画質に誤差が生じて評価し辛い。
それでもあえて比較すると、 QP に関しては一長一短な結果となり、 SSIM, PSNR は HEVC の圧勝。
AVC の B フレーム QP の結果が伸びているのは --b-pyramid normal, --direct auto 辺りがいい仕事したのかもしれない。
総合的に見れば、 HEVC の大勝。

・HEVC x265







FrameTypeFrameCountQP AveragePSNR Average
I2722.1445.13
P50524.9843.71
B162426.7443.74

PSNR Avg: 42.080
SSIM Y: 0.9765765 (16.303 dB)
エンコード時間: 42 分 43 秒
容量: 16,405,400 バイト



・AVC x264







FrameTypeFrameCountQP AveragePSNR Average
I2921.6943.67
P49924.9941.19
B162826.2041.12

PSNR Avg: 41.174
SSIM Y: 0.9750723 (16.033db)
エンコード時間: 4 分 46 秒
容量: 16,697,305 バイト



■ キャプチャ


勿論 AVC よりも HEVC のほうがノイズが抑制されているが
HEVC のほうは低周波領域において、強力な平滑化が施されているように見える。
CTU (64x64) の効果が発揮されているのかもしれない。

<Original> 拡大300% ニアレストレイバー法
x3_original.png

<HEVC> 拡大300% ニアレストレイバー法
x3_x265.png

<AVC> 拡大300% ニアレストレイバー法
x3_x264.png



次回は、RD (レート歪み最適化) についてエンコードした結果をまとめたいと思う。





twitter
↑参考になったという方は、是非記事のツイートをお願いします



関連記事
【HEVC】 仕様についての走り書き




引用元:TVアニメ「変態王子と笑わない猫。」
©2013 さがら総・メディアファクトリー/「変猫。」製作委員会

Tag:HEVC H.265 x265 AVC H.264 x264 比較 変態王子と笑わない猫。

あくまで読解中の情報なので信憑性の度合いはお察し。
誤っている可能性もあるので鵜呑みにしないで、取っ掛かり程度に参考にしてください。


情報源符号化部 H.265 | MPEG -H HEVC 規格の概要
 >>http://www.soumu.go.jp/main_content/000230399.pdf
x265 Evaluators Guide
 >>https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20March%2016%202014.pdf

符号化の処理単位
AVC:MB(Macroblock)→HEVC:CTU(Coding Tree Unit)
CTUのサイズは可変で、最大64x64画素ブロック(MBは16x16)

ブロック階層(--tu-intra-depth、--tu-inter-depth)はCUの四分木分割の回数
増やせばきめ細かなユニットでの処理が可能になる

MBの概念がCUに取って代わっている
AVC:--mbtree ≒ HEVC:--cutree

CAVLC/CABAC の選択はなく、全プロファイルで後者が採用されている

AVC:b-pyramid=strict ≠ HEVC:b-pyramid=1

RDO(レート歪み最適化)ビットレート辺りの品質向上化
離散コサイン変換で失われた情報の回復を図る。重い

rect = CUの分割(PU)に2NxN、Nx2Nの2分割長方形パーティションを選択可能にする機能
amp = CUの分割(PU)に2NxnUなどの非対称な動的パーティションを可能にする機能

max-marge = 動きベクトル予測機能の、予測ブロック候補数(最大5)
エンコーダが選択した予測ブロックの情報はデコーダにシグナリング(開示)される


H.265/HEVC動画の作成と再利用の方法
 >>http://www.katch.ne.jp/~kakonacl/douga/x265hevc/h265_hevc_video.html





関連記事
【HEVC】 HEVC と AVC でエンコード比較してみた

Tag:HEVC H.265 x265



WHAT'S NEW?

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。