x265 HEVC Encoder

[zerowalker]

Well it's good news, medium is the one who should be in the middle ground, and that is really something that Slow and above(below?) should use.
This makes it at least 50% faster, so tests can be done at greater speed;P!

[kensan]

Does anyone knows how to change main and main10 profile after compiling? What is the option to switch. If HIGH_BIT_DEPTH is ON, main10 profile is generated, and if OFF, main profile is generated, I think.

And YUV 8bit input can be encoded to main10 10bit stream like HM? Could you tell the option?

Regards,

[LoRd_MuldeR]

HIGH_BIT_DEPTH is a compile-time option, you cannot change this at runtime!

And since 10-Bit HEVC requires the "Main 10" profile, this is what you will get, if your x265 binary was compiled with HIGH_BIT_DEPTH enabled.

http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles

[x265_Project]

Does anyone knows how to change main and main10 profile after compiling? What is the option to switch. If HIGH_BIT_DEPTH is ON, main10 profile is generated, and if OFF, main profile is generated, I think.

And YUV 8bit input can be encoded to main10 10bit stream like HM? Could you tell the option?

Regards,
As Lord Mulder said... if HIGH_BIT_DEPTH is set on when you build x265, you will build the 16 bits per pixel (bpp) version of x265, and all encodes from this build will be Main10 profile. If it is off, you will get the 8 bpp build of x265, and all encodes from this build are Main profile. There is no runtime selection.

No option is required to encode an 8bit video as Main10. Just tell the 16 bpp build of x265 the input bit depth: x265 foo.yuv --input-res 1920x1080 --fps 24 --input-depth 8 out.hevc.

[LigH]

Version 1.1 is coming "soon™", so there was a stable merge again. There have been many preset changes to make them a lot faster with only little quality penalty.

