Comparisons of x265 vs x264

[benwaggoner]

I agree that at some point it is better to downscale... but HEVC pushes this point lower.
Yeah, that's pretty much the story of compression right there :).

Back with Apple and Microsoft Video, we were talking >2 Mbps for 320x240 to look halfway decent, and it was halfway at best. Cinepak made for a reasonably decent 320x240 @ 2 Mbps for most content. MPEG-1 gave us a better 352x240 @ 1.5 Mbps. In the late 90's we had huge innovation with things like Sorenson Video 1 & 2/3, Indeo 5, RealVideo, and Windows Media V7 & 8 which made 320x240 feasible down to maybe 750 Kbps. Last decade saw VC-1 and H.264 emerge, getting us down to a decent Kbps 320x240. Over the last 10 years, further refinement in H.264 (largely psychovisual, but a lot from the Baseline to High transition) got us down to 300 Kbps 320x240 looking pretty good. HEVC can do the same at 200 Kbps, maybe lower. Of course, no one is even doing 320x240 any more.

If I get sufficiently bored, I should dust off all my old tools and encode the same clip using the best codecs of each era to see our progression.

Back when I was encoding for the Grolier's CD ROM encyclopedia around 97-98, I remember how excited I was to get a MPEG-1 (black and white 24p) down to 900 Kbps ABR!

[sneaker_ger]

I extended the test from post #45, this time with a bitrate of 5000 kbit/s and 8 bit only. The x265 encode didn't show as much improvement as the x264 one initially. Activating psy showed much less banding, though. I should have probably turned it on in the other test as well.

