x265 HEVC Encoder

[mzso]

Here are examples of aliasing I saw with x265 encodes:
https://drive.google.com/open?id=0ByfdfPvnoDuzNUdidHRRenMyQlE

https://drive.google.com/open?id=0ByfdfPvnoDuzVk5IakRzZDd0eVk

Does anyone have a clue why it happens?

[littlepox]

It's due to the very distinct pattern on his face after down-scaling.
Technically it is called "Moiré pattern".
It has nothing to do with the encoder unless the encoder performs a blur filter before encoding.

[x265_Project]

Hi!

Is aliasing a significant issue for x265 (our HEVC)? I came across two separate x265 encoded files of the same thing. The higher bitrate one had some pretty bad aliasing where there were fine patterns. The lower bitrate one was even worse with with more stuff aliased an aliasing being more pronounced.

It looks like something went wrong in a processing step prior to encoding... probably in scaling, or chroma subsampling.

[Ma]

There are stability problems with newest Microsoft compilers -- VS 2015 update 3 & VS "15" preview 5. 12-bit x265 compiled with CXXFLAGS=/arch:AVX /GS- /GL hangs at beginning of encoding. (VS 2013 update 5 & VS 2015 update 2 works OK.)

I have a request to a person with AVX2 CPU -- could you test AVX & AVX2 version of 12-bit x265 compiled by VS "15" preview 5 and report back if it works (it hangs at i5 3450S, but it is possible that it works at AVX2 CPU).
VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5.7z (it works, no need to test)
AVX-CPU VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5-AVX.7z (x265-12b.exe hangs on AVX CPU)
AVX2-CPU VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5-AVX2.7z (not tested -- I don't have AVX2 CPU)

[trip_let]

There are stability problems with newest Microsoft compilers -- VS 2015 update 3 & VS "15" preview 5. 12-bit x265 compiled with CXXFLAGS=/arch:AVX /GS- /GL hangs at beginning of encoding. (VS 2013 update 5 & VS 2015 update 2 works OK.)

I have a request to a person with AVX2 CPU -- could you test AVX & AVX2 version of 12-bit x265 compiled by VS "15" preview 5 and report back if it works (it hangs at i5 3450S, but it is possible that it works at AVX2 CPU).
VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5.7z (it works, no need to test)
AVX-CPU VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5-AVX.7z (x265-12b.exe hangs on AVX CPU)
AVX2-CPU VS "15" preview 5 clean builds: www.msystem.waw.pl/x265/x265-2.1+20-c64393b_vs15p5-AVX2.7z (not tested -- I don't have AVX2 CPU)

12-bit AVX build from x265-2.1+20-c64393b_vs15p5-AVX.7z and 12-bit AVX2 build from x265-2.1+20-c64393b_vs15p5-AVX2.7z work fine for me.

I let it go for about 1000 frames before I stopped the process. This on a Core i7-6700K.

[Ma]

12-bit AVX build from x265-2.1+20-c64393b_vs15p5-AVX.7z and 12-bit AVX2 build from x265-2.1+20-c64393b_vs15p5-AVX2.7z work fine for me.

I let it go for about 1000 frames before I stopped the process. This on a Core i7-6700K.

Thanks!

It looks like newest M$ compilers emit AVX2 only instruction with /arch:AVX option. I will try to report this bug.

[Barough]

x265 v2.1+20-c64393b415ad (http://www50.zippyshare.com/v/2oAFG6Oa/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[LigH]

x265 2.1+20-c64393b415ad (GCC 5.3.0) (https://www.mediafire.com/file/mk3ixj5iric4gbc/x265_2.1+20-c64393b415ad.GCC530.7z)
x265 2.1+20-c64393b415ad (GCC 6.2.0) (https://www.mediafire.com/file/ooasvtcipb8og4v/x265_2.1+20-c64393b415ad.GCC620.7z)

CLI changes since v2.1+2:

+ --limit-tu <integer> Enable early exit from TU recursion for inter coded blocks. Default 0

- --discard-sei Discard SEI packets in bitstream. Default disabled
- --discard-vui Discard optional VUI information from the bistream. Default disabled
+ --[no]-vui-timing-info Discard optional VUI timing information from the bistream. Default enabled
+ --[no]-vui-hrd-info Discard optional HRD timing information from the bistream. Default enabled

^ The small syntax typo will surely be corrected soon... ([no-]... instead of [no]-...).

The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality.
__

P.S.: Don't try --limit-tu >2.

Invalid limit-tu option, limit-TU must be 0, 1 or 2

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.

[fauxreaper]

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.

limit-tu only works with tu-inter-depth>1.

[benwaggoner]

x265 2.1+20-c64393b415ad (GCC 5.3.0) (https://www.mediafire.com/file/mk3ixj5iric4gbc/x265_2.1+20-c64393b415ad.GCC530.7z)
x265 2.1+20-c64393b415ad (GCC 6.2.0) (https://www.mediafire.com/file/ooasvtcipb8og4v/x265_2.1+20-c64393b415ad.GCC620.7z)
The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality.
__

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.
I have a few more --limit-tu questions as well.


What does the default of 0 do? Is it the same as --no-limit-tu?
Is the expectation that 2 is faster and potentially lower quality than 1?

[brumsky]

@x265_project

Thank you guys so much! I've been wishing for a option like this for some time.

A few quick tests show a performance drop of ~.5% with a file size ~2% smaller. This is comparing inter 1 vs inter 4 + limit tu 1. Without limit tu, inter 4 is ~ 20% slower.

So far I see no visible quality difference.

Great job!!!

Could you explain the differences between limit tu 1 + 2 a bit more in depth, please? :)

[easyfab]

I wonder how much speed gain will be possible without a noticable additional loss of quality.
.

according to this https://mailman.videolan.org/pipermail/x265-devel/2016-October/010702.html

it seems there is no significant loss of quality for a good gain of speed with slower presets

[LigH]

limit-tu only works with tu-inter-depth>1.

This leads to the follow-up question: When does that happen? — For preset defaults slower than "slow".

slower = 2
veryslow = 3
placebo = 4

They are all no choice for a CPU without AVX support, I fear... :o

[stevendj]

Hi all,

I noticed a speed decrease between today's x265 and an earlier version of it.
Using builds from builds.x265.eu I narrowed the change I'm talking about down to be between the following versions:
1.9+217 (https://builds.x265.eu/x265-64bit-8bit-2016-06-30.exe)-626fcbac7ffb
1.9+223 (https://builds.x265.eu/x265-64bit-8bit-2016-07-01.exe)-17c0c875f27d

Encoding the same input video with the same settings takes 5%-30% longer in +223 compared to +217.
File size and visual quality of the output are virtually the SAME.

These commits can currently be found at the fourth page of the commits list on Bitbucket.
I also attached a screenshot of the 6 commits that could have caused this slowdown.

The new recursion skip a.k.a. --rskip seems like something big that could have caused the different encoding time, so I tried --no-rskip, but that (logically) only further increased the encoding time.

Could some other people perhaps test if they see a significant slow down between these versions too?

Thanks in advance

[Ma]

Encoding the same input video with the same settings takes 5%-30% longer in +223 compared to +217.
File size and visual quality of the output are virtually the SAME.

Could you specify your encoding settings?

[Motenai Yoda]

This leads to the follow-up question: When does that happen? — For preset defaults slower than "slow".

slower = 2
veryslow = 3
placebo = 4

They are all no choice for a CPU without AVX support, I fear... :o
virtually they can change preset defaults to use tu-inter 2/3 on faster presets with limit-tu 2/1 w/o sensible speed impact

also as the doc says
--limit-tu <0|1|2>
Enables early exit from TU depth recursion, for inter coded blocks.
Level 1 - decides to recurse to next higher depth based on cost comparison of full size TU and split TU.
Level 2 - based on first split subTU's depth, limits recursion of other split subTUs.
Default: 0

so testing anything over 2 has no sense

[brumsky]

Hi all,

I noticed a speed decrease between today's x265 and an earlier version of it.

This will explain the performance difference you are seeing.

http://forum.doom9.org/showpost.php?p=1779902&postcount=4237

At least it should. :)

[stevendj]

Could you specify your encoding settings?

I can reproduce the difference with just preset slower & crf 23.
I also tried preset medium, but the issue seems non-existent there.

It seems especially reproducible when encoding animated content, less so with 'real-life footage'.
Now that I've done some more testing, I do see a quality increase in the 'real-life footage' encodes (so good job x265 team!),
but when encoding animated content -in my opinion so far- the quality doesn't visibly change while the extra encoding time is noticable..

[benwaggoner]

but when encoding animated content -in my opinion so far- the quality doesn't visibly change while the extra encoding time is noticable..
Animation is pretty easy to encode. If it's already looking pretty much dialed in, than encoder improvements aren't going to do visually. Try raising your CRF by 3 and redoing the comparison.

[stevendj]

Animation is pretty easy to encode. If it's already looking pretty much dialed in, than encoder improvements aren't going to do visually. Try raising your CRF by 3 and redoing the comparison.

Tried it, and even tried raising it by 6:
There is a small quality increase, but a ~30% slower encode by my testing. (I only ran 1 test with this higher crf, on animation)

Dear x265 Team, if in the future you would want to optimise x265 for animated content, I guess you should also look into how --rskip behaves on animation.

Edit: all you hard & good work is much appreciated, though!

[Ma]

I can reproduce the difference with just preset slower & crf 23.

So I made speed test with options "-p slower --crf 23" on Win7 64-bit, i5 3450S, test file 1920x800 BD movie 750 frames.

Relative encoding time (to x265 1.9+217; less -- faster):
enc.time| description
100.0% | x265 1.9+217
107.8% | x265 1.9+223
108.4% | x265 2.1+21
106.3% | x265 2.1+21 --limit-tu 1
105.2% | x265 2.1+21 --limit-tu 2

--limit-tu 1 & --limit-tu 2 produce the same output in my test.

Raw data in attachment.

[pingfr]

So I made speed test with options "-p slower --crf 23" on Win7 64-bit, i5 3450S, test file 1920x800 BD movie 750 frames.

Relative encoding time (to x265 1.9+217; less -- faster):
enc.time| description
100.0% | x265 1.9+217
107.8% | x265 1.9+223
108.4% | x265 2.1+21
106.3% | x265 2.1+21 --limit-tu 1
105.2% | x265 2.1+21 --limit-tu 2

--limit-tu 1 & --limit-tu 2 produce the same output in my test.

Raw data in attachment.

So, does this means we should stick to x265 1.9+217 for an everyday "mainstream" use?

[burfadel]

Don't forget quality improvements and preset changes will likely affect encode speed.

[Ma]

So, does this means we should stick to x265 1.9+217 for an everyday "mainstream" use?

New versions are slower but with better quality.

Example of 10-bit encoding with options "-p slower --crf 16":
original sample www.msystem.waw.pl/x265/uhd177.y4m
x265 1.9+217 www.msystem.waw.pl/x265/u217.mkv
x265 1.9+223 www.msystem.waw.pl/x265/u223.mkv
x265 2.1+21 --limit-tu 1 www.msystem.waw.pl/x265/u1.mkv

x265 2.1+21 produces the same output as 1.9+223.

In this sample there is no details, it is only for check of smooth move. The move in u217.mkv is simply wrong.

In movies at full resolution the effect is only on small objects -- big objects are moving smoothly but small objects not, it is unnatural. From version 1.9+223 is much better (with --limit-tu 1 or 2 is also better).

[pingfr]

New versions are slower but with better quality.

Example of 10-bit encoding with options "-p slower --crf 16":
original sample www.msystem.waw.pl/x265/uhd177.y4m
x265 1.9+217 www.msystem.waw.pl/x265/u217.mkv
x265 1.9+223 www.msystem.waw.pl/x265/u223.mkv
x265 2.1+21 --limit-tu 1 www.msystem.waw.pl/x265/u1.mkv

x265 2.1+21 produces the same output as 1.9+223.

In this sample there is no details, it is only for check of smooth move. The move in u217.mkv is simply wrong.

In movies at full resolution the effect is only on small objects -- big objects are moving smoothly but small objects not, it is unnatural. From version 1.9+223 is much better (with --limit-tu 1 or 2 is also better).

I have to agree the playback from 1.9+217 is twitchy, jerky, messy.

However the other samples are hard to make a difference given the source's resolution, I mean 340x160 feels like we're back at the stone age.

Could use a 720p source to begin with. :)

[benwaggoner]

So I made speed test with options "-p slower --crf 23" on Win7 64-bit, i5 3450S, test file 1920x800 BD movie 750 frames.

Relative encoding time (to x265 1.9+217; less -- faster):
enc.time| description
100.0% | x265 1.9+217
107.8% | x265 1.9+223
108.4% | x265 2.1+21
106.3% | x265 2.1+21 --limit-tu 1
105.2% | x265 2.1+21 --limit-tu 2

--limit-tu 1 & --limit-tu 2 produce the same output in my test.

Raw data in attachment.
You might want to try --tu-inter 4 --tu-intra 4 so that there are more tu depths to check. Preset slower defaults to only 2. I hope that faster tu checking can enable deeper tu size searches to improve detail retention with reasonable performance.

[benwaggoner]

However the other samples are hard to make a difference given the source's resolution, I mean 340x160 feels like we're back at the stone age.

Could use a 720p source to begin with. :)
Yeah, HEVC's low-bitrate performance is good enough that I can't imagine a scenario where I'd want to use 340x160, even at <<100 Kbps. Even moreso than H.264, HEVC tends to get soft rather than blocky/ringy when bits-per-pixel drops "too low" in the hardest bits of video, so it's safer to use higher resolutions. It's a long way from MPEG-2, where content could look fine 95% of the time and horrible 5% of the time, with such a sharp threshold where complexity @ bitrate made it unwatchable.

Also, we should be using at LEAST mod8 resolutions, right :)? and at that low resolution, the upscaling artifacts can be quite distracting, and a major source of visual defects that'll vary between players.

That said, there is tons of SD-only content in this world, and defects are easier to see in SD and encoding is certainly faster. I'd be happy to have test results at 640x360, certainly.

[Jawed]

The move in u217.mkv is simply wrong.

In movies at full resolution the effect is only on small objects -- big objects are moving smoothly but small objects not, it is unnatural.
Wow what an excellent test clip.

A while ago I talked about problems at crf 24 due to the number of b-frames with higher quality presets. This test clip reveals the same kind of problem I witnessed.

Encoding this clip at crf 24 preset slow with version 2.1+2-c0d91c2b4048 the judder on the lead vehicle is truly spectacular.

As I reduce b-frames count using 2, then 1 and 0, the results get better. 1 is far from perfect, but the reduction in judder with each reduction in b-frame count is pretty clear. 0 produces no judder on the vehicles, but there is some judder on the clouds of dust. I think that judder is actually just blocking artefacts as the problem extends into the ground.

I haven't played with --limit-tu yet.

[Barough]

x265 v2.1+22-c97805dad914 (http://www117.zippyshare.com/v/5kpmu8gP/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Winston_Smith_101]

Hi! I would like to (re-)encode my original very high bitrate 1080p h.264 movies to x265 to save space on my nas. My goal is to maintain the picture quality nearly as well as possible, but to save a good amount of space at the same time. At the moment i use the newest x265 version 2.1+21 and Staxrip.

I use a Windows 10 Machine with 2x 14 Core Intel Xeon E5 2683v3 CPUs.

So far I made good experiences with the following settings for the first CPU:
"--crf 18 --preset veryslow --output-depth 10 --pools "+,-" --pmode --pme --no-sao"

and: "--crf 18 --preset veryslow --output-depth 10 --pools "-,+" --pmode --pme --no-sao" for the 2nd CPU.

Would you suggest other settings or do you have tweaks to optimize my result? In the end, i would be happy with a picture quality of 80-90% compared to a optically lossles encoding. Encoding time is not a primary sector.

Thank you!

[HWK]

I would take out --pme option it offer little to no benefit
From docs

Parallel motion estimation. When enabled the encoder will distribute motion estimation across multiple worker threads when more than two references require motion searches for a given CU. Only recommended if x265 is not already saturating CPU cores. --pmode is much more effective than this option, since the amount of work it distributes is substantially higher. With –pme it is not unusual for the overhead of distributing the work to outweigh the parallelism benefits.–pme will increase utilization on many core systems with no effect on the output bitstream.

[brumsky]

I use a Windows 10 Machine with 2x 14 Core Intel Xeon E5 2683v3 CPUs.

So far I made good experiences with the following settings for the first CPU:
"--crf 18 --preset veryslow --output-depth 10 --pools "+,-" --pmode --pme --no-sao"

and: "--crf 18 --preset veryslow --output-depth 10 --pools "-,+" --pmode --pme --no-sao" for the 2nd CPU.

Would you suggest other settings or do you have tweaks to optimize my result? In the end, i would be happy with a picture quality of 80-90% compared to a optically lossles encoding. Encoding time is not a primary sector.

Thank you!


I agree with HWK drop --pme, it isn't worth it. Also, I'd drop --pmode as well. I have actually seen fps drop with it. I'm running dual e5-2683 v4 16 cores.

I also use --no-strong-intra-smoothing, helps to keep things a littler sharper.

If you are running x265 v2.1+20 or newer you can use --limit-tu 1 or 2. It'll speed up your encoding with virtually no quality loss. You could also try --limit-refs 3 since you are running very slow preset it sets that to 1.

Based on my testing the option that gives the best quality increase is --rd 5/6, they are the same right now. Which Very Slow defaults to rd 6, so you've already got it.

So you spend\waste a lot of time with limit-refs < 3 and limit-tu 0.

Edit:
Just noticed that --rskip is removed in veryslow as well. I'd suggest enabling that as well.

[LigH]

New CLI options:

--[no-]opt-qp-pps Discard optional HRD timing information from the bistream. Default enabled
--[no-]opt-ref-list-length-pps Discard optional HRD timing information from the bistream. Default enabled

GCC 6.2.0 only is sufficient from now on.

x265 2.1+25-0e9e52640546 (https://www.mediafire.com/file/4co4tji043zovjl/x265_2.1+25-0e9e52640546.7z)

[Boulder]

As it's been a while since I last tried x265 - are there any new recommended encoder settings to test to compare with x264 and --tune film? I've got three seasons of Star Trek TOS to encode and the HD transfers are quite far from perfect at least in the first season. It might be useful to see if x265 will produce better output around the same bitrate. I usually downsize (with some sharpening to compensate) and encode at 720p with CRF 18 using x264 and the preset veryslow.

[Selur]

Can anyone give some inside into the whole hdr processing?
I thought --master-display ... and --max-cll ... were used to add the timing informations that --opt-qp-pps and --opt-ref-list-length-pps remove,...

[nevcairiel]

Can anyone give some inside into the whole hdr processing?
I thought --master-display ... and --max-cll ... were used to add the timing informations that --opt-qp-pps and --opt-ref-list-length-pps remove,...

Those options add additional HDR SEI metadata into the stream, it has nothing to do with the HRD timings.

Don't mix up HRD with HDR - HRD stands for Hypthetical Reference Decoder, and its a different metadata block. Its generally related to various compliance checks, VBV etc. Not sure decoders typically even read this, which is why they may opt to remove it by default.

[Jawed]

As it's been a while since I last tried x265 - are there any new recommended encoder settings to test to compare with x264 and --tune film? I've got three seasons of Star Trek TOS to encode and the HD transfers are quite far from perfect at least in the first season. It might be useful to see if x265 will produce better output around the same bitrate. I usually downsize (with some sharpening to compensate) and encode at 720p with CRF 18 using x264 and the preset veryslow.

I suggest you avoid the spaghetti soup of options some people offer up and stick with:

--preset medium --output-depth 10 --merange 38 --rd 5

this will be about the same speed or a little bit faster than x264 very slow. It'll also be at least as good in picture quality. And it'll produce a file that's about 60% as large.

--merange 38 is for 720p encodes. If you encode 1080p material, then remove this option as the default motion search range is configured for 1080p.

--output-depth 10 will prevent the encoder from introducing banding. Don't use if you are trying to play back your encodes on something other than a PC.

The documentation here is useful:

http://x265.readthedocs.io/en/latest/cli.html

There is no tuning for film. In my opinion at crf 18 you're going to lose some noise and some acuity in your source material (just like with x264) but you'll find x265 is extremely consistent, much better than x264.

Finally, presets in x265 change over time. It's still effectively in alpha, since not all published options are actually implemented. e.g. --rd 6 is actually the same as --rd 5.

[sneaker_ger]

New CLI options:

--[no-]opt-qp-pps Discard optional HRD timing information from the bistream. Default enabled
--[no-]opt-ref-list-length-pps Discard optional HRD timing information from the bistream. Default enabled
Gotta love these totally not confusing documentations. Always gotta take a moment to wrap my head around them.

[Selur]

Don't mix up HRD with HDR
Ahhh, totally read HDR :)

Discard optional HRD timing information from the bistream. Default enabled
So by default the timing information is put in the bitstream,... right?

[sneaker_ger]

No. Only there with --opt-qp-pps + --hrd + --vbv-maxrate + --vbv-bufsize

(Not sure about implications of --uhd-bd)

[Selur]

okay, does --vui-hrd-info play into this somehow?

[Boulder]

I suggest you avoid the spaghetti soup of options some people offer up and stick with:

--preset medium --output-depth 10 --merange 38 --rd 5

this will be about the same speed or a little bit faster than x264 very slow. It'll also be at least as good in picture quality. And it'll produce a file that's about 60% as large.What I'm looking for is still the retention of details (or noise), but based on a very quick test with a frame by frame comparison, it seems to me that x265 still eats those for breakfast. I'll really have to do a proper viewing test too see if it's noticable in motion. I also noticed a shift in colors that some other people have mentioned. It doesn't occur in the x264 sample.

[Motenai Yoda]

Finally, presets in x265 change over time. It's still effectively in alpha, since not all published options are actually implemented. e.g. --rd 6 is actually the same as --rd 5.
this is bs, they explained many times those rd modes exists in previous versions and they mantain rd 4 and rd 6 to not broke existing users's scripts and code

@Boulder try with no-sao and rdoq 2 both will reduce detail/grain loss, but most of the x264 "details" come from its microblocking and aren't real ones

[Jamaika]

Ahhh, totally read HDR :)
So by default the timing information is put in the bitstream,... right?
HRD (Hypothetical Reference Decoder) is only an additional signal streaming in the header frames GOP. It doesn't change the recording HEX in file HEVC. It is the wrong description. HDR is off by default.
I wonder about changes in the function of high-tier.
No matter whether I enable or disable the vbv 160000kbps, tier is always high for crf. If the function is always automatic that is superfluous.

[WhatZit]

What I'm looking for is still the retention of details (or noise), but based on a very quick test with a frame by frame comparison, it seems to me that x265 still eats those for breakfast.

When they announced improvements to "--tune grain" in v2.0, they weren't kidding! Combine this with 10/12-bit encoding, and the results are, I think, magic.

Prior to this, I was also chasing all manner of CLI arguments to retain detail. Now, I use the same ludicrously simple command line for practically everything.

--preset (as slow as you can stand) --crf 21 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing

With the above, the slower the preset, the more detail retention you get. In fact, speed is the only change you need to make to improve (or reduce) quality, as it should be.

Tuning for grain greatly reduces psychovisual artifacts from moving picture elements, and cuts out almost all of the high-frequency "breathing" caused by wayward quant fluctuations.

Of course, encoding in 10 (or 12) bits obviates banding.

Deblock is at the weakest setting rather than turn it off completely (--no-deblock), and who wants strong smoothing when you want to retain detail?

Just for laughs, why don't you try a preset of "superfast"? I call that the "x264 emulator".

[Boulder]

When they announced improvements to "--tune grain" in v2.0, they weren't kidding! Combine this with 10/12-bit encoding, and the results are, I think, magic.After some testing, I have to admit that --tune grain is a helluva lot better than it used to be. Earlier the bitrate skyrocketed but now it's possible to use a lower bitrate than with x264 and detail is retained quite nicely, at least with the Star Trek samples I've encoded.

EDIT: What about --rd-refine, has anyone tested it? I've not seen any mentions about it.

[Barough]

x265 v2.1+25-0e9e52640546 (http://www50.zippyshare.com/v/crmBmKE7/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Dclose]

Can anyone explain the effects of --tu-inter-depth and --tu-intra-depth in layman terms for me please?

I'm currently encoding old ish TV series from DVD whilst experimenting with some settings in the process. It's been a while since I last tried x265 and I'm pleasantly surprised by what speeds I can get on my i7 3770k with a bit of settings juggling.

But I've just stumbled across that increasing both --tu-inter-depth and --tu-intra-depth from 1 to 2 causes a 15% reduction in bitrate with all other settings left the same. Is really that much of an efficiency gain or is it actually having a negative impact somewhere? The DVD's are PAL 720x576 so is resolution a factor? Perhaps 1 is best for SD, 2 for HD and 3 is for 4k? Going from 2 to 3 barely has any effect but the reduction in bitrate and file size when increasing from 1 to 2 is quite alarming!

Speed doesn't seem much different when set to 1, 2 or 3 but that might be because it's chugging along at a lower bitrate when set to 2 or 3.

Main settings I've settled on otherwise (for 576p resolution) are preset medium but with the following tweaks :-

--CRF 21 --ctu 16 --max-tu-size 8 --qg-size 16 --early-skip --b-intra --limitmodes --weightb --me star --merange 25 --max-merge 3 --subme 3 --ref 5 --bframes 5 --rc-lookahead 40

Thanks.
I haven't seen a layman's answer to what intra and inter tree unit depth do. It looks like it's just supposed to help make the file smaller, but...

While encoding a 1080 cartoon, Max Intra 2 looks to be more blurry than Max Intra 1. I don't think 1 is sharper than the source; just that 2 is blurrier. On my test sample, 1 has a smaller file size.

So, I'm not sure what Intra (or Inter) are supposed to be doing. Maybe they do something different on live action, which I haven't tested that specifically yet.

Btw, Coding Unit size of 64 is already said to be blurrier than 32, and on my current cartoon sample it's very noticeable. It's interesting in that 64 and Intra 2 do help add fluidity and a "3-D" quality to the 2-D cartoon, but they make me want to rub my eyes thinking my eyes can't quite focus. 64 is a bigger file than 32 too, on this particular sample.

[gamebox]

@Dclose

I've noticed the same issue with blurriness when increasing inter/intra depth. Basically, bigger value for tu-inter/intra-depth means encoder will try harder to find visual material that can be reused from previously encoded frames. That also means more parts of the image will stay on screen for longer, and be more "degraded" because of subtle transformations from motion compensation they are subjected to. This is especially true if encoder is allowed to use many consecutive B-frames. So, the bottom line is - if areas with lots of movement are important in video (anime, sport, porn), try decreasing these options to get better defined edges and less blur. For general purpose encoding, Hollywood motion pictures, documentaries, etc, where scenery is as important as the action itself, feel free to use larger values to get smaller files.

[Winston_Smith_101]

I am not a programmer and do not know methods of software optimization. My questions are, is it possible that x265 could become noticeable faster in the future, or are there any realistic possibilities for optimizing the program code? Do people optimize the speed of x265 in this phase of development? And is it thinkable that x265 in future can use the computational power of a modern graphics card as a teammate together with the cpu?