Therefore another MinGW build: x265 1.0+151-108996798e78 (https://www.mediafire.com/?b5wev7k73gb1ndt)

[x265_Project]

The latest build includes improvements to psy-rd, and it looks like things are working better now.

I'm seeing some artifacts when the psy-rd strength is higher, but I'm seeing a nice improvement in picture quality with the limited testing I've done at lower strengths (0.2 to 0.5).

[x265_Project]

Version 1.1 is coming "soon™", so there was a stable merge again. There have been many preset changes to make them a lot faster with only little quality penalty.

We have sped up the ultrafast preset by about 10 to 30% (bigger benefit at higher bit rates). There is a very small impact on encoding efficiency, but you can always increase efficiency by using a slower (higher quality) preset. We've also sped up the superfast, veryfast and faster presets in a similar way.

[x265_Project]

There is also a new lossless mode. Of course, lossless encoding will generate high bit rates, but the decoded content should be identical to the uncompressed source.
--lossless forces full lossless coding of every frame and every CU. --lossless will make the output bit-exact to the input regardless of preset. As lossless mode still uses motion estimation, slower presets will generally give you better lossless compression.

--cu-lossless forces the encoder to perform RD cost analysis between lossy and lossless modes and choose the least cost mode for each CU. The mode decision algorithm will create one more candidate where the transform and quantization was skipped for the CU. It will compare the RD cost for this lossless CU to all the other encode candidates. If the RD cost is better, it will use it. This just adds one more encode candidate to the mode decision. --cu-lossless will not guarantee a lossless bitstream. It is generally only useful for very high quality (slow, higher bit rate) encodes where you want every bit of efficiency possible.

[Procrastinating]

Has x265 lossless size been compared to x264 lossless? Another thread showed that x264 --slow was pretty competitive with codecs designed with lossless storage in mind, though obviously a lot slower.

Similarly, would lossless compression be expected to improve even marginally over time, or is that more fixed to the specification?

[x265_Project]

Has x265 lossless size been compared to x264 lossless? Another thread showed that x264 --slow was pretty competitive with codecs designed with lossless storage in mind, though obviously a lot slower.

Similarly, would lossless compression be expected to improve even marginally over time, or is that more fixed to the specification?
The lossless feature has just been implemented, and so it hasn't been tested extensively.

Lossless HEVC compression can be expected to improve over time, for a couple of reasons. First, the Joint Collaborative Team on Video Coding (the experts who developed the HEVC standard) are continuing their work on extensions to the standard, including enhancements specifically designed to improve lossless encoding efficiency. Second, lossless encoding takes advantage of inter-prediction (a.k.a. motion estimation, or temporal encoding), finding redundancies in previous or subsequent frames. Multiple encoding candidates can be compared for each block to see which one encodes most efficiently. So, as with the normal, lossy compression that x265 provides, it's possible to spend more time to find more redundancy, producing more efficiency. We haven't done any optimization for the lossless mode, but there is almost certainly room for future improvement.

[Farfie]

In light of recent discussion regarding further preset optimization, I decided to start removing --rect and --amp from my encode command line to see what kind of difference it would make. Initially the speed increase was very obvious, from 2.3~ to 5.3~ FPS when using Slow, --tune SSIM (I know it's default but whatever :)). What I noticed next was strange... the size of the resulting file was also smaller than its counterpart with both switches enabled.So --rect and --amp put ~100% more stress on my CPU in order to make a larger file!

Could it be related to the specific content I'm encoding? Because I'm also not seeing a visual benefit either, though I didn't expect it to, because while the file IS bigger, it's not by much... 2,050,837KB to 2,119,957KB with switches.

Strange or no? Do these switches go beyond what reading the thread has made me to believe they are for, which in my mind was a simple efficiency for speed tradeoff?

edit:
Pardon, should add this was using 2014-06-02: 64 Bit-(d93801eda07e76cb32c85834760306e1) from http://builds.x265.eu/

[LoRd_MuldeR]

The latest build includes improvements to psy-rd, and it looks like things are working better now.

Yeah, I definitely see some improvement! But also looks like it's not fixed completely yet:
http://www.mediafire.com/download/fs08d8dls07w8xf/x265-psyrd-test.rar

There's still some very apparent "wobbling" effect. You can see it clearly at the beginning of the clip, on the right side of the face (near his left ear).

Also, but not necessarily related to Psy-RD, the brick wall looks smoothed out initially. But then, shortly after the camera pan is complete, the details are popping up.

[x265_Project]

Yeah, I definitely see some improvement! But also looks like it's not fixed completely yet:
http://www.mediafire.com/download/fs08d8dls07w8xf/x265-psyrd-test.rar

There's still some very apparent "wobbling" effect. You can see it clearly at the beginning of the clip, on the right side of the face (near his left ear).

Also, but not necessarily related to Psy-RD, the brick wall looks smoothed out initially. But then, shortly after the camera pan is complete, the details are popping up.
What was your command line?

[LoRd_MuldeR]

What was your command line?

Everything on default, except for what is required to enable Psy-RD ("--preset veryslow" + "--psy-rd 1"). Version 1.0+156, clean MSVC build.

[x265_Project]

Everything on default, except for what is required to enable Psy-RD ("--preset veryslow" + "--psy-rd 1"). Version 1.0+156, clean MSVC build.

I looked at your clip, and I see what you are referring to. I'm not surprised. I'm seeing these types of artifacts also if psy-rd strength is set too high.

As I mentioned, I wouldn't suggest a psy-rd strength of 1.0 at this point. Forget what you know about x264... x265 is a different animal, and psy-rd is still in the tuning phase. We may need to recalibrate in the future to make 1.0 the default strength. For now, I would try encodes with psy-rd strength of around 0.2 to 0.5. Experiment and see what works best.

[LoRd_MuldeR]

Okay, I think a psy-rd strength of 0.2 looks okay. At strength 0.5 the problem appears again, but much less than at strength 1.0. Though I'm not sure whether I prefer 0.0 or 0.2 in this clip.

x265 Psy-RD 0.0 vs. 0.2 vs. 0.5:
http://www.mediafire.com/download/6w3kgq9u101lqed/x265-psyrd-compare.rar

[x265_Project]

Release 1.1 has been tagged. This is an incremental update with several important rate control improvements and a few new features.

= New Features =

1. Psycho-visual rate distortion optimizations. These RD optimizations are only effective on presets which use RDO (rd levels 5 and 6).
Psy-rd is still considered experimental in this release and is not enabled by default. We recommend evaluating with a low psy weight factor, for instance: --rd 5 --psy-rd 0.4

2. Lossless coding. This release of x265 can create a bit-accurate output bitstream by using --lossless. This feature disables rate control and distortion metrics, and instead just reports the compression ratio at the end of the encode. Lossless coding is considered experimental in this release, we believe there is room for improvement in both compression efficiency and performance.

3. Support for Y4M streams with more than 8 bit depth (for example, ffmpeg -i vid.avi -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | ./x265 - --y4m o.hevc)

= API Changes =

* new x265_picture.forceQp for qpfile functionality
* new param.levelIdc to force a decoder requirement level
* new param.psyRd for (experimental) psycho-visual rate distortion optimizations
* new param.bIntraInBFrames to disable intra predictions in B slices regardless of preset
* new param.noiseReduction, very similar to x264 noise reduction
* new param.bLossless to enable lossless coding (experimental)
* new param.bCULossless to include trans-quant bypass modes in CU RD analysis
* new param.rc.rfConstantMin to limit rate factors in rate control
* param.rc.aqMode now defaults to 2 (to match CLI behavior)

new x265_encoder_parameters() function which retrieves a copy of the active parameters from the encoder. x265_encoder_open() was modified to ensure it never modified the param structure passed to the function; it makes a private copy of the param prior to making any modifications to it.

The default setting (the medium preset) was be adjusted to include the --no-rect and --no-amp options, becoming faster (on average, about 70%, but as much as 90%), with a very slight (~ 1 - 4%) impact on encoding efficiency.

We have sped up the ultrafast preset by about 10 to 30% (bigger benefit at higher bit rates). There is a very small impact on encoding efficiency, but you can always increase efficiency by using a slower (higher quality) preset. We've also sped up the superfast, veryfast and faster presets in a similar way.

= CLI Changes =

New options:
--level
--repeat-headers (older feature, newly exposed to CLI) --nr --lossless --psy-rd --crf-min --no-b-intra --cu-lossless --qpfile

--tune fast-decode now also disabled intra in B frames

As always, the most detailed documentation for the command line arguments can be found in our online documentation:
http://x265.readthedocs.org/en/1.1/

= Rate Control =

Single pass ABR received a lot of attention in this release, in particular the tendency for ABR to undershoot and overshoot wildly in the first two seconds of the video. We added two new features to ABR to limit this tendency. First, we now amortize a portion of the cost of I frames across many frames. Second, we limit frame parallelism until we have about a half-second of P frames encoded. Together these two changes have greatly improved the ability of single pass ABR to arrive at the good QP for the first GOP without any large swings.

Further improvements were made to ABR to allow it to reach very high bit rates.

We also did some re-balancing of CRF between Main and Main10 so they achieve closer quality, and several fixes were made to VBV.

Recovery Point SEI are now generated at each keyframe

In the near future we will be focusing on two-pass encoding and making mode decision more efficient.

[LoRd_MuldeR]

Here's a fresh set of x265 v1.1 binaries:
x265-win-msvc2013.2014-06-04.rar (http://www.mediafire.com/download/qllbo1bqw6easbp/x265-win-msvc2013.2014-06-04.rar)

(MSVC 2013.2, 32-Bit and 64-Bit binaries, 8-bpp and 16-bpp)

[LigH]

x265 1.1+3-1fe42453d2e3 (https://www.mediafire.com/download/h45yzrgxjn86s46/x265_1.1+3-1fe42453d2e3.7z) is up. Time to clean up my HEVC folder (https://www.mediafire.com/folder/6lfp2jlygogwa//HEVC) a bit and remove 0.8 versions.

[Atak_Snajpera]

x264 --crf 22 --preset medium (average bitrate 966 kbps)
http://i.imgur.com/4ZRwIi5.png

x264 --crf 22 --preset veryslow (average bitrate 886 kbps)
http://i.imgur.com/gTqmkjJ.png

x265 --crf 20 --preset medium (average bitrate 992 kbps)
http://i.imgur.com/TT9h3Ok.png
(http://i.imgur.com/TT9h3Ok.png)


UPDATE

x265 --crf 20 --preset medium --rd 6 --psy-rd 0.2 (average bitrate 915 kbps)
http://i.imgur.com/iu1fWmh.png

x264 --crf 20 --preset veryslow --no-psy (average bitrate 903 kbps)
http://i.imgur.com/6DTT23H.png

In this example x265 with psy looks more or less like x264 with psy disabled. In other hand x264 with enabled psy looks much better than without it. Unfortunately We still do not see that big leap in quality with x265's psy yet.

UPDATE 2

x265 --crf 20 --preset medium --rd 6 --psy-rd 0.5 (average bitrate 957 kbps)
http://i.imgur.com/TXTdeHp.png

x265 --crf 20 --preset medium --rd 6 --psy-rd 1.0 (average bitrate 1060 kbps)
http://i.imgur.com/42gksNo.png

[x265_Project]

In this example x265 with psy looks more or less like x264 with psy disabled. In other hand x264 with enabled psy looks much better than without it. Unfortunately We still do not see that big leap in quality with x265's psy yet.

Try a little bit higher --psy-rd strength... 0.4 to start with.

[nekrosoft13]

i'm quite new to x265, can files be smaller (at smaller kbps) compared to x264 and still have the same image image quality?

if yes, about how much smaller?

[sneaker_ger]

The comparisons between x264 and x265 are inconclusive at this point in time. Sometimes x265 is better, sometimes worse than x264.

[benwaggoner]

The comparisons between x264 and x265 are inconclusive at this point in time. Sometimes x265 is better, sometimes worse than x264.
For low-bitrate UHD content, x265 beats x264 by a huge margin, at least with --preset veryslow.

It does require a lot of patience, though :).

[Atak_Snajpera]

A lot of patience or multiple 14c / 24t xeons on board ;) x265 can easily degrade your fancy overclocked i7 to the "pentium 4" level ;)

[benwaggoner]

A lot of patience or multiple 14c / 24t xeons on board ;)
Both :). I'm getting ~200:1 times on a sixteen core Ivy Bridge! Tuned for absolute quality to an unreasonable degree; I'm sure I could be a lot faster with only a few extra percent bitrate.

