Mapping of CRF between x265 and x264?

[benwaggoner]

I know that CRF values between x264 and x265 can't be expected to match, or even have a simple relationship.

That said, has anyone played around with comparisons enough to get a sense of CRF values in x264 and x265 that result in roughly equivalent quality for any particular scenarios?

[gonca]

Presently running an encode. If you want I can post screencaps and settings for comparison.

[gonca]

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

[benwaggoner]

Relatedly, how about mapping of CRF between the 8-bit and 16-bit encoder modes? It seems (unsurprisingly) that the same CRF value yield a lot higher bitrates when encoding to Main 10 than to Main when using otherwise identical source and settings. Probably something to do with how CRF is an offset to QP, and actual quantization values will be relatively larger when you're starting with a lot more frequency data.

My "the kids are running around crazy and I can't think straight" guesstimate is that the difference should be 12 CRF, since each 6 QP represents a 2x change in the actual quantizer (at least in H.264...), and since 10-bit is 4x 8-bit, that'd be 12 QP steps to get a 4x quantizer difference. But I'm equally sure it's nowhere near that simple in practice...

[gonca]

Working on a different comparison chart with various xx-bit encoders. Do you prefer the chart in pdf or excel format?

[gonca]

Comparison part 2

[benwaggoner]

Comparison part 2
Interesting data. Looks like 8-bit and 10-bit x264 are quite comparable. But going from 8-bit to 16-bit builds of x265 have a huge delta. Rough ballpark around 6 steps? But once you're using the 16-bit build, there's not much difference between 10-bit and 8-bit output.

Good stuff!

[gonca]

Remember, this is one sample from one movie. More samples from different movies averaged out would produce more valid results. I would say that a set of predetermined set of movies, in their entirety, covering a variety of encoding situations would be ideal. However, if you look at the speeds you quickly realize that this is a time consuming effort. For the record I am using an i7 3930K @4.4Ghz.

[benwaggoner]

Remember, this is one sample from one movie. More samples from different movies averaged out would produce more valid results. I would say that a set of predetermined set of movies, in their entirety, covering a variety of encoding situations would be ideal. However, if you look at the speeds you quickly realize that this is a time consuming effort. For the record I am using an i7 3930K @4.4Ghz.
No doubt! The actual differential, if it is even consistent isn't known. But we can see from this data that there definitely is a big one with x265 10-bit versus x265 8-bit and x264.

It would be great if x265 could get whatever correction factor got implemented for the same situation in x264.

[gonca]

If you wish and are willing to be a little patient I could try and repeat the comparison with a different sample from a different movie. In fact you might want to suggest some movies and time frame(s) for comparison. Please bear in mind the speed of x265 at slow preset, or slower, if you wish that tested, on the length of the samples.

[benwaggoner]

If you wish and are willing to be a little patient I could try and repeat the comparison with a different sample from a different movie. In fact you might want to suggest some movies and time frame(s) for comparison. Please bear in mind the speed of x265 at slow preset, or slower, if you wish that tested, on the length of the samples.
I am certainly curious, and I can be patient for favors :).

Tears of Steel is a pretty good source clip for stuff that is readily available. The earlier Elephants Dream is also interesting and has some really challenging bits for CGI.

I don't know that preset should make that much of a difference as long as you're not setting any bitrate. I'd say initial tests using the default preset for both x264 and x265 would be fine. Or perhaps default x265 and a x264 preset that results in similar encoding time.

Generally different speed presets with CRF just result in slightly different file sizes, but similar quality.

However, my supposition is that CRF is ballpark similar between x264 and x265 8-bit, and it would require some serious double-blind visual comparison to determine a real delta. So the real question is the differential between x265 8-bit and x265 16-bit. Comparing 8-bit to 8-bit and 16-bit to 8-bit at the same preset is probably about as apples-to-apples as we'll get, and relatively straightforward. We may find a relatively predictable CRF ratio that gives the same file sizes.

[gonca]

I am presently downloading some 1080p and 4k clips, all legal before anyone asks, so we can get some more comparisons.

[gonca]

Comparison on crowd run 1080p50. Original has bitrate over 1Gbps

[gonca]

Ultrafast preset, same file size, crf comparison

[gonca]

low bitrate ABR comparison

[gonca]

high bitrate ABR comparison

[gonca]

For the double blind test, we can work on a semi official not technically correct test. I can encode the test clips, and if the members of the forum co-operate, not use mediainfo right off the bat, we could run an impromptu semi half double bind test

[easyfab]

or convert the files to x264 lossless ?

[benwaggoner]

It's interesting to note that bitrate goes UP significantly as the preset gets slower at the same CRF with x265. This is the opposite to the behavior that we'd expect, and that we see in x264. At a constant visual quality, more expensive encoding techniques should result in a smaller file size. Clearly CRF is acting quite weirdly in x265 overall, not just in the 16-bit v. 8-bit pipelines. PSNR and CRF are also less correlated with x265. Since x264 defaults to tuning for SSIM, perhaps we should compare both x264 and x265 using SSIM. And it's a better subjectively correlated metric anyway.

