Mapping of CRF between x265 and x264?

[gonca]

Let's use one parameter at a time. This will allow us to view the effects individually, and then we can try combining options. Like you said, x265 default, medium, with different CTUs and then we can try other options. This might help to visualize how different options affect quality, then we try combinations.

[gonca]

CTU comparisons

http://www.mediafire.com/download/kq6e484n21ga38u/crowd_run_1080p50_16x16.mkv
http://www.mediafire.com/download/rkjr69tly8xfsfq/crowd_run_1080p50_32x32.mkv
http://www.mediafire.com/download/hehsfcbd1w6max2/crowd_run_1080p50_64x64.mkv


http://www.mediafire.com/download/87ozz4348syrkah/ducks_take_off_1080p50_16x16.mkv
http://www.mediafire.com/download/ddgjar1z7dqgx52/ducks_take_off_1080p50_32x32.mkv
http://www.mediafire.com/download/icdpfd31z2y6jbb/ducks_take_off_1080p50_64x64.mkv

[a5180007]

Hi,

Why is the ssim of x265 --ctu 16 --crf xx so much below x264 --no-psy --crf xx ?
Isn't the same amount of information supposed to be removed from both signals ?

[gonca]

If you are referring to the post above yours, there is no x264 encode involved

[a5180007]

@gonca, I'm referring to your (earlier in this post) and other comparisons between x264 and x265 at various CRF or QP.

E.g. if I compare (the source does not matter too much)
x264 --qp 23 --b-adapt 0 --no-psy --bframe 4 --merange 57
x265 --qp 23 --b-adapt 0 --rc-lookahead 40

http://i.imgur.com/uCvSXNb.gif

The SSIM is lower even for the I-frames? I might get it wrong, but shouldn't the quantizer affect the I-frames the same way in both encodes -or even better with the improved HEVC loop filters?

EDIT : Sorry, I've tried to reduce the image, is there any bbcode tag such as \[img width="500"] that I can use?

[gonca]

CRFxx in x265 might not correlate to CRFxx in x264 in terms of quality. At least not yet. Rate control is a work in progress for x265, I believe.
Presently, it might be better to say x264 CRFxx > x265 CRFyy and xx and yy have to be determined.

[edison]

the bitrate gap between x265 to x264 is about 2.24 to 2.6 in my test.
For example, with a 1080p23.976 clip:

x265_x64 1.1+152
slow preset CRF 19 : 5341.15 kb/s,SSIM Y: 0.9815310 (17.336 dB)