[Romario]

Nice changes, x265_project. :)

But I wait 2-pass encoding. Is it possible for version 1.2 ?

[x265_Project]

Nice changes, x265_project. :)

But I wait 2-pass encoding. Is it possible for version 1.2 ?
Thanks.

We're just starting to work on 2-pass encoding. It will take more than one milestone.

[Atak_Snajpera]

Try a little bit higher --psy-rd strength... 0.4 to start with.

I've have updated my post with 0.5 and 1.0. Still x264's psy looks better.

[benwaggoner]

I've have updated my post with 0.5 and 1.0. Still x264's psy looks better.
The differences are pretty small though, particularly as the frame is paused. And both encodes look pretty good.

It might be interesting to compare at 500 Kbps where HEVC compression efficiency will have more to do.

Also, I thought psy-rd didn't kick in without --rd of 5+

See http://x265.readthedocs.org/en/default/cli.html?highlight=psy-rd#cmdoption--psy-rd

--psy-rd <float>
Influence rate distortion optimizations to try to preserve the energy of the source image in the encoded image, at the expense of compression efficiency. 1.0 is a typical value. Default disabled. It only has effect on presets which use full RDO-based decisions (slower, veryslow and placebo)

Range of values: 0 .. 2.0

Although the --help says Slow, not Slower is the minimum required.

