x265 HEVC Encoder

[Ma]

Originally Posted by stevendj

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]

Originally Posted by Ma

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]

Originally Posted by pingfr

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]

Originally Posted by Ma

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]

Originally Posted by Ma

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]

Originally Posted by pingfr

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]

Originally Posted by Ma

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 (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]

Originally Posted by Winston_Smith_101

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

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

Originally Posted by 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,...

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]

Originally Posted by 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.

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]

Originally Posted by 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

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)