Comparisons of x265 vs x264

[sneaker_ger]

Crowdrun 1080p50 (https://media.xiph.org/video/derf/y4m/crowd_run_1080p50.y4m) at placebo settings, ~9200 kbit/s.

Nothing new or surprising, x265 blurs details while x264 has other more pronounced artifacts.

x264 r2479 64 bit from Videolan
x265 r1.3+226 icl 64 bit from Chromashift

original (https://media.xiph.org/video/derf/y4m/crowd_run_1080p50.y4m)
x264 --preset placebo --crf 30.1 --keyint infinite --tune film --open-gop 10 bit (https://mega.co.nz/#!g4VACBrA!2wJcCk6Owc7IhySV1R5CaTBrqODOV_KjmeeFtk5F1mU) (0.5 fps)
x265 --preset placebo --crf 40 --keyint -1 --bframes 16 --ref 16 --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!R8cmCB5Q!RIWKvWaziVM9ZPfUQLqAUuK5lw-Oq3QxmerqRkHe8Dc) (0.05 fps)

http://abload.de/img/380_v4ucv.png
http://abload.de/img/380_x264_placebo_y0ut2.png
http://abload.de/img/380_x265_placebo_7uu5z.png

Both used 1 I frame but x264 used 75 P frames while x265 used 125 P frames.

[huhn]

is there a good reason why x265 make the picture more dark in general and it looks more red?

[foxyshadis]

is there a good reason why x265 make the picture more dark in general and it looks more red?

That's the HEVC decoder, not x265's fault. It's a good idea to always explicitly signal VUI characteristics, since apparently not all of them use the <=540 is BT.601, >540 is BT.709 rule.

[vivan]

Then this would be renderer's fault, but this is not the case since we're using madVR.

Probable he is talking about provided screenshots? By default x265 butchers chroma way more, maybe think this why it looks like this (but, honestly, it's the opposite for me - less detailed looks brighter).
U channel from screenshots above:
http://2.firepic.org/2/images/2014-09/23/s2tbnwxklh95.png
http://2.firepic.org/2/images/2014-09/23/91c0hjbmhnrb.png

[huhn]

histogram avg color:

x264:
lumi: 90.52
red: 95.18
green: 89.72
blue: 82.04

x265:
lumi: 90.37
red: 95.58
green: 89.34
blue: 81.64

if I look at these histogram data the x265 is not as bright as x264 but the red channel this has a higher value compared to the x264 encode.

I see a red tint in any color in the x265 screenshoot the white looks red compared to x264 screenshoot or the orignal source. even the trees look more red.
I think x265 does something wrong here.

[benwaggoner]

Personally, I don't plan on ever using 8 bit HEVC encoding since we already have hardware support for that...
Unfortunately there will be a lot of 8-bit only mobile chipsets in devices.

[lotusgg]

aq-mode 2 and psy vs aq-mode 1 and no psy
http://screenshotcomparison.com/comparison/93743

someone named 'x265' posted it on a chat, credits to him.

[huhn]

aq-mode 2 and psy vs aq-mode 1 and no psy
http://screenshotcomparison.com/comparison/93743

someone named 'x265' posted it on a chat, credits to him.

hard to judge both are very bad. I don't know the source but looks like aq 2 with psy is a little bit better. CRF 21 is simply not good enough.

[lotusgg]

Testing RDOQ in anime grain retention.
source is 1080p grainy anime blu-ray. It has digital grain and also scenes without any grain, scenes with high motion, high detail and lots of lightning plays.


x264 lossless (http://zorofiles.com/k4xrgjbubcxh) - 2gb (rename .test to .mp4 or just open with the player of your choice.)

High RDO and low AQ1 method:
x265 crf18 (http://www.solidfiles.com/d/c5209420dd/00000.hevc) settings: http://prntscr.com/543jd1 - 0.43fps - 300mb
x265 crf14 (http://www.solidfiles.com/d/356963ef9b/00000_2.hevc) settings: http://prntscr.com/54h6fx - 0.40fps - 460mb

No psy and high AQ1 method:
x265 crf18 (http://zorofiles.com/23aniq7m87b9) settings: http://prntscr.com/54eqks - 0.38fps - 540mb
x265 crf14 (http://zorofiles.com/9dlqeyb73j52) settings: http://prntscr.com/54eq25 - 0.32fps - 800mb


Will edit with more tests.

[microchip8]

hard to judge both are very bad. I don't know the source but looks like aq 2 with psy is a little bit better. CRF 21 is simply not good enough.

I prefer the second (aq1 nopsy)

[sneaker_ger]

Playing around a bit with grain retainment but without any luck (throwing spaghetti at wall). Interested to see if anyone is able to find settings that match x264.
[...]

Added two encodes with x265 1.4 --tune grain to the test. Quite a difference between 10 bit and 8 bit.

[lotusgg]

lol.
8bits performed better?

[sneaker_ger]

Yes. x264 10 bit does not have this problem.

[Motenai Yoda]

Imho x265 performs pretty good on I-frames but bad on P/B frames

x264 (142.2491kmod_8bit_x64) settings: --preset veryslow -p 2 -B 1460 --profile high --level 4.1 --vbv-maxrate 24000 --vbv-bufsize 24000 -f -2:-1 -b 8 -r 5 --tune film --psy-rd 1.1:0.3
x265 (1.4+208_8bit_x64) settings: -p medium --rdpenalty 1 --tu-intra-depth 3 --tu-inter-depth 3 --b-intra --weightb --psy-rd 1.0 --rd 4 --psy-rdoq 1.0 --rc-lookahead 40 --crf 21

Source 038295 http://www.imagebam.com/image/23c7f3373876529
Source 038296 http://www.imagebam.com/image/3afdc0373876667

x264 038295 http://www.imagebam.com/image/61bfbc373876774
x264 038296 http://www.imagebam.com/image/819874373876893

x265 038295 http://www.imagebam.com/image/5b3a3d373876988
x265 038296 http://www.imagebam.com/image/42dd57373877153

[x265_Project]

Imho x265 performs pretty good on I-frames but bad on P/B frames

x264 (142.2491kmod_8bit_x64) settings: --preset veryslow -p 2 -B 1460 --profile high --level 4.1 --vbv-maxrate 24000 --vbv-bufsize 24000 -f -2:-1 -b 8 -r 5 --tune film --psy-rd 1.1:0.3
x265 (1.4+208_8bit_x64) settings: -p medium --rdpenalty 1 --tu-intra-depth 3 --tu-inter-depth 3 --b-intra --weightb --psy-rd 1.0 --rd 4 --psy-rdoq 1.0 --rc-lookahead 40 --crf 21

Source 038295 http://www.imagebam.com/image/23c7f3373876529
Source 038296 http://www.imagebam.com/image/3afdc0373876667

x264 038295 http://www.imagebam.com/image/61bfbc373876774
x264 038296 http://www.imagebam.com/image/819874373876893

x265 038295 http://www.imagebam.com/image/5b3a3d373876988
x265 038296 http://www.imagebam.com/image/42dd57373877153
Your rate control settings are very different, and they don't seem to make sense. You're setting x264 to an average bit rate of 1460 kbps, using 2 pass rate control. Meanwhile, you're setting x265 to --crf 21.

When I try these settings I get massively different bit rates.

If you want to compare x264 and x265 fairly, I suggest that you don't try to adjust all of the parameters that the performance presets already take care of (GOP structure, # of ref frames, other quality algorithms, profiles, levels, depths, etc.). Try something like...

x264 --preset XXXX --bitrate YYYY
x265 --preset XXXX --bitrate YYYY (or YYYY/2, or somewhere in between)

If you want to add psy-rd to x265, I suggest a nominal amount... --psy-rd 0.2 --psy-rdoq 1.0.

[Motenai Yoda]

Your rate control settings are very different, and they don't seem to make sense. You're setting x264 to an average bit rate of 1460 kbps, using 2 pass rate control. Meanwhile, you're setting x265 to --crf 21.

I set 1460kbps for x264 (avg quant 28.409) to match the bitrate give me by x265 at --crf 21
also I tryed those settings (depth/psy/rd) to maintain at least some detail/grain (I forgot to remove some parameters for x264, vbv, profile,level)
ps highest x265's presets are too slow on my pc

my point is the washout from I-frames to other frames with x265 while with x264 are still comparable.

[benwaggoner]

This is still a prey apples-to-kumquats comparison. What are your dependent and independent variables you are shooting for?

B-intra isn't the first thing I'd add to medium to try to address these issues. --tune-grain might be worth trying for detail preservation as an experiment.


-Ben Waggoner (via TapaTalk)

[Boulder]

I tried comparing x264 and x265 and came to the conclusion that at least with the default settings of presets, x265 smooths the picture too much. I encoded a short snippet of Hot Fuzz in CRF mode, x264 had CRF18 and x265 needed CRF14.75 to produce about the same final bitrate.

Settings for x264 : --stdin y4m - --sar 1:1 --open-gop --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" --preset veryslow --tune film --crf 18
Settings for x265 : --y4m --input - --sar 1:1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" --preset slow --crf 14.75

The high smoothing can easily be seen in frames around 600 or so by looking at the windows in the background. The x265 encodes with a higher CRF would naturally smooth the image even more. Actually it smooths so much that a denoiser would not be necessary anymore and that is something I don't like. However, I see a lot of potential there, I just hope that the promise of improved efficiency is not fulfilled with such tricks :)

I'm also going to encode the same clip at the same CRF with presets slower and veryslow and see if there is any improvement. They are just too slow to use in full-length encodes at the moment (on an i5-4670K at least).

The clips are here to download, I also put the original file there so you can try yourself. Please let me know if this is not a "fair use" case and I'll remove those.

https://drive.google.com/folderview?id=0BzeF_1syecQwQjB2T1N5Mm93dU0&usp=sharing

[a5180007]

Is it fair to compare smoothness in x264 with psy and x265 without ?

[Boulder]

Well, I'd expect that most regular users use the default values and as the developers often state: "Use presets unless you have a really good reason not to."

[Hiritsuki]

--no-sao is good for quality.

[Audionut]

The last time I used x265 was about 8 months ago, and the quality was to be expected given the development infancy. Just tried again with the latest build by LigH, things have improved immensely, both speed and quality. :)

ducks_take_off_1080p50.y4m

x265_Win64_64bpp.exe -o output.hevc input.y4m
x264_Win64_10bit.exe --crf 31.6 input.y4m output.mkv

https://dl.dropboxusercontent.com/u/34113196/x265.hevc
https://dl.dropboxusercontent.com/u/34113196/x264.mkv

y4m [info]: 1920x1080p 1:1 @ 50/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile High 10, level 4.2, 4:2:0 10-bit
x264 [info]: frame I:2 Avg QP:50.35 size: 81802
x264 [info]: frame P:251 Avg QP:52.02 size: 37366
x264 [info]: frame B:247 Avg QP:53.78 size: 6177
x264 [info]: consecutive B-frames: 1.2% 98.8% 0.0% 0.0%
x264 [info]: mb I I16..4: 6.1% 71.8% 22.1%
x264 [info]: mb P I16..4: 0.6% 1.6% 0.1% P16..4: 50.2% 19.2% 10.9% 0.0% 0.0% skip:17.3%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 41.3% 0.6% 0.2% direct: 0.6% skip:57.2% L0:15.6% L1:82.5% BI: 1.8%

x264 [info]: 8x8 transform intra:70.7% inter:74.1%
x264 [info]: coded y,uvDC,uvAC intra: 58.4% 64.7% 35.6% inter: 25.3% 17.1% 0.8%
x264 [info]: i16 v,h,dc,p: 4% 83% 3% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 3% 39% 14% 3% 6% 3% 19% 2% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 4% 52% 12% 3% 5% 2% 12% 1% 8%
x264 [info]: i8c dc,h,v,p: 62% 32% 4% 2%
x264 [info]: Weighted P-Frames: Y:4.8% UV:2.0%
x264 [info]: ref P L0: 90.5% 5.8% 3.6% 0.1%
x264 [info]: ref B L0: 98.0% 2.0%
x264 [info]: kb/s:8854.55

encoded 500 frames, 22.69 fps, 8855.13 kb/s

y4m [info]: 1920x1080 fps 50/1 i420p8 sar 1:1 frames 0 - 499 of 500
x265 [info]: HEVC encoder version 1.4+527-d26268f9dc19
x265 [info]: build info [Windows][GCC 4.8.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-4.1 (Main tier)
x265 [info]: WPP streams / frame threads / pool : 17 / 3 / 8
x265 [info]: Internal bit depth : 10
x265 [info]: CTU size / RQT depth inter / intra : 64 / 1 / 1
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: Rate Control / AQ-Strength / CUTree : CRF-28.0 / 1.0 / 1
x265 [info]: tools: rd=3 psy-rd=0.30 deblock sao signhide tmvp
x265 [info]: frame I: 3, Avg QP:36.35 kb/s: 34836.93
x265 [info]: frame P: 124, Avg QP:36.74 kb/s: 25119.47
x265 [info]: frame B: 373, Avg QP:39.85 kb/s: 3166.34
x265 [info]: global : 500, Avg QP:39.06 kb/s: 8800.74
x265 [info]: Weighted P-Frames: Y:21.0% UV:13.7%
x265 [info]: consecutive B-frames: 1.6% 0.8% 0.0% 97.6% 0.0%

encoded 500 frames in 82.58s (6.06 fps), 8800.74 kb/s

[sneaker_ger]

Revisiting the old grainy anime test (http://forum.doom9.org/showpost.php?p=1693863&postcount=81) with x265 1.5:

Conclusion: x265 still does away with lots of the grain.

7000 kbit/s 2pass
x264 2525 --preset veryslow --tune grain
x265 1.5.11 --preset slower --tune grain

x264 8 bit (https://mega.co.nz/#!w4cDEa6K!BKU1HWLB3xHrP34e35q8RoAC8-KZjdJFLt7f4Pggweo) (2nd pass: 3.18 fps)
x264 10 bit (https://mega.co.nz/#!c5VG0LKJ!eYHoBLxzpvdmPC_Ld83hoaNV4et_ic9PsyjlWupg3LA) (2nd pass: 1.89 fps)
x265 8 bit (https://mega.co.nz/#!RwNFnIoZ!9oFRdEK8Z5nKoj-QzVFTEr8N-sckE26p_83s9ktSrV8) (2nd pass: 0.56 fps)
x265 10 bit (https://mega.co.nz/#!8t9VXaJZ!Gg1HuJMn50R7PwC518PfNejQEJCA6ZIfqH7EkMiCS6M) (2nd pass: 0.44 fps)
package of screenshots + logs (https://mega.co.nz/#!I40FnKDB!dNJAv0kWHxeUt_89OKPwQcWXJuoXI714nQy9HfNdqxQ)

http://abload.de/img/270_original_2pu9h.png
http://abload.de/img/270_x264g_8bit_nibbh.png
http://abload.de/img/270_x264g_10bit_rsxdp.png
http://abload.de/img/270_x265g_8bit_xgll8.png
http://abload.de/img/270_x265g_10bit_r6xqw.png

/edit:
fixed "original" screenshot

[huhn]

the original picture is not cropped in the same way as the encode results.

I would say x264 even with 8 bit outperforms x265 10 bit in this case.

x265 is really blurry in this case.

[benwaggoner]

So, lots of different opinions about x264 v. x265 out there. There've been a bunch of quality improvements in x265 in the last month or so, so I thought I'd give it all a swing through my standard stress test settings using Tears of Steel. Interestingly, the quality differences weren't that big at my old 3 Mbps CBR rate, so I went down to 2 Mbps (for 1920x800!) so we could really see some differences.

My stress test parameters emulate a classic streaming case.

2 Mbps Constant Bitrate
Max 4 sec Variable Closed GOP
VBV=4 seconds of content, so 8000 Kbps
All quality v. speed knobs turned up to 11
All encoders get the appropriate psychovisual tweaks for the content
2-pass encoding


Here's my x264: https://www.amazon.com/clouddrive/share/fixwjTKQyNIgLxUzTeXz-4b5qpOQ_uhXk81TchNeqc8

And my x265: https://www.amazon.com/clouddrive/share/YSZCWMHmhXYnQgnjCwK4HWGN_8M1OesaDlOf-J6M6BU

x264 parameters: --level 4.0 --preset placebo --pass 2 --bitrate 2000 --stats ".stats" --keyint 96 --min-keyint 8 --vbv-bufsize 8000 --vbv-maxrate 2000 --merange 32 --aud --nal-hrd cbr --colorprim bt709 --transfer bt709 --colormatrix bt709

x265 parameters: --level-idc 40 --pass 2 --preset placebo -F 1 --pmode --cu-lossless --subme 7 --tskip --bframes 16 --ref 6 --keyint 96 --rc-lookahead 96 --no-open-gop --bitrate 2000 --vbv-maxrate 2000 --vbv-bufsize 8000 --colorprim bt709 --transfer bt709 --colormatrix bt709 --repeat-headers --hrd --au

As expected, the x265 was about 8x slower than x264, which isn't crazy. And I'm sure nearly identical quality could have been gained at much higher speed for both.

At this low bitrate, x265 is definitely better than x264 for action and higher motion scenes, although they look pretty darn similar for lower-motion scenes. Man, codecs have come a LONG way!

Anyway, tell me what y'all think.

I'm not sure whether my next test should be at VideoCD bitrates :). It's amazing to think how much better quality we can get, even per-pixel, with 15x more pixels. Not bad for just 20 years!

I'd be happy for VP9/Daala/etcetera experts to provide equivalent clips to the same specs for comparison purposes. I think I'll do a VC-1 test just to shame my former self.

[mandarinka]

Not hardcore enough, it still has WPP on :D
But encoding your sample in how many (16?) segments is not fun. But maybe disabling WPP and using more frame threads instead would help quality (probably, I didn't try myself).

[benwaggoner]

I view WPP as an essential decoder side optimization, so I always use it. I would prefer I the universe forgets that a non-WPP mode ever existed, like all those Baseline-but-not-Main features of H.264.

[benwaggoner]

Also, with --pmode I'm still able to get around 50-65% utilization on my 16 core (32 thread) workstation.

[foxyshadis]

Not hardcore enough, it still has WPP on :D
But encoding your sample in how many (16?) segments is not fun. But maybe disabling WPP and using more frame threads instead would help quality (probably, I didn't try myself).

WPP is NOT slicing and it'll usually (minimally) increase quality, not decrease it. WPP only changes the way the final lossless compression works, it's not the large quality/speed tradeoff that people associate with x264 slices, although measuring it is pretty complex with RDO. I'd say it's one of the best special-purpose lossless compression methods I've ever seen.

Not using WPP slows both your encode and decode down for no good reason.

[xooyoozoo]

WPP only changes the way the final lossless compression works

In addition, it should be possible to do a bitstream-level "remuxer" that losslessly transforms a file between non-WPP and WPP.

There's no need for such a thing right now, but for all we know, the next several generations of hardware HEVC encoders could completely ignore WPP.

[mandarinka]

WPP is NOT slicing and it'll usually (minimally) increase quality, not decrease it. WPP only changes the way the final lossless compression works, it's not the large quality/speed tradeoff that people associate with x264 slices, although measuring it is pretty complex with RDO. I'd say it's one of the best special-purpose lossless compression methods I've ever seen.

Not using WPP slows both your encode and decode down for no good reason.

It is not slices but AFAIK even x265 developers say that it does decrease compression some (more than frame threads do). I wouldn't normally suggest to disable it, but since OP already disabled frame threads...

[x265_Project]

It is not slices but AFAIK even x265 developers say that it does decrease compression some (more than frame threads do). I wouldn't normally suggest to disable it, but since OP already disabled frame threads...
I hesitate to contradict Foxyshadis. However WPP is not likely to increase compression efficiency. If anything there might be a very slight decrease. See http://x265.readthedocs.org/en/default/threading.html#wavefront-parallel-processing

However, Wavefront Parallel Processing is massively better than using multiple tiles or slices per frame, both in terms of compression efficiency and in terms of parallelism (effective utilization of many-core machines).

[benwaggoner]

WPP is also what can make pure software or software + GPU decode FASTER than H.264 decode on multicore systems, with Windows 10 and Android L as two major examples.



We should act like HEVC non-WPP doesn't exist in the same way we mainly act like H.264 slices don't exist*.



*With the sad exception of Blu-ray above level 4.0.

[sneaker_ger]

New sample with grainy film. 5000 kbit/s 2pass.

It becomes harder and harder to find places were x265 loses against x264. I actively have to search for them now instead of just posting random screenshots. One remaining problem is some larger blocks turning flat.

x264 10bit (64) r2538 from Videolan
x265 1.5+452 high bitdepth Chromashift ICL

original (https://mega.co.nz/#!JtFDjaAC!x08kgvwP1dKWRiWTYy1fhmbYy-uzKWjh4X_aNR3ooSM)
x264 --preset veryslow --tune grain 10 bit (https://mega.co.nz/#!lptCVIaI!miWT43qqMY377Pt8hmoO6VGlZNzq-fUqvYwN2u0Uqm8)
x265 --preset slower --tune grain 10 bit (https://mega.co.nz/#!BocjHDaD!5ljTbNTMAXpDkJePZNUvEU7fFPjaTVwFIVW3aSo47kY)

http://abload.de/img/340_original_fzuqe.png
http://abload.de/img/340_x264_htutj.png
http://abload.de/img/340_x265_8guuf.png
Notice flat blocks on the paper in x265 encode, esp. in the region around the red line

http://abload.de/img/1414_original_h2u7d.png
http://abload.de/img/1414_x264_iwuq4.png
http://abload.de/img/1414_x265_qiucc.png
Notice flat blocks on the walls in the top-left part of the picture in x265 encode (zoom (http://abload.de/img/1414_x265_zoom_e0axq.png))

(encodes with 8 bit and/or rdoq-level 2 available on request)

[Boulder]

McConaughey's jacket seems to lose texture quite noticably in the x265 screenshot. The bad thing is that if you don't use --tune grain, you are bound to lose even more details :(

I wonder why the door doesn't have the same issue in the same magnitude, or the wall lower from where you have the zoomed image (slight flattening but not as bad as it could be).

[sneaker_ger]

I don't know. Looks like it's close to some kind of threshold. You will also see more of the blocks on the door if you frame-step through the video. The flat blocks come and go in a seemingly random fashion.

[smegolas]

New sample with grainy film. 5000 kbit/s 2pass.

It becomes harder and harder to find places were x265 loses against x264.

In those clips it's hard to find places where x265 wins against x264. (yes I can find a few)

x265 encode still looks like it's gone through a bad DNR filter.

http://screenshotcomparison.com/comparison/119588

[Sparktank]

http://screenshotcomparison.com/comparison/119588

Both look pretty severe.
The x264 shot looks like it got a lot of artificial sharpening while the x265 looks like it got smeared with mud.
The details on his brown coat (the creases) are too much in the x264 and are too little in the x265.

The walls look clean in x265 though.

[sneaker_ger]

The x264 shot looks like it got a lot of artificial sharpening

I don't really see it.
http://abload.de/img/original_jacket_depfb.png
http://abload.de/img/x264_jacket_crqdk.png
http://abload.de/img/x265_jacket_kfrtp.png

[Sparktank]

His top-right shoulder looks sharper and at first glance it looks like something completely different.
Maybe I just see what I want to see and take too much time looking at details.

Sitting at the desk sees things differently than I would be if I were looking at it 15 feet away when I normally watch.

The shadows the creases form are more defined, however.

[smegolas]

Both look pretty severe.
The x264 shot looks like it got a lot of artificial sharpening while the x265 looks like it got smeared with mud.
The details on his brown coat (the creases) are too much in the x264 and are too little in the x265.

The walls look clean in x265 though.

I disagree.

The x264 clip has approximately the same sharpness as the source.

The x265 clip has an entirely different character to the source. If I want a smoothing filter i'll apply it myself.

[burfadel]

After a bit of playing around, I came up with the following settings for x265, which is good up to 1080P:
--crf 20 --tu-intra-depth 2 --tu-inter-depth 2 --b-intra --bframes 7 --rc-lookahead 60 --ref 7 --subme 3 --merange 24 --max-merge 5 --weightb --aq-mode 2 --nr-intra 400 --nr-inter 400 --pmode

Try that for speed and quality verses just using --crf 20. Of course, I'm pretty 'enthusiastic' with the reference frames and bframes, you could eliminate those two in trying those settings, or set both to say 4, in the aforementioned speed/quality comparison I suggest you do :). You might want to play around with both of those noise reduction settings as well. Choosing the right values means no perceptible loss of quality but 'noticeably' improved compression. Keep in mind that what you save in bitrate with noise reduction, you could potentially put towards your CRF without ending up with a bigger file. What I mean is, if I had CRF 20 without the noise reduction, I could potentially obtain a similarly sized file with CRF 19 with noise reduction, with the other settings remaining the same.

[iSunrise]

Notice flat blocks on the walls in the top-left part of the picture in x265 encode (zoom (http://abload.de/img/1414_x265_zoom_e0axq.png))
Thanks for some of your examples sneaker_ger.

I don't get why the x265 encoder leaves some grainy areas mostly intact, while it seems to suddenly "decide" by random to create large blocks with areas of almost one and the same color in other parts of the picture.

Shouldn't this be quite easy to fix? What exactly is the reasoning for this? This seems more like a bug than anything else to me.

An expected result would be that the encoder dials down (averaging them all out by an amount X) on detailed areas in all of these grainy spots (relative to the available bandwidth it has at it's disposal), but instead it seems to choose completely by random to replace some areas of the picture with almost one colored pixels, which completely kills all picture information that's within the uniformly colored blocks.

That completely doesn't make any sense to me. This should not be hard to fix or I seriously doubt that x265 developers know what they're doing. This may sound a bit harsh, but I would really love an explanation for this, because when I look at this I seriously question the state of the encoder.

x265 in this state is not usable, because it seemingly alters the picture by ways of throwing a dice and this is not what anyone could want from it.

Also, with this behaviour present, x264 will remain visually superior with more grain retention and it's also way more predictable.

I hope the developers know what to look for when they see shots like this.

[Boulder]

I'm sure the devs know about these issues but it might not be that easy to fix without large amounts of code. I gave them my test clip by request and posted several screenshots showing the problem but I've not heard anything from them yet.

[Tommy Carrot]

I reported about this problem several months ago. They didn't acknowledge this issue and they insisted the problem is on my side. Since then, this behaviour hasn't been improved even a tiny bit, so don't expect it'll be fixed anytime soon.

[iSunrise]

I reported about this problem several months ago. They didn't acknowledge this issue and they insisted the problem is on my side. Since then, this behaviour hasn't been improved even a tiny bit, so don't expect it'll be fixed anytime soon.
The problem is on your side? Did they give any details what exactly they assume your problem is?

Because otherwise, this is just an answer that seems totally ignorant and self-protecting, when in fact they seem unwilling to even attempt to fix obvious bugs that end users invest their time to find and report to them.

I hope this is not their official stance on this matter.

Can we have DS back please? At least I got the impression that he knows what he is doing.

While I fully don't expect that x265 can ever be a lot more effective with really heavy grainy sources compared to x264, I at least expect a predictable behaviour with grainy sources and some savings on bitrate compared to x264 in the future.

[Boulder]

Well, poking some fun out of the situation: the answers have sometimes been like Spinal Tap's classic "but this goes to eleven". To me it seems that they have chosen the path they wish to proceed and are focusing on the current algorithms and making them faster because most people don't care about the issue as we've seen in many replies.

There is a slight chance that they'll go back to these issues we've reported at some point, but I wouldn't hold my breath while waiting. Fortunately x264 is a very good encoder and there is no urgent need to use anything else :)

[Tommy Carrot]

The problem is on your side? Did they give any details what exactly they assume your problem is?

Because otherwise, this is just an answer that seems totally ignorant and self-protecting, when in fact they seem unwilling to even attempt to fix obvious bugs that end users invest their time to find and report to them.

I hope this is not their official stance on this matter.

Well, they immediately assumed i've made some mistakes in my testing method. Since then, i saw claims by them about x265 being better than x264 in all circumstances, and i haven't seen any attempt to improve this behaviour, so i assume they don't acknowledge it as a real issue.

[iSunrise]

Well, poking some fun out of the situation: the answers have sometimes been like Spinal Tap's classic "but this goes to eleven". To me it seems that they have chosen the path they wish to proceed and are focusing on the current algorithms and making them faster because most people don't care about the issue as we've seen in many replies.

There is a slight chance that they'll go back to these issues we've reported at some point, but I wouldn't hold my breath while waiting. Fortunately x264 is a very good encoder and there is no urgent need to use anything else :)
Currently x264 serves us well, however, the problem i see with x264 is that bandwidth requirements explode with good and reasonably detailed >=4K sources, also Main10 H.265 is there for a reason. It almost seems like the MPEG2 situation from several years all over again (where at a certain resolution a codec just isn't well fit for anymore).

Let's hope this is not the last word we hear from them.

Well, they immediately assumed i've made some mistakes in my testing method. Since then, i saw claims by them about x265 being better than x264 in all circumstances, and i haven't seen any attempt to improve this behaviour, so i assume they don't acknowledge it as a real issue.
This sounds like they are purely marketing driven. Someone is deciding that they want to follow in x264's footsteps when it comes to quality, while completely ignoring facts and samples that show a completely different state. Not a good sign at all. It's like driving through red lights with heavy street traffic present that should alert you that there's clearly something wrong and you just keep on doing it.

[sneaker_ger]

Don't forget: they are investing a lot of money for a software we are using for free. And they have been doing work on psy, created a grain tuning, changed default aq mode and recently introduced rdoq-level option. To me it is proof they are working on improving quality, it just does not happen overnight nor is it trivial. I suggest we keep the aggression and entitlement out of this thread on focus on doing comparisons of current state. Providing undeniable proof of problems is more convincing than finger pointing. Everything else is off-topic and should be taken somewhere else.