--psy-rd <0..2.0> Strength of psycho-visual optimization. Requires slow preset or below. Default 0.000000

Given Slow is --rd 4 and Slower+ is --rd 6, I think the online documentation is correct. So I'd test with at least --preset slower.

[Atak_Snajpera]

but i forced --rd 6 ! Take a look at my post again.

I think that ~1mbps for 1280x534 is already very low. Besides x264 veryslow is at least 2x faster than x265 with medium preset plus rd 6 and still looks great.

For sane bitrates x264 is still a better choice for most users.

[benwaggoner]

but i forced --rd 6 ! Take a look at my post again.
Ah, sorry.

I think that ~1mbps for 1280x534 is already very low.
Low for x264. But low for HEVC? I don't think we know that yet?

Besides x264 veryslow is at least 2x faster than x265 with medium preset plus rd 6 and still looks great.
Sure. And we can't expect that x265 would ever be as fast as x264, as it just has so many more choices it can make. The expectation is that with HEVC we'll be able to trade of longer encoding time for significantly lower bitrates versus H.264.

I think it's too early to start worrying about quality @ speed with x265, since it's had many years less optimization than x264. Its potential quality is more interesting today.

For sane bitrates x264 is still a better choice for most users.
But sane bitrates are defined by what looks good in x264, so that's kind of a circular definition. Sane bitrates were a lot higher five years ago, and they'll be a lot lower in five more. I'd like to see how x264 and x265 compare at a sane bitrate for HEVC. There's definitely a crossover point below which the greater intrinsic efficiency of HEVC makes up for the relative rawness of x265's perceptual quality tuning versus x264. And that crossover point is getting higher.

[Atak_Snajpera]

at 1mbps both x265 and x264 already have problems to keep fine details. I will post tomorrow original frame to show you how many fine details on his face is removed. if i reduce bitrate 2 times x265 will have to remove even more details. I don't think you will enjoy watching wax figures instead of actors ;)