Comparing x265 to x265, encoding 16-bit to 10-bit versus 8-bit makes very little difference. In fact, the values are identical, which makes me wonder if a true 10-bit source wasn't used or something.

We continue to see a huge differential between 8-bit to 8-bit versus 16-bit to 8-bit, but it's not predictable by any CRF offset or anything. This may be due to CRF just not being fully tuned for 16-bit processing or something.

[gonca]

I have been using SSIM. The rate control in x265 is still a work in progress, which means that the 16 bit version might have a few issues, since it is a newer development. If you look at the low bitrate comparison x265 8 bit has the better SSIM value most of the time, and the other flavors of x265 have the lowest SSIM.

What do you think of my suggestion for the double blind tests?

[benwaggoner]

I have been using SSIM. The rate control in x265 is still a work in progress, which means that the 16 bit version might have a few issues, since it is a newer development. If you look at the low bitrate comparison x265 8 bit has the better SSIM value most of the time, and the other flavors of x265 have the lowest SSIM.
Yeah, that's probably the best we can do for easily calculated objective metrics right now. But I anticipate that SSIM will tend to relatively underrate x265 versus x264, as x265 (and probably HEVC in general) does a much better job avoiding temporal artifacts, which a single-frame metric like SSIM won't pick up on.

What do you think of my suggestion for the double blind tests?
I love double blind tests! They're the closest thing to something I actually trust :).

If you're worried about MediaInfo being used, you could also convert the clips back to lossless H.264 in 8-bit or 10-bit before distribution. That's how the Hydrogen Audio double-blind tests have worked, by converting back to FLAC IIRC.

[gonca]

If you can recommend a decent and free file sharing site, since Doom9 doesn't allow uploading of video files, I can work on getting the encodes done.
video > x264 > x264 loss less
x265

[gonca]

Let the double blind test begin

crowd_run_1080p50 ABR 1500 Kbps

http://www.mediafire.com/download/pfcyj2p5718du8y/crowd_run_1080p50_1_1.mkv

http://www.mediafire.com/download/f4sy78q8z8ubrkp/crowd_run_1080p50_1_2.mkv

http://www.mediafire.com/download/7t0jqjefn18f4n5/crowd_run_1080p50_1_3.mkv

[gonca]

crowd_run_1080p50 ABR 10000Kbps

http://www.mediafire.com/download/4lpccd3ye55dl5d/crowd_run_1080p50_1_4.mkv

http://www.mediafire.com/download/6gogjbblm9hzp4s/crowd_run_1080p50_1_5.mkv

http://www.mediafire.com/download/sfcb4bx98cf2a74/crowd_run_1080p50_1_6.mkv

[gonca]

crowd_run_1080p50 CRF 18

http://www.mediafire.com/download/94cvl59dmdfcyy9/crowd_run_1080p50_1_7.mkv

http://www.mediafire.com/download/gou6evkgs4zma37/crowd_run_1080p50_1_8.mkv

More samples to come

[gonca]

Second batch

crowd_run_2160p50 ABR 4000Kbps

http://www.mediafire.com/download/updfa7dukqbbu60/crowd_run_2160p50_2_1.mkv

http://www.mediafire.com/download/a0o3l4l0qr4kmew/crowd_run_2160p50_2_3.mkv

[gonca]

crowd_run_2160p50 ABR 20000Kbps

http://www.mediafire.com/download/eljl5vquygsnyb8/crowd_run_2160p50_2_5.mkv

http://www.mediafire.com/download/sm694akzabibpic/crowd_run_2160p50_2_6.mkv

[gonca]

crowd_run_2160p50 CRF 18

http://www.mediafire.com/download/a6sr72qc53cz7ns/crowd_run_2160p50_2_7.mkv

http://www.mediafire.com/download/64i02q8sftqs04a/crowd_run_2160p50_2_8.mkv

Feedback appreciated

[edison]

It look like the quality of x265 lost in the case that in same bitrate compare.

[gonca]

Updated the version of x265 for the double-blind samples. Try those.

[edison]

crowd_run_2160p50 CRF 18

http://www.mediafire.com/download/a6sr72qc53cz7ns/crowd_run_2160p50_2_7.mkv

http://www.mediafire.com/download/64i02q8sftqs04a/crowd_run_2160p50_2_8.mkv

Feedback appreciated

wow, 2800Mbps !

[vivan]

because lossless

[macromizer]

Updated the version of x265 for the double-blind samples. Try those.

Not to nitpick too much, but you do realize that a double-blind test means that the test giver doesn't know which sample is which, right? If you're doing all the encoding yourself than you know which sample is which and that means you're simply doing a single-blind test.

[gonca]

Not to nitpick too much, but you do realize that a double-blind test means that the test giver doesn't know which sample is which, right? If you're doing all the encoding yourself than you know which sample is which and that means you're simply doing a single-blind test.

That's why I previously referred to it as a semi double blind test.
I will not participate in the test, since I know which is which, and I have re-encoded the samples to x264 lossless so the willing participants don't know which is which. Lets not get too hung up on some issues yet since x265 seems to be changing quickly.