x264_x64 0.142.2431
slow preset CRF 21.24: 5340.76 kbit/s (SSIM Y:0.9803749 (17.072db)

That is about 6.260% SSIM improve for x265 compare to x264 in this case.

[gonca]

They might still be working on rate control, so those numbers will change. Realistically, you need multiple tests with multiple sources to come to any conclusion.

[foxyshadis]

@gonca, I'm referring to your (earlier in this post) and other comparisons between x264 and x265 at various CRF or QP.

E.g. if I compare (the source does not matter too much)
x264 --qp 23 --b-adapt 0 --no-psy --bframe 4 --merange 57
x265 --qp 23 --b-adapt 0 --rc-lookahead 40

http://i.imgur.com/uCvSXNbl.gif

The SSIM is lower even for the I-frames? I might get it wrong, but shouldn't the quantizer affect the I-frames the same way in both encodes -or even better with the improved HEVC loop filters?

EDIT : Sorry, I've tried to reduce the image, is there any bbcode tag such as \[img width="500"] that I can use?

x265's bitrate is lower.

Also, Doom9's vBulletin version is too old to support anything like that. imgur, imageshack, photobucket, and flickr all provide thumbnailing. It's new enough that it doesn't completely break the whole forum, though, so it's not a big deal.

[a5180007]

x265's bitrate is lower.

Indeed, and at the same qp, with the bigger sizes of residual transform units this is expected. But why would the quality -especially of I-frames- be lower? With the greatly increased computational time, one would think that the intra search would be more efficient.

[foxyshadis]

Indeed, and at the same qp, with the bigger sizes of residual transform units this is expected. But why would the quality -especially of I-frames- be lower? With the greatly increased computational time, one would think that the intra search would be more efficient.

Again, the HEVC bitrate is lower. Quantization isn't the same between AVC and HEVC, even at the same transform sizes (which isn't the case for your comparison; AVC only uses i8x8 and i4x4, along with a special i16x16 that's a set of 5 i4x4, whereas HEVC will just do i4x4 all the way to i32x32). If you analyze even just the I-frames, you'll find that the size is much smaller, you can verify that by encoding or editing down to just the first frame and comparing sizes. By default, x265 will prefer larger block sizes that have a higher PSNR but slightly lower SSIM but are much smaller. This can be tweaked with --rdpenalty.

If you had the exact same data after prediction, the scale factors are very different, which means that a single QP quantizes differently. (Another big factor in why cqp size differs so much.) Even before that, the actual DCT is subtly different, so you get different values to be quantized.

You might be interested in running the files through CodecVisa (The Cloud version supports HEVC but not AVC) to see how radically they differ, and try raising x264's QP until the file size matches to see the SSIM difference, which makes the comparison more valid.

[a5180007]

@foxyshadis : understood, thanks for the explanation.
Even with --ctu16, x265 uses much more bigger blocks.
As seen below the rd decision modes are very different, and the only fair comparison is with I-frames of the same size.

I would have thought that the prediction search would return about the same residuals based on SATDs, but obviously x264 and x265 have very different strategies.

x264 --qp23 --no-psy
http://i.imgur.com/xKBqXWU.png

x265 --qp 23 --ctu 16
http://i.imgur.com/LuiIgnZ.png


EDIT : difficult to obtain the same I-frame size as qp has to be an integer. But even with a smaller I-frame size, PSNR is still in favour of x264:
x264 --qp 23 --no-psy , I-frame size 1546143 bits, PSNR 48.77 dB
x265 --qp 22, I-frame size 1610594 bits, PSNR 47.93 dB
Source is first frame of https://drive.google.com/file/d/0B4QaEqxOEYWvTmJjVXpVSmlyeFk/edit?usp=sharing
x265 1.1+192 x32 8bpp

EDIT2 : having played with various sources, I-frames predicts/residuals and PSNR are much similar to HM14 for the same size. Is x265 still using HM RDO/RDOQ, rather than one similar to x264 rdo/trellis including cabac cost?

[mparade]

@gonca/to someone who knows it

I would need your help.

How can I write encoding results to a log file in x264?

In x265 it is very simple by using "--log-level --csv" options. In x264 there is no such thing like "--csv" unfortunately, but I need to somehow write the encoding results to a file (calculated ssim numbers this case) to compare with the ones in the csv file of x265.

Do we have some similar command line option in x264?

Thank you very much for your help!

[raffriff42]

How can I write encoding results to a log file in x264?this:x264.exe <options go here> --tune ssim --ssim --verbose -o "out.264" "in.mp4" > "log.txt" 2>&1 produces this:x264 [debug]: frame= 0 QP=19.60 NAL=3 Slice:I Poc:0 I:3600 P:0 SKIP:0 size=49185 bytes SSIM Y:0.99472
x264 [debug]: frame= 1 QP=19.17 NAL=2 Slice:P Poc:8 I:803 P:1918 SKIP:879 size=21439 bytes SSIM Y:0.99266
x264 [debug]: frame= 2 QP=22.37 NAL=2 Slice:B Poc:4 I:119 P:1956 SKIP:1452 size=8149 bytes SSIM Y:0.99215
x264 [debug]: frame= 3 QP=23.35 NAL=0 Slice:B Poc:2 I:84 P:857 SKIP:2616 size=3433 bytes SSIM Y:0.99333
x264 [debug]: frame= 4 QP=23.18 NAL=0 Slice:B Poc:6 I:24 P:1416 SKIP:2130 size=3065 bytes SSIM Y:0.99096
x264 [debug]: frame= 5 QP=19.43 NAL=2 Slice:P Poc:16 I:294 P:2353 SKIP:953 size=17924 bytes SSIM Y:0.99166
x264 [debug]: frame= 6 QP=22.86 NAL=2 Slice:B Poc:12 I:98 P:2286 SKIP:1166 size=8707 bytes SSIM Y:0.99082
x264 [debug]: frame= 7 QP=22.14 NAL=0 Slice:B Poc:10 I:17 P:1221 SKIP:2326 size=2599 bytes SSIM Y:0.99065
x264 [debug]: frame= 8 QP=21.19 NAL=0 Slice:B Poc:14 I:18 P:642 SKIP:2924 size=1661 bytes SSIM Y:0.99283
x264 [debug]: frame= 9 QP=20.21 NAL=2 Slice:P Poc:24 I:264 P:2238 SKIP:1098 size=19134 bytes SSIM Y:0.99151...etc, easily transformed into csv form (just replace ' '(space), ':'(colon) and '='(equal) with commas)

[mparade]

this:x264.exe <options go here> --tune ssim --ssim --verbose -o "out.264" "in.mp4" > "log.txt" 2>&1 produces this:x264 [debug]: frame= 0 QP=19.60 NAL=3 Slice:I Poc:0 I:3600 P:0 SKIP:0 size=49185 bytes SSIM Y:0.99472
x264 [debug]: frame= 1 QP=19.17 NAL=2 Slice:P Poc:8 I:803 P:1918 SKIP:879 size=21439 bytes SSIM Y:0.99266
x264 [debug]: frame= 2 QP=22.37 NAL=2 Slice:B Poc:4 I:119 P:1956 SKIP:1452 size=8149 bytes SSIM Y:0.99215
x264 [debug]: frame= 3 QP=23.35 NAL=0 Slice:B Poc:2 I:84 P:857 SKIP:2616 size=3433 bytes SSIM Y:0.99333
x264 [debug]: frame= 4 QP=23.18 NAL=0 Slice:B Poc:6 I:24 P:1416 SKIP:2130 size=3065 bytes SSIM Y:0.99096
x264 [debug]: frame= 5 QP=19.43 NAL=2 Slice:P Poc:16 I:294 P:2353 SKIP:953 size=17924 bytes SSIM Y:0.99166
x264 [debug]: frame= 6 QP=22.86 NAL=2 Slice:B Poc:12 I:98 P:2286 SKIP:1166 size=8707 bytes SSIM Y:0.99082
x264 [debug]: frame= 7 QP=22.14 NAL=0 Slice:B Poc:10 I:17 P:1221 SKIP:2326 size=2599 bytes SSIM Y:0.99065
x264 [debug]: frame= 8 QP=21.19 NAL=0 Slice:B Poc:14 I:18 P:642 SKIP:2924 size=1661 bytes SSIM Y:0.99283
x264 [debug]: frame= 9 QP=20.21 NAL=2 Slice:P Poc:24 I:264 P:2238 SKIP:1098 size=19134 bytes SSIM Y:0.99151...etc, easily transformed into csv form (just replace ' '(space), ':'(colon) and '='(equal) with commas)

Your proposal works great when feeding x264 manually.
Thank you very much, your help is really appreciated!You saved for me quite a few hours or days of searching in the forums. :thanks:

[Shevach]

Comparison of x264 to x265 >>> preset, bitrate, fps. crf, ssim

i apologize on referring to the results reported about an year ago (i have just started looking this thread through).
i would like to know on what processor the results (fps) were obtained and whether WPP or tiles used or not?

[Music Fan]

i would like to know on what processor the results (fps) were obtained
i7 3930K @4.4Ghz ;
http://forum.doom9.org/showthread.php?p=1680044#post1680044

I am also wondering which x264 and x265 versions were used because I guess the results may change a little bit with more recent versions.

[benwaggoner]

i7 3930K @4.4Ghz ;
http://forum.doom9.org/showthread.php?p=1680044#post1680044

I am also wondering which x264 and x265 versions were used because I guess the results may change a little bit with more recent versions.
Compared with October 2014? Yeah, they'll be a LOT different! x265 is night and day better since then, with whole classes of psychvisual optimization added and tons of refinement and bug fixes.

Even x264 has gotten some minor quality tweaks since then.

[gonca]

i apologize on referring to the results reported about an year ago (i have just started looking this thread through).
i would like to know on what processor the results (fps) were obtained and whether WPP or tiles used or not?

Sorry for the delay
i7-3930k @ 4.4
WPP was used I believe

OOps
Music Fan already answered

[gonca]

i7 3930K @4.4Ghz ;
http://forum.doom9.org/showthread.php?p=1680044#post1680044

I am also wondering which x264 and x265 versions were used because I guess the results may change a little bit with more recent versions.

Don't remember the versions, but as benwaggoner said
x265 has seen many changes and those comparisons would have to be redone with up to date encoders to be meaningful

[Music Fan]

Ok thanks, thus I guess CRF 20 with x264 is probably not anymore as good as CRF 20 with x265.

[gonca]

Don't think there was ever a true relationship of that nature, where crf 20 @ med preset would yeild equal quality from x264 and x265

[Music Fan]

I believe it was an estimation done with SSIM results (which were close with CRF 20 for both codecs).

[gonca]

The only way to see where x264 and x265 stand would be to run new tests