original
x264 --preset veryslow --tune film (https://mega.co.nz/#!pwcVwbpY!l7d9muOvue6dkxKyfu0OC9eelH79RJIxbklySl5ViAk)
x265 --preset slower (https://mega.co.nz/#!E4tgzByB!J0XGg1NQaDPJOWHLHl_bqSmFmdwKHewN7UWVkn8h4wM)
x265 --preset slower --psy-rd 1.0 --psy-rdoq 1.0 (https://mega.co.nz/#!Yk9gUbJQ!fZKdTNK0l0Gr2j09BNfxTL6a3PVHg44OpGTsB8NuOKw)

http://abload.de/img/70_orgcmslk.png
http://abload.de/img/70_4_v6stn.png
http://abload.de/img/70_5_w7sqn.png
http://abload.de/img/70_5psy_yfs1o.png

http://abload.de/img/290_orgqtsuz.png
http://abload.de/img/290_4_yls9t.png
http://abload.de/img/290_5_tmszr.png
http://abload.de/img/290_5psy_d9sl3.png

http://abload.de/img/1270_orgajst9.png
http://abload.de/img/1270_4_dusty.png
http://abload.de/img/1270_5_1wset.png
http://abload.de/img/1270_5psy_ydsup.png

http://abload.de/img/1950_orgrjsu8.png
http://abload.de/img/1950_4_2eseq.png
http://abload.de/img/1950_5_goslo.png
http://abload.de/img/1950_5psy_dss3t.png

[edison]

But PC graphics vendors have traditionally reserved 10 bit /sample (deep color) output for their professional graphics (NVIDIA Quadro, AMD FirePro).

All DX10 GPU support true 10-bit scan-out in DX10 mode via displayport or DB-15. There is a DX10 10-bit scan-out sample in MS DX SDK.
NVIDIA and AMD support DX10 10-bit scan-out in DX10 mode without need professional GPU. But, AMD implement a 1x-bit dithering in their DVI-output since X800 gen, so there is not difference when compare DVI and displayport on AMD GPU running the MS DX SDK 10bit sample.

[benwaggoner]

All DX10 GPU support true 10-bit scan-out in DX10 mode via displayport or DB-15. There is a DX10 10-bit scan-out sample in MS DX SDK.
NVIDIA and AMD support DX10 10-bit scan-out in DX10 mode without need professional GPU. But, AMD implement a 1x-bit dithering in their DVI-output since X800 gen, so there is not difference when compare DVI and displayport on AMD GPU running the MS DX SDK 10bit sample.
For NVidia, I believe the restriction is that the Quadro drivers are required for 10-bit OpenGL output. Which is what the professional video apps, notably CC, use.

The good news is that the low end Kepler Quadro's are actually pretty reasonable for a content creator. But they'd be lousy for gaming and other enthusiast stuff, so it'd be hard to build a box with a single GPU that did both well.

[huhn]

For NVidia, I believe the restriction is that the Quadro drivers are required for 10-bit OpenGL output. Which is what the professional video apps, notably CC, use.

The good news is that the low end Kepler Quadro's are actually pretty reasonable for a content creator. But they'd be lousy for gaming and other enthusiast stuff, so it'd be hard to build a box with a single GPU that did both well.

no normal nvidia card can do it for over 5 years.

http://nvidia.custhelp.com/app/answers/detail/a_id/3011/related/1

you need a quadro for openGL 10 bit like photoshop. but for directx 10 bit nothing special is needed just a normal nvidia card that's not over 6 years old and support DP, HDMI or both.

[nevcairiel]

no normal nvidia card can do it for over 5 years.

http://nvidia.custhelp.com/app/answers/detail/a_id/3011/related/1

you need a quadro for openGL 10 bit

Did you read his post? :p
He did mention that the limitation is about 10-bit OpenGL.

[huhn]

Did you read his post? :p
He did mention that the limitation is about 10-bit OpenGL.

good question... hmm

[agressiv]

With x265 encodes, am I losing quality with a --preset medium vs --preset veryslow or is it just file size? --crf is 18.

With x264, you lose a bit of quality even with the same crf.

[LoRd_MuldeR]

With x265 encodes, am I losing quality with a --preset medium vs --preset veryslow or is it just file size? --crf is 18.

With x264, you lose a bit of quality even with the same crf.

If you compare the visual quality of files with different size (and therefore with different bitrate) you won't learn much, because you comparison is flawed. Therefore, always compare files of the same size (bitrate)!

BTW: The same CRF has a different meaning, if you change other influential settings, like switching between "medium" and "veryslow" presets. Don't use CRF for comparisons. Use 2-Pass mode.

[agressiv]

That's the thing, final file size / target bitrate - has never been a goal of mine. I'd rather just have consistent quality, which --crf 18 with x264 has always provided for me. So, doing a 2-pass wouldn't bring me any closer to deciding if veryslow is desirable with --crf 18, or if an extra small amount of file size saves me hours of transcoding time with comparable quality by sticking with medium.

If I compared a 2-pass encode and decided medium is good enough, would that hold true for crf 18 in a 1-pass? To me, that is apples and oranges, no?

[LoRd_MuldeR]

That's the thing, final file size / target bitrate - has never been a goal of mine. I'd rather just have consistent quality, which --crf 18 with x264 has always provided for me. So, doing a 2-pass wouldn't bring me any closer to deciding if veryslow is desirable with --crf 18, or if an extra small amount of file size saves me hours of transcoding time with comparable quality by sticking with medium.

If I compared a 2-pass encode and decided medium is good enough, would that hold true for crf 18 in a 1-pass? To me, that is apples and oranges, no?

CRF is not a "target quality" mode! All you really know about CRF mode is: The same CRF value gives approximately the same quality for different sources (of the same type) as long as you don't change any other settings. Consequently, CRF 18 at preset "veryslow" may give very different quality than CRF 18 at preset "medium". With 2-Pass mode you can verify that "veryslow" preset gives better quality than "medium" preset at the same bitrate. Of course this applies to CRF mode too! Only that in CRF mode you probably will not get the same bitrate for "medium" and "veryslow" preset at a given fixed CRF value (e.g. CRF 18). So when going from "medium" to "veryslow" preset, you will probably need to re-adjust your "usual" CRF value.

[sneaker_ger]

The next comparison is from the 2K trailer of "Gravity". It is done in 2pass 5000 kbit/s. Source was down-sampled to 4:2:0 8 bit/10 bit using fmtconv (http://forum.doom9.org/showthread.php?t=166504) since 4:2:2 HEVC is still experimental.

Original (2.6 GB) (http://pdl.warnerbros.com/wbmovies/gravity/trailer2/GRAVITY_TRAILER_5-2k.mov)
x264 veryslow film 8 bit (https://mega.co.nz/#!opdykaTY!Xrybcjh8Umds7V1Y7Hjpc2u9blP5wq81maUrSaGz3UU)
x264 veryslow film 10 bit (https://mega.co.nz/#!4gVU2YxD!rAjuWATY5fL6PPeS5syenzETFZekR4PICPWPYU5gMJ4)
x265 default psy-rd 1.0 10 bit (https://mega.co.nz/#!k0dz2SjY!KKzMMhIBwkWpJGIn0GvEAeW5F7-bP2k0GQ_EQXRffAc)
x265 slower psy-rd 1.0 psy-rdoq 1.0 10 bit (https://mega.co.nz/#!gsVwVIQA!kpvXpZYGr2csELFdnH5ivzTabIzuwoTgAuj4cwkAaB4)

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

http://abload.de/img/22507ruhl.png
http://abload.de/img/2250_4_uru68.png P
http://abload.de/img/2250_4_10_zeuwo.png P
http://abload.de/img/2250_5_xnuwt.png B
http://abload.de/img/2250_5s_opu3g.png B

http://abload.de/img/2640ixune.png
http://abload.de/img/2640_4_b4uak.png I
http://abload.de/img/2640_4_10e1u3a.png I
http://abload.de/img/2640_5_e8u6d.png I
http://abload.de/img/2640_5s_0iukh.png B

http://abload.de/img/2677qzull.png
http://abload.de/img/2677_4_2fuk0.png P
http://abload.de/img/2677_4_10_d1uyl.png B
http://abload.de/img/2677_5_gju0y.png B
http://abload.de/img/2677_5s_5ruea.png B

http://abload.de/img/2765bxum3.png
http://abload.de/img/2765_4_t9u7d.png P
http://abload.de/img/2765_4_10_gzudi.png P
http://abload.de/img/2765_5_zruvh.png P
http://abload.de/img/2765_5s_q4uf6.png P

http://abload.de/img/2825ewf9y.png
http://abload.de/img/2825_4_rseqv.png B
http://abload.de/img/2825_4_10_ihc4t.png B
http://abload.de/img/2825_5_lxi4l.png B
http://abload.de/img/2825_5s_kjfei.png B

http://abload.de/img/3030wecu5.png
http://abload.de/img/3030_4_hidwl.png B
http://abload.de/img/3030_4_10_fyitx.png B
http://abload.de/img/3030_5_opezp.png B
http://abload.de/img/3030_5s_0gi4q.png B

http://abload.de/img/3334j6dn8.png
http://abload.de/img/3334_4_o2fhi.png P
http://abload.de/img/3334_4_10_45c50.png P
http://abload.de/img/3334_5_9gdjm.png P
http://abload.de/img/3334_5s_vginz.png P

[sneaker_ger]

Since I haven't seen any tests yet the next one is with a cartoon/animation Blu-Ray sample. The bitrate was 2500 kbit/s (2pass).

My conclusion:
x265 is the clear winner in this one, even against x264 10 bit. Especially the first screenshot made me question my test setup. In retrospect the bitrate was too low, though.

Original (https://mega.co.nz/#!tk0F3TxZ!-6WkTrqXemhegSyjKwBteGYr9Iow_DRJwG3_d0pKr-4)
x264 veryslow animation 8 bit (https://mega.co.nz/#!EhsFmDjY!ixhVOqEYxD_Unj8BY9O5_ChgLwQtdl29QmmIljj0Ics) (16.65 fps, 3.17 fps)
x264 veryslow animation 10 bit (https://mega.co.nz/#!YsdBWBpR!7KL0HBE8q3SjJhgbtZ_DfO8n3RJx3nrabSPr2b1nKq0) (12.35 fps, 1.78 fps)
x265 default psy-rd 1.0 10 bit (https://mega.co.nz/#!50tUyDSa!FTycXqVpQ0NiS2h98scLkyYHq6KbF_CLYM7ay40l874) (4.71 fps, 4.05 fps)
x265 slower psy-rd 1.0 psy-rdoq 1.0 10 bit (https://mega.co.nz/#!d99WlQSI!3vLlE74M8EOue5Zl3mpimmBW8ysMqBbcda2c6MmOCLg) (3.73 fps, 0.28 fps)

Intel Core i7-860 @ stock
x264 r2479 64 bit from Videolan
x265 r1.3+175 icl 64 bit from Chromashift

all B
http://abload.de/img/60khxt8.png (ignore the "downsampled to 4:2:0" part, that was a forgotten left-over from the previous test)
http://abload.de/img/60_4_pcl9o.png
http://abload.de/img/60_4_10_1xzef.png
http://abload.de/img/60_5_haybt.png
http://abload.de/img/60_5s_nxzs3.png

all P
http://abload.de/img/870qgxi7.png
http://abload.de/img/870_4_8rx9p.png
http://abload.de/img/870_4_10_mfbye.png
http://abload.de/img/870_5_70b6b.png
http://abload.de/img/870_5s_gvbkl.png

all P
http://abload.de/img/1570e2act.png
http://abload.de/img/1570_4_uibrn.png
http://abload.de/img/1570_4_10_kna07.png
http://abload.de/img/1570_5_hub5z.png
http://abload.de/img/1570_5s_zlzhb.png

all B
http://abload.de/img/179313ale.png
http://abload.de/img/1793_4_b8zaf.png
http://abload.de/img/1793_4_10wqyza.png
http://abload.de/img/1793_5_o8abz.png
http://abload.de/img/1793_5s_fbx5j.png

The next test should probably be cartoon/animation taken from within an actual show because this was too action/sfx packed. Cartoons are often still shots with little movement.

[sneaker_ger]

An extension of the test above, now with 6000 kbit/s. x264 8 bit has been removed, x265 default has been substituted by x265 preset slow.

My conclusion:
x265 (slower) is still the winner in this. Both x264 and x265 lose (different) details here and there but the x265 shows much less artifacts around edges and looks more smooth in general.

original
x264 veryslow animation 10 bit (https://mega.co.nz/#!18ln3IjS!cc2Qf58kLXEdm9MeE-b5wvDwG9GmgLHIdSQSXTE6_ko) (11.06 fps, 1.45 fps)
x265 slow psy-rd 1.0 psy-rdrq 1.0 10 bit (https://mega.co.nz/#!pwUmhCbA!sX1qX4Q_RwlBSrif0RsinTh9zDrf2u81i9Mv3fjtzyw) (4.05 fps, 0.89 fps)
x265 slower psy-rd 1.0 psy-rdrq 1.0 10 bit (https://mega.co.nz/#!xttVhSDD!KaZGE4_mJxVYWyLfm-STGVISJX2Rzd_ypcvV4SC09Rc) (3.09 fps, 0.21 fps)

http://abload.de/img/60khxt8.png
http://abload.de/img/60_4_krbgi.png
http://abload.de/img/60_5_rol23.png
http://abload.de/img/60_5s_fuyzw.png

http://abload.de/img/870qgxi7.png
http://abload.de/img/870_4_4tb58.png
http://abload.de/img/870_5_7caty.png
http://abload.de/img/870_5s_vlx63.png

http://abload.de/img/1570e2act.png
http://abload.de/img/1570_4_j9y18.png
http://abload.de/img/1570_5_featk.png
http://abload.de/img/1570_5s_f6l7i.png

http://abload.de/img/179313ale.png
http://abload.de/img/1793_4_erye1.png
http://abload.de/img/1793_5_icl1d.png
http://abload.de/img/1793_5s_dglkf.png

[huhn]

edit: talking about the 2500 kbit anime test.

i find it very strange that veryslow x264 8 bit gets aliasing but preserve a lot more details compared to default x265 10 bit and has less banding too

veryslow x264 8 bit http://abload.de/img/1570_4_uibrn.png aliased
default x265 10 bit http://abload.de/img/1570_5_hub5z.png more banding missing a lot of details sharper at all

i judge them later with a lot better screen.

[Gravitator]

i find it very strange that veryslow x264 8 bit gets aliasing but preserve a lot more details compared to default x264 10 bit and has less banding too
10bit is useless / waste bitrate on images with a greater proportion of light areas.

[huhn]

10bit is useless / waste bitrate on images with a greater proportion of light areas.

no there are multiply test that shows 10 bit helps in all cases.

there is a huge type it is veryslow 8 bit x264 vs default 10 bit x265

[Gravitator]

no there are multiply test that shows 10 bit helps in all cases.

there is a huge type it is veryslow 8 bit x264 vs default 10 bit x265

Parallel forum for threads x264 vs x265 (http://forum.videohelp.com/threads/365014-x264-vs-x265)

[huhn]

Parallel forum for threads x264 vs x265 (http://forum.videohelp.com/threads/365014-x264-vs-x265)

sorry its hard to fine useful informations in that thread. a lot of personal things hard to find tests. and the most important part it is pretty old with the last post from 12 july. x265 has matured a lot in the meanwhile.

the first comparison show little effect with 10 bit or 8 this has changed a lot.

and with x264 there is no question that 10 bit has an positive effect on quality.

[professor_desty_nova]

edit: talking about the 2500 kbit anime test.

i find it very strange that veryslow x264 8 bit gets aliasing but preserve a lot more details compared to default x265 10 bit and has less banding too

veryslow x264 8 bit http://abload.de/img/1570_4_uibrn.png aliased
default x265 10 bit http://abload.de/img/1570_5_hub5z.png more banding missing a lot of details sharper at all

i judge them later with a lot better screen.

X264 has tune for animation (tweaked deblock, Bframes, AQ and psy-rd), and x265 is at default. Maybe tweaking psy-rd, psy-rdoq and AQ might make a difference in detail preservation in animation...

[huhn]

X264 has tune for animation (tweaked deblock, Bframes, AQ and psy-rd), and x265 is at default. Maybe tweaking psy-rd, psy-rdoq and AQ might make a difference in detail preservation in animation...

as far as I can read no tune was used in these encode.

[sneaker_ger]

as far as I can read no tune was used in these encode.
"x264 veryslow animation 10 bit" is supposed to mean "x264.exe --preset veryslow --tune animation".

[sneaker_ger]

New test: non-action packed cartoon/anime, 1000 kbit/s.

My conclusion:
A win for x265 as well which seems to have no problems with edges. x264 on the other always hand shows problems on quite a few of them. I actually did a third pass for x264 because it undershot the bitrate but it couldn't change the result of the match.
Maybe others have better x264 tunings?

Original (https://mega.co.nz/#!AhknDSJQ!Y2Qwi6KivN87sl0ENjxJejPp3jDGjSGjvQiywopHcgU)
x264 --preset veryslow --tune animation 10 bit (https://mega.co.nz/#!xhcQGQSA!xtdOVDnVl5w4z2g1CKIDzgR2dxSSRyCgjz5l-EZiFM8) (2pass result (https://mega.co.nz/#!dsUUFLBA!nCBqNvpbMh4SvWOO7P3hStBHk8WaxWjevYXRH7lbW-8)) (15.65 fps, 4.15 fps)
x265 --preset slower --psy-rd 1.0 --psy-rdoq 1.0 10 bit (https://mega.co.nz/#!J8NwSKDQ!nBwM5V8kSJ7eA3hYmzDtwjyyMsNqbg71hdrlKF8rYXo) (5.81 fps, 0.77 fps)
x265 --preset slower 10 bit (https://mega.co.nz/#!4o01hKrQ!HJdDaq3D54LoRTh4pJw7OoQfm_XfpQ5pzQCXzJt1Zwo) (6.54 fps, 0.92 fps)

Intel Core i7-860 @ stock
x264 r2479 64 bit from Videolan
x265 r1.3+186 icl 64 bit from Chromashift

http://abload.de/img/118djpdb.png
http://abload.de/img/118_4_14olo.png
http://abload.de/img/118_5_mhqcv.png
http://abload.de/img/118_5_np_xletx.png

http://abload.de/img/2007xojz.png
http://abload.de/img/200_4_fdowr.png
http://abload.de/img/200_5_ssqyx.png
http://abload.de/img/200_5_np_73el8.png

http://abload.de/img/97271q98.png
http://abload.de/img/972_4_esofi.png
http://abload.de/img/972_5_pipcb.png
http://abload.de/img/972_5np_9zeiv.png

http://abload.de/img/1407hdp6o.png
http://abload.de/img/1407_4_93rx3.png
http://abload.de/img/1407_5_wbri4.png
http://abload.de/img/1407_5np_ixf0z.png

Seeing the results x265 might be the new champion for cartoon/animation. These tests were done on clean Blu-Ray sources of modern shows. Maybe older, less "sterile", films yield different results?

[lotusgg]

sneaker_ger, can you do the tests WITHOUT psy-rd/psy-rdoq on anime sources?
I did some tests with 900bitrate anime and psy-rd seems to be degrading the image.

[sneaker_ger]

I have added an encode without x265's psy to the last test.

[lotusgg]

Can you do it in an action/lightning-packed anime?
Like Mahouka or even SNK again.

[sneaker_ger]

The next test involves old and grainy anime. Bitrate is 7000 kbit/s (2pass).

Conclusion:
x264 does a better job for this noisy source.

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

original (https://mega.co.nz/#!hh0nRLia!7BghO78Nto3t9jVz_AObXbHuFd5HlDn7k4XOb_acysc)
x264 --preset veryslow --tune animation 10 bit (https://mega.co.nz/#!pwVQjR5I!Bz5G3jdYlBxx8OQzJMfyqB4JobH6F3e-BQO6kxbleis)
x264 --preset veryslow --tune grain 10 bit (https://mega.co.nz/#!9wNV3bqA!yxaY4z8LiNHSYGrbma9hWNWVV1ZknVnBLGaTXy2rMlU)
x265 --preset slower --psy-rd 1.0 --psy-rdoq 1.0 10 bit (https://mega.co.nz/#!pxVkTJCI!S8JX-KjJvrFsAoRaouIdxZsAzT1fbv0W_OVCD3qFZ2I)

http://abload.de/img/220_btky3.png
http://abload.de/img/220_4a_2akwo.png
http://abload.de/img/220_4g_erohp.png
http://abload.de/img/220_5_jjkrj.png

http://abload.de/img/240_njj10.png
http://abload.de/img/240_4a_qxk0m.png
http://abload.de/img/240_4g_vxqfm.png
http://abload.de/img/240_5_0ykf6.png

http://abload.de/img/770_c7kko.png
http://abload.de/img/770_4a_2gjhx.png
http://abload.de/img/770_4g_lpq7g.png
http://abload.de/img/770_5_gcjbs.png

http://abload.de/img/900_4cjui.png
http://abload.de/img/900_4a_brjp9.png
http://abload.de/img/900_4g_repih.png
http://abload.de/img/900_5_aejol.png

http://abload.de/img/1000_ezjr8.png
http://abload.de/img/1000_4a_u9kwv.png
http://abload.de/img/1000_4g_x8rlw.png
http://abload.de/img/1000_5_npkxg.png

[sneaker_ger]

Can you do it in an action/lightning-packed anime?
Like Mahouka or even SNK again.
Not that interested right now as x265 already proved itself superior in that test. Since I provided the source file you can easily do it yourself, though. (Also: I don't have every Blu-Ray on earth.)

[huhn]

I may do a comparison later with a relative new anime that's not from shaft. the animation style from shaft is very compression friendly these days.

I have nearly no experience with 2 pass encodes and I never really used presets too. so it's hard for me to judge what Kbit should be used for the tests.

[lotusgg]

Try 1000kbit/s and no psy-rd.
If you wish, you can make two tests. One with and other without it.
Just saying, cuz I tested on some non-lossless sources and the non-psyrd ones had less blurring/detail washes and less weird softy blocks inside a nest of grains.

[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.

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

Original (from previous test, cropped 22/22 top/bottom, trimmed 634 - 1156)
x264 --preset veryslow --tune grain 8 bit (https://mega.co.nz/#!00cRRI6Z!VJKsdBGD7Rq2pJO4YiytQSyRF70TgYH5Lt_e6GNzAcI)
x264 --preset veryslow --tune grain 10 bit (https://mega.co.nz/#!Ip0hlbYJ!36QK1_JNS39-xXKQvXMkBG9udpq-RiETZigrXeMg4Io)
x265 --preset veryslow --aq-strength 0.5 10 bit (https://mega.co.nz/#!Fg9xBTgL!QEvx6Hu3j8YJrsG0-40rgdUKvn7_mUZgQHC--k1gphc)
x265 --preset veryslow --aq-strength 0.5 --psy-rd 1.0 --psy-rdoq 4.0 10 bit (https://mega.co.nz/#!V4s3mSII!sVrn1h038xHhxGwkcz8gTy4NsesEXNCNGqRpCq6wf3M)
x265 --preset veryslow 10 bit (https://mega.co.nz/#!g0tXhJ7D!xeHIqgYFxoGxZ-eGknVUil4rp14JXskAmTZgh9Nccc0)
x265 --preset veryslow --psy-rd 1.0 --psy-rdoq 1.0 10 bit (https://mega.co.nz/#!Eh12mChL!r1gV7njbML2WrJMRXSpz8hjR84s1ZoF7rbcvfpk8jZY)
x265 --preset veryslow --aq-strength 1.5 --psy-rd 1.5 --psy-rdoq 5.0 10 bit (https://mega.co.nz/#!940jVZKA!QZpoJPIFyG2rH7BIY2UbLigxC7Wgt4iO8vWkaH6Guck)
x265 --preset veryslow --aq-mode 1 --aq-strength 2 --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!MwlW3QZb!KLERb7cjvqe7ZeeUzcvMknVm2XHBo18nHHdJOsd4PxU)

All 2pass --bitrate 7000. Average 2nd pass fps for x265's preset veryslow was ~0.20 fps vs x264's ~3.2 fps. Watching the clips gives a better idea about the grain than looking at the screenshots.

http://abload.de/img/270_5my3i.png
http://abload.de/img/270_g_igz4x.png
http://abload.de/img/x264_10bitoar34.png
http://abload.de/img/270_1_vdl7g.png
http://abload.de/img/270_2_vdlvs.png
http://abload.de/img/270_3_yha9l.png
http://abload.de/img/270_4_0kzy9.png
http://abload.de/img/270_atak_zvs7k.png
http://abload.de/img/270_destanig_8xsqs.png

/edit Nov 11th 2014:
Added encodes with x265 1.4+55 --preset slower --tune grain:

x265 10 bit (https://mega.co.nz/#!J0VVVCBB!Sbw1OT8_mQ1dVymWcDAbMNHGPFGOkDp7-P07sfcx4LA)
x265 8 bit (https://mega.co.nz/#!kktVjR6A!7loqK-T65T7ODVTwqaY_YiIM3z8VlTHxf2bD41KVVN8)

http://abload.de/img/x265_grain_10_v9uzv.png
http://abload.de/img/x265_grain_8_n3uxj.png

[Atak_Snajpera]

try aq 1.5 , psyrd 1.5 , psyrdoq 5.

[sneaker_ger]

Thank you for the suggestion, I have added it to the test above. Can't really say I'm satisfied with the result, though.

[destanig]

You could try --aq-mode 1 --aq-strength 2 --psy-rd 1 --psy-rdoq 1
Switching from auto-variance AQ to constant AQ should do the trick. That's what I've been using for grainy sources though never with 10 bit builds

[huhn]

anime with "rain" in the background at 2mbit

x264-10b-r2479-dd79a61
x265-1.3.198-icl14.0-64


all 2 pass
no lossless source because it is a because it is out of a mainstream from a blu ray
custom: x264_10.exe --ref 6 --bframes 7 --b-adapt 2 --merange 64 --subme 11 --me umh --bitrate 2000 (http://www.file-upload.net/download-9544759/customanimationx264.mkv.html)
veryslow: x264_10.exe --preset veryslow --tune animation --bitrate 2000 (http://www.file-upload.net/download-9544762/veryslowanimeatioonx264.mkv.html)
default x265.exe --bitrate 2000 (http://www.file-upload.net/download-9544760/defaultx265.mkv.html)
slow: x265.exe --preset slow --bitrate 2000 (http://www.file-upload.net/download-9544761/slowx265.mkv.html)

x265 is 8 bit. x264 is 10 bit


frame 27
http://abload.de/img/27hgkhf.png
http://abload.de/img/custom27rckjd.png
http://abload.de/img/veryslow27qek76.png
http://abload.de/img/default276yj86.png
http://abload.de/img/slow27t4kwf.png

frame 166
http://abload.de/img/166h8ycd.png
http://abload.de/img/custom166paa26.png
http://abload.de/img/veryslow166f0xil.png
http://abload.de/img/default1668azb3.png
http://abload.de/img/slow1662rlg0.png

frame 363
http://abload.de/img/363nbydw.png
http://abload.de/img/custom363lnb1w.png
http://abload.de/img/veryslow3631sx0w.png
http://abload.de/img/default363mpz2h.png
http://abload.de/img/slow363ndaes.png

frame 456
http://abload.de/img/456umb8l.png
http://abload.de/img/custom456fwaba.png
http://abload.de/img/veryslow45627lyj.png
http://abload.de/img/default456qbzss.png
http://abload.de/img/slow456shxfi.png

i judge the frames later with a better screen too. but x265 looks better on this bad screen. i guess lavfilter used random dithering on them because i used EVR not madVR and all x264 are 10 bit. i don't used madVr because the dithering always results in huge screens.
all x265 screens are a lot small compared to the x264 screens. i wonder why maybe because I didn't used the highbitdeep version from x265.

[sneaker_ger]

Yes, I think dithering and 10 bit coding make bigger file sizes when doing PNG on a screenshot. If you enhance the luma plane(?) you'll probably see why. Personally, I don't plan on ever using 8 bit HEVC encoding since we already have hardware support for that so I find it strange that you chose 10 bit x264 vs. 8 bit x265.

As for the results:
They are similar to what we have seen before: x265 does a better job on edges. Preset slow(er) does visibly help.
On the hair at the end x264 some times looks better but it could be a symptom of 8 bit vs 10 bit.


http://abload.de/thumb/456_4_veryslow_aujry.png
x264 very slow 10 bit (http://abload.de/img/456_4_veryslow_aujry.png)
http://abload.de/thumb/456_5_slowukj6x.png
x265 slow 8 bit (http://abload.de/img/456_5_slowukj6x.png)

lwlibavvideosource("veryslowanimeatioonx264.mkv", stacked=true, format="yuv420p16")
DitherPost()
Histogram(mode="luma")
dither_convert_yuv_to_rgb(matrix="709")
lwlibavvideosource("slowx265.mkv")
Histogram(mode="luma")
dither_convert_yuv_to_rgb(matrix="709")

[sneaker_ger]

You could try --aq-mode 1 --aq-strength 2 --psy-rd 1 --psy-rdoq 1
Switching from auto-variance AQ to constant AQ should do the trick. That's what I've been using for grainy sources though never with 10 bit builds

Thank you for the suggestion - I have added it to the test.

I have done a bunch of additional tests with varying aq and psy options now but so far I've been unable to match x264. Especially in the beginning of the short (not seen in this screenshot) the girl's skirt often turns from grain to uniform in x265's results. I'm giving up for now.

[sneaker_ger]

One more cartoon test, this time less SFX packed but still some action. Mixed light and dark scenes. 2500 kbit/s 2pass.

Conclusion:
Again a win for x265.

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

original (https://mega.co.nz/#!E1UnBB6D!jhooOYLQWl_IgGsIFDKFdv3lmqk1blJ5NvEjOktJKgA)
x264 --preset veryslow --tune animation 10 bit (https://mega.co.nz/#!5p1jgKRT!wCWnWqTWq83kKSoSD8c55J3vw08cBA5uLzQnxVYG1uI)
x265 --preset slower --psy-rd 1 --psy-rdoq 1 (https://mega.co.nz/#!h8lxiaQS!YZunFb1XzwjyNPc8isG2o71d_U-vHkNqpUmkaV1M_i8)

http://abload.de/img/550_b5sk3.png
http://abload.de/img/550_4_u8snj.png
http://abload.de/img/550_5_2ksqb.png

http://abload.de/img/1200_wgs6v.png
http://abload.de/img/1200_4_8lsr3.png
http://abload.de/img/1200_5_qasq2.png

http://abload.de/img/1560_gcs7b.png
http://abload.de/img/1560_4_onscv.png
http://abload.de/img/1560_5_bssl8.png

[sneaker_ger]

A new hollywood-type test. Bitrate 2500 kbit/s 2pass.

Conclusion:
x264 does a much better job on retaining the textures and the grain.

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

original (https://mega.co.nz/#!x5NDlK4I!LTsz-uNPgtqXFw5bIJtvV6-NZwvFVybkBYg_Ftt7oNY)
x264 --preset veryslow --tune film 10 bit (https://mega.co.nz/#!JttDHKaY!LKjsc7KdABWATdNMKQ71r-hQ7KMeBewQd1rh9VXzcYI)
x265 --preset slower --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!JltAAIQY!LExTXgQ0WwNrpaY7gnLKYalE0Ug1X32uiyCTq-lzNYI)

http://abload.de/img/220_musv2.png
http://abload.de/img/220_4_5uszy.png
http://abload.de/img/220_5_pwsbg.png

http://abload.de/img/440_2is52.png
http://abload.de/img/440_4_mesr1.png
http://abload.de/img/440_5_kxswf.png

[foxyshadis]

original
x264 veryslow animation 10 bit (https://mega.co.nz/#!18ln3IjS!cc2Qf58kLXEdm9MeE-b5wvDwG9GmgLHIdSQSXTE6_ko) (11.06 fps, 1.45 fps)
x265 slow psy-rd 1.0 psy-rdrq 1.0 10 bit (https://mega.co.nz/#!pwUmhCbA!sX1qX4Q_RwlBSrif0RsinTh9zDrf2u81i9Mv3fjtzyw) (4.05 fps, 0.89 fps)
x265 slower psy-rd 1.0 psy-rdrq 1.0 10 bit (https://mega.co.nz/#!xttVhSDD!KaZGE4_mJxVYWyLfm-STGVISJX2Rzd_ypcvV4SC09Rc) (3.09 fps, 0.21 fps)

The main thing this test convinced me of is that there's a big benefit to going beyond slow, in terms of very fine detail. Veryslow is probably a small improvement more, at yet another quartering of the speed. Very interesting, that would make more sense for anything resized down.

[sneaker_ger]

The main thing this test convinced me of is that there's a big benefit to going beyond slow, in terms of very fine detail.
Yes, I though so as well. It's no coincidence I used at least preset slower for all tests after that one.

Veryslow is probably a small improvement more, at yet another quartering of the speed. Very interesting, that would make more sense for anything resized down.
Resizing down might be a good test. x264's smaller blocks might put it at a disadvantage at 1080p and most Blu-Rays don't have that much detail anyways.

[sneaker_ger]

New test, basically post #88 (http://forum.doom9.org/showpost.php?p=1694097&postcount=88) but downsized to 720p (AviSynth's spline36resize).

Conclusion:
Still a win for x265 overall but the differences are often small.

x265 preset slower vs. x265 preset veryslow: very small differences. Not even sure whether veryslow is better or worse than slower.


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

original
x264 --preset veryslow --tune animation 10 bit (https://mega.co.nz/#!Y48wwIRQ!6DbbIs9Jdd0XYkKaZ4UoGhkLHfmhYHlk7Y8lsHiy12o) (2nd pass: ~4fps)
x265 --preset slower --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!EktzgZJI!a7JE5ha6v7EpiTWYWUEPmBKvgXtbJ6O785ssu0lWkPo) (2nd pass: ~0.5 fps)
x265 --preset veryslow --psy-rd 1 --psy-rdoq 1 10 bit (https://mega.co.nz/#!sh8xQBxQ!7ZST-repEQPy1r1kgdl_CHETG0ML5aS7Gc-6J8QUuto) (2nd pass: ~0.3 fps)

http://abload.de/img/550_r6kle.png
http://abload.de/img/550_4_wkuqp.png
http://abload.de/img/550_5s_d5jrs.png
http://abload.de/img/550_5vs_c9kwk.png

http://abload.de/img/1200_gdkm5.png
http://abload.de/img/1200_4_ptuas.png
http://abload.de/img/1200_5s_uzka2.png
http://abload.de/img/1200_5vs_rrk11.png

http://abload.de/img/1560_41kqs.png
http://abload.de/img/1560_4_0euwn.png
http://abload.de/img/1560_5s_exker.png
http://abload.de/img/1560_5vs_chjqm.png

[lotusgg]

How can I losslessly capture frames of my choice?
How can I differenciate I from P or B?

[Sharc]

A new hollywood-type test. Bitrate 2500 kbit/s 2pass.

Conclusion:
x264 does a much better job on retaining the textures and the grain.
.....
original (https://mega.co.nz/#!x5NDlK4I!LTsz-uNPgtqXFw5bIJtvV6-NZwvFVybkBYg_Ftt7oNY)


Perhaps a bit off topic: I took your hollywood clip for a "high compression" test scenario (http://forum.doom9.org/showpost.php?p=1694252&postcount=21171)x264 vs x265, aiming at same PSNR. The file size reduction is amazing (forget about grain retention; still watchable though).

[Atak_Snajpera]

PSNR is useless for human eyes/brain ;) Higher value does not mean better quality. All psy algos in fact reduce PSNR scores.

[Sharc]

PSNR is useless for human eyes/brain ;) Higher value does not mean better quality. All psy algos in fact reduce PSNR scores.
Absolutely, but comparing individual frames is also problematic.
For my compression tests I actually disabled all the aq and psy's in order to make the PSNR perhaps more comparable/meaningful. I also watched the clip - with my eyes of course.
I am not aware of any perfect metric for the "quality" rating. The problem is that one often focuses on certain criteria like details, grain, dark scenes, high motion, flat areas, fading scenes, fog .... etc. -- not easy.
My main point was the huge reduction of the original file size, still producing a "watchable" result. :)

[lotusgg]

Testing with a colorful, bright anime packed with action and also dark scenes at 1000kbit/s.

Don't know how to capture certain frames from a clip, so I will let the sources here and hope someone PM me with a solution.

Lossless (http://www.firedrive.com/file/3EB7AB54091B1A8A) - 2.3gb
x264 10bits CUSTOM --preset placebo --bitrate 1000 --ipratio 1.0 --pbratio 1.0 --aq-mode 2 --me umh --subme 10 --psy-rd 0.00:0 (https://mega.co.nz/#!aNARzART!fa9OkUhQDax8lWwC0z2r8VFml34FuIwFmf4rXqGBrDE) - 25mb - encoding speed: ~1,50fps
x265 10bits CUSTOM --preset medium --weightb --bframes 16 --rc-lookahead 40 --merange 57 --no-open-gop --min-keyint 25 --ipratio 1.0 --pbratio 1.0 --ctu 64 --aq-strength 1 (https://mega.co.nz/#!rFgF1TBS!kAHeINw1KvrEwiJ6rhSpZlUPc2P_D8SLP0bvirSP4aQ) - 25mb - encoding speed: ~3,20fps

x265 was faster than x264.
didn't watched it yet, because it's on the ded's drive and my internet is super lazy today.

[Atak_Snajpera]

LOL placebo vs medium. No wonder x265 was faster. What a surprise !

[lotusgg]

B-But it was custom.
Medium is just because I'm lazy to put it on veryslow and remove some params, since I use it ever before 1.1 release.
Also, x264 got reduced some params there.

[sneaker_ger]

didn't watched it yet, because it's on the ded's drive and my internet is super lazy today.

I did watch it. This is so bitrate-starved that it may come down to what artifacts you prefer. My preference changes from scene to scene.