[Romario]

Thanks.

We're just starting to work on 2-pass encoding. It will take more than one milestone.

Ok, thanks on answer.

Can you, please, tell me about future optimisations. I wait for more FPS then we have now. When we can except GREAT optimisations in speed ?

[foxyshadis]

Ok, thanks on answer.

Can you, please, tell me about future optimisations. I wait for more FPS then we have now. When we can except GREAT optimisations in speed ?

The Wiki TODO page (https://bitbucket.org/multicoreware/x265/wiki/TODO) is reasonably up to date with what's coming up, in no particular order. You can look at the history and see how much has been accomplished. The only answer to "when" is "when it's done" or "maybe not ever", so I don't think that's a useful question; the conversion of everything to assembly may have been the last big free performance boost for a while. We'll have to see.

[Atak_Snajpera]

Uncompressed frame
http://i.imgur.com/MU2RNcd.png

x265 --crf 20 --preset medium --rd 6 --psy-rd 1.0 (average bitrate 1060 kbps)
http://i.imgur.com/42gksNo.png

x264 --crf 22 --preset veryslow (average bitrate 886 kbps)
http://i.imgur.com/gTqmkjJ.png

[fumoffu]

Cool comparison and the results are rather sad ;/
but your uncompressed frame is not the same frame...

[Atak_Snajpera]

but your uncompressed frame is not the same frame...

nope!

frame 6519
http://i.imgur.com/RP0rHp9.png

frame 6520 (from previous post)
http://i.imgur.com/aGKEjdC.png

frame 6521
http://i.imgur.com/b4UC66H.png

[fumoffu]

hmm weird...
in both encoded versions the left eyebrow/eyelashes seem higher and light reflexes in eyes are different from uncompressed but the same in x264 and x265. I guess motion estimation/compression algorythms are similar in both?
Just in case: what do you use for grabbing those frames? I'm asking because for example MPC-HC which I usually use for this is very unreliable with frame numbers and it often goes to the wrong one. And from the ones you posted it looks like they are out of order, it seems they should go: 6520,6521,6519... (or the other way around 6519,6521,6520)

[LigH]

A more reliable way to catch the same frame is probably using AviSynth with L-SMASH Works and ImageWriter.

[benwaggoner]

nope!

frame 6519
http://i.imgur.com/RP0rHp9.png

frame 6520 (from previous post)
http://i.imgur.com/aGKEjdC.png

frame 6521
http://i.imgur.com/b4UC66H.png
Can you share the actual video files for these? It's hard to judge how visible these differences would be in motion as opposed to a still image.

[Sagittaire]

Uncompressed frame
http://i.imgur.com/MU2RNcd.png

x265 --crf 20 --preset medium --rd 6 --psy-rd 1.0 (average bitrate 1060 kbps)
http://i.imgur.com/42gksNo.png

x264 --crf 22 --preset veryslow (average bitrate 886 kbps)
http://i.imgur.com/gTqmkjJ.png

and as always that doesn't mean anything because you can have pframe for x264 and bframe for x265. For the same sample you can certainely say that x265 win with pframe if x264 use pyramidal bframe. Conclusion for frame N will be not the same for frame N+1. If you want make comparison like that, you must use x264 and x265 in constant quantizer mode and certainely not in cfr mode.

[Atak_Snajpera]

i will upload full 10 min samples tomorrow so you can judge yourself. x265 psy is always more blury than x264's psy. I would have to increase psy strength to atleast 1.5 to achieve similar level of detail. Unfortunatelly this would generate even higher average bitrate.

[LoRd_MuldeR]

I would have to increase psy strength to atleast 1.5 to achieve similar level of detail. Unfortunatelly this would generate even higher average bitrate.

You should always compare clips of the same size (same average bitrate), otherwise the comparison is meaningless.

So if Psy-RD strength 1.5 increases the bitrate in CRF mode, you need to increase your CRF value in order to compensate. Or use ABR mode right away.

Anyway, from my tests Psy-RD strength 1.5 will be far too high. I was getting very obvious artifacts with a strength of "only" 1.0 :scared:

(x265 project recommends something in the 0.2 to 0.4 range)

[mandarinka]

Yes, but strength 0.5 is really too little to attain grain/texture retention like x264 can, he's correct in that.

[Atak_Snajpera]

x265 --crf 20 --preset medium --rd 6 --psy-rd 1.0 (average bitrate 1060 kbps) - ENCODING TIME : 22m55s
https://mega.co.nz/#!kM80wCTI!rIhFZ40t-9i_yISWiUN_rJ-4pEG6sdgi_7dlLY0f-a4

x264 --crf 21 --preset veryslow (average bitrate 1031 kbps) - ENCODING TIME : 9m22s
https://mega.co.nz/#!0ZcxzajB!QjH8qs4CX0GEZLtJkrUq6qEWkjA40ScXX1s3WR01K5E

frame 6310
x264 -> http://i.cubeupload.com/165cDq.png
x265 -> http://i.cubeupload.com/MAGGW7.png

frame 7380
x264 -> http://i.cubeupload.com/LaMR7r.png
x265 -> http://i.cubeupload.com/Dn0t5C.png

frame 12630
x264 -> http://i.cubeupload.com/IGLRca.png
x265 -> http://i.cubeupload.com/YQIGuD.png

[Sagittaire]

x265 --crf 20 --preset medium --rd 6 --psy-rd 1.0 (average bitrate 1060 kbps) - ENCODING TIME : 22m55s
https://mega.co.nz/#!kM80wCTI!rIhFZ40t-9i_yISWiUN_rJ-4pEG6sdgi_7dlLY0f-a4

x264 --crf 21 --preset veryslow (average bitrate 1031 kbps) - ENCODING TIME : 9m22s
https://mega.co.nz/#!0ZcxzajB!QjH8qs4CX0GEZLtJkrUq6qEWkjA40ScXX1s3WR01K5E

frame 6310
x264 -> http://i.cubeupload.com/165cDq.png
x265 -> http://i.cubeupload.com/MAGGW7.png

frame 7380
x264 -> http://i.cubeupload.com/LaMR7r.png
x265 -> http://i.cubeupload.com/Dn0t5C.png

frame 12630
x264 -> http://i.cubeupload.com/IGLRca.png
x265 -> http://i.cubeupload.com/YQIGuD.png

Well I don't understand very well your demonstration. crf 21 for x264 is not really a hard challenge for quality. Certainely that xvid will provide excellente quality too here. x264 is perhaps more sharp and x265 seem more flat for it's for really expert eyes.

Try with 500 kbps and make comparison with same sample and the conclusion will be radicaly different ... :D. For me H265 is designed for make 4K on DVD9 size, 1080p encoding on DVD5 size or 720p encoding on CDR size with really high quality.

[benwaggoner]

Well I don't understand very well your demonstration. crf 21 for x264 is not really a hard challenge for quality. Certainely that xvid will provide excellente quality too here. x264 is perhaps more sharp and x265 seem more flat for it's for really expert eyes.

Try with 500 kbps and make comparison with same sample and the conclusion will be radicaly different ... :D. For me H265 is designed for make 4K on DVD9 size, 1080p encoding on DVD5 size or 720p encoding on CDR size with really high quality.
I concur the tests will be more interesting at lower bitrates.

Also, why even do CRF? For apples-to-apples 1-pass CBR makes more sense to me. 500 Kbps? With --vbv-maxrate 500 and --vbv-bufsize 1000?

Lastly, I think the same --preset veryslow should be used in both encodes. We know x265 isn't fully optimized, and if we're not trying to do a quality @ speed test, we should let each codec strut its stuff to see what the potential quality deltas are. Quality @ speed is important, but let's just test one variable at a time.

[Atak_Snajpera]

I prefer practical tests that's why i used very popular constant quality mode. Preset very slow should be renamed to insanely slow. It is so slow that it is practicaly useless. What will be your next excuse to disapointing quality? Maybe I should use reference encoder next time???

What's the point of reducing bitrate even further if even at current 1mbps we see lack of the details on actors faces. Unlike you sagitare I hate watching actors with applied photoshop's surface blur.

[zerowalker]

The thing is that x265 currently, can only beat x265 when the bitrates are so low that the fundamental structure of it breaks.
x264 will turn into a block madness, x265 will look like HD vs SD when you compare the two.

When you reach the breaking point where x264 hasn enough bitrate to make the picture, it turns the tide.

This however, as far as i know, is because x264 is optimized for ages and beyond, x265 is more advanced and offers more complexity, but the encoder isn't using everything to it's advantage, like x264 is now.

So i look at it simply as an x264 all over again, but which a greater span of evolution available to it, (Think of it as x264 goes to lvl 99, but x265 can go to 100 and beyond;P).

(How these statements are correct in some sense anyway)