My function in these tests is to encode and upload and let other members offer their opinions on the samples.

[Blue_MiSfit]

My poor Q6600 CPU at work is belching smoke and flames trying to play these clips :)

I'll have to try my i7 at home!

[gonca]

I did notice that playback is just a little cpu intensive. I wonder how an i5 would handle it?

[benwaggoner]

I did notice that playback is just a little cpu intensive. I wonder how an i5 would handle it?
With WPP, HEVC decoding should scale to as many threads as the Mod64 height of the frame. And more recent processors certainly will get more pixels-per-clock than older ones.

[gonca]

With WPP, HEVC decoding should scale to as many threads as the Mod64 height of the frame. And more recent processors certainly will get more pixels-per-clock than older ones.

Pardon me for simplifying your statement, but HEVC encoding / decoding isn't meant for legacy hardware.

I'll try to encode some more samples this weekend for comparison, but uploading x264 lossless takes a few minutes.
If anyone needs to know which sample is which, let me know and I will PM you the info.

[gonca]

ducks_take_off_1080p50 ABR 1500 Kbps

http://www.mediafire.com/download/p4t9inwgc49kr24/ducks_take_off_1080p50_3_1.mkv
http://www.mediafire.com/download/xbmf02ebnjc7ddz/ducks_take_off_1080p50_3_2.mkv
http://www.mediafire.com/download/yy3kiq6ezu88ti5/ducks_take_off_1080p50_3_3.mkv

[gonca]

ducks_take_off_1080p50 ABR 10000 Kbps

http://www.mediafire.com/download/lbwfqqmm2i4atvv/ducks_take_off_1080p50_3_4.mkv
http://www.mediafire.com/download/tslgppgpzxzdz6p/ducks_take_off_1080p50_3_5.mkv
http://www.mediafire.com/download/4270sub4bxyht3b/ducks_take_off_1080p50_3_6.mkv

[gonca]

ducks_take_off_1080p50 CRF 18

http://www.mediafire.com/download/383438n0vmiv1ka/ducks_take_off_1080p50_3_7.mkv
http://www.mediafire.com/download/ov1djku9aug9thm/ducks_take_off_1080p50_3_8.mkv

Feedback, and opinions welcome.

[gonca]

ducks_take_off_2160p50 ABR 4000 Kbps

http://www.mediafire.com/download/l1buat5s3rxev12/ducks_take_off_2160p50_4_1.mkv
http://www.mediafire.com/download/24393nrr94s0kp1/ducks_take_off_2160p50_4_2.mkv

[gonca]

ducks_take_off_2160p50 ABR 20000Kbps

http://www.mediafire.com/download/3ja4z7p13icbw9o/ducks_take_off_2160p50_4_3.mkv
http://www.mediafire.com/download/kmbspb6ssamiee5/ducks_take_off_2160p50_4_4.mkv

[gonca]

The CFR 18 files encoded to x264 lossless are huge (4GB). If someone is truly interested in comparing them I will upload them.

[gonca]

Here is the pdf showing which file was encoded with each encoder

[benwaggoner]

This new commit suggests that the 10-bit QP mapping has changed or is changing:

https://bitbucket.org/multicoreware/x265/commits/3a19a9fdb103979e65a9daf15c46c0735e8d743e

The what and why are as mysterious as always though. What I wouldn't give for some more detailed comments along with these commits :)! Probably only one out of twenty gives much of a hint as to the potential real-world impact of the change.

[gonca]

After a while I can always repeat the process. Just figure I'll let things settle in a bit first, allow for some of these changes to be stabilized somewhat, like psy-rd. One thing I've read is that setting CTU=16 for SD and CTU=32 for HD might help with detail retention. Might try that soon.

[benwaggoner]

After a while I can always repeat the process. Just figure I'll let things settle in a bit first, allow for some of these changes to be stabilized somewhat, like psy-rd. One thing I've read is that setting CTU=16 for SD and CTU=32 for HD might help with detail retention. Might try that soon.
I think we can exclude psy-rd for the moment. But yes, a lot of stuff does seem in flight right now.

I think comparing just --preset medium with stock settings using the same 8-bit source and comparing Main and Main 10 in 8-bit is a reasonable test. But if they're already trying to fix this, no need to sweat it until they say it's done.

[gonca]

A quick test comparing CTU=32 and CTU=64 on a high def source might be interesting just to compare the effects on detail retention. The problem right now is that we are thinking of the x265 options in terms of x264, and realistically, they probably behave differently.

[benwaggoner]

A quick test comparing CTU=32 and CTU=64 on a high def source might be interesting just to compare the effects on detail retention. The problem right now is that we are thinking of the x265 options in terms of x264, and realistically, they probably behave differently.

--rdpenalty might also be a relevant parameter to impact this behavior. --rdpenalty 1 uses rate distortion in choosing 32x32 TU.

Docs:
--rdpenalty <0..2>
Penalty for 32x32 intra TU in non-I slices. Default 0

Values: 0:disabled 1:RD-penalty 2:maximum
I've wondered why the non-RD mode is the default. Almost by definition, RD is going to be better than non-RD.

[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