x265 HEVC Encoder

[pingfr]

Originally Posted by WhatZit

So, it's SIZE you care about, not quality.

Not exactly, I am archiving commercial Blu-Ray discs. So quality matters, has to be "on par" with what an encode would be in x264.

I usually go by the rule of:

720p = min bitrate 4000kbits.
1080p = min bitrate 8000kbits.

And it has to be visually "identical" to the source.

While I'm trying not to derail the thread or turn this into a "x264 vs x265" debate, here are the settings of my last x264 1080p encode:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 38mn
Bit rate : 8 072 Kbps
Width : 1 920 pixels
Height : 808 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.217
Stream size : 5.39 GiB (82%)
Writing library : x264 core 148 r2744 b97ae06
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / bitrate=8072 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No

As you can see, the bitrate is about 8072 kbits, typical for a 1080p encode.

[LigH]

You cannot judge quality by reading numbers. Only by looking at the video. Just look at it and decide: Is the quality loss negligible? Don't care about bitrates other encoders used with other encoding options. And don't try to find average values; there are too different movies out there. You can probably find one that needs only a tenth of the bitrate of another, and still "looks better".

[WhatZit]

Originally Posted by pingfr

I usually go by the rule of:

720p = min bitrate 4000kbits.
1080p = min bitrate 8000kbits.

And it has to be visually "identical" to the source.

If you have to hit bitrate targets AND maintain quality, then that sounds like a perfect job for ABR!

Here's my old 1080p x265 2-pass batch file, that I used to use for grainy sources:

@Echo Off

If [%1]==[] Goto Usage

REM stats file = .\x265_2pass.log

:Pass_1
Echo =========== PASS 1
Echo.
ffmpeg -i %1 -f yuv4mpegpipe -  |  x265 --preset medium --bitrate 6500 --pass 1 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing --y4m %2 %3 %4 %5 %6 %7 %8 %9 - -o %1_ABR6500.hevc
Echo.
Echo.

:Pass_n
Goto Pass_2
REM Don't do this!
Echo =========== PASS n
Echo.
ffmpeg -i %1 -f yuv4mpegpipe -  |  x265 --preset medium --bitrate 6500 --pass 3 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing --y4m %2 %3 %4 %5 %6 %7 %8 %9 - -o %1_ABR6500.hevc
Echo.
Echo.

:Pass_2
Echo =========== PASS 2
Echo.
ffmpeg -i %1 -f yuv4mpegpipe -  |  x265 --preset medium --bitrate 6500 --pass 2 --profile main10 --tune grain --deblock=-6:-6 --no-strong-intra-smoothing --y4m %2 %3 %4 %5 %6 %7 %8 %9 - -o %1_ABR6500.hevc
Echo.


Goto END

:Usage
Echo USAGE: %0  SOURCE_VIDEO  [extra params]
Echo.
Echo Converts the SOURCE_VIDEO file into an x265 2-Pass ABR6500 .hevc stream (for later MKVMerging with original audio)
Echo.

:END

With that, I was able to turn this high-complexity IMAX demo:

General
Unique ID		: 185273360177734801790310909616562081404 (0x8B6259E9F86865D08A2BEE3E4BA78E7C)
Format		: Matroska
Format version	: Version 4 / Version 2
File size		: 84.1 MiB
Duration		: 30 s 37 ms
Overall bit rate	: 23.5 Mb/s
Encoded date	: UTC 2016-02-06 15:48:41
Writing application	: mkvmerge v8.8.0 ('Wind at my back') 64bit
Writing library	: libebml v1.3.3 + libmatroska v1.4.4

Video
ID			        : 1
Format			: AVC
Format/Info		: Advanced Video Codec
Format profile		: High@L4.1
Format settings, CABAC	: Yes
Format settings, ReFrames	: 4 frames
Codec ID			: V_MPEG4/ISO/AVC
Duration			: 30 s 42 ms
Width			: 1 920 pixels
Height			: 1 038 pixels
Display aspect ratio		: 1.85:1
Frame rate mode		: Constant
Frame rate		: 24.000 FPS
Color space		: YUV
Chroma subsampling	: 4:2:0
Bit depth			: 8 bits
Scan type			: Progressive
Writing library		: x264 core 142 r2431+42 c69a006 tMod [8-bit@all X86_64]
Encoding settings		: cabac=1 / ref=4 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=0.85:0.10 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=12 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=72 / rc=crf / mbtree=1 / crf=14.0000 / qcomp=0.70 / qpmin=0:0:0 / qpmax=69:69:69 / qpstep=4 / vbv_maxrate=24000 / vbv_bufsize=33000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00 / aq-sensitivity=10.00 / aq-factor=1.00:1.00:1.00 / aq2=0 / aq3=0
Language		: English
Default			: Yes
Forced			: No

into this:

General
Unique ID		: 235329403967803183918623951386027792481 (0xB10ACB6A3A0256CD96DFD7E451449861)
Format		: Matroska
Format version	: Version 4 / Version 2
File size		: 23.6 MiB
Duration		: 30 s 0 ms
Overall bit rate	: 6 607 kb/s
Encoded date	: UTC 2017-03-07 08:14:21
Writing application	: mkvmerge v9.8.0 ('Kuglblids') 64bit
Writing library	: libebml v1.3.4 + libmatroska v1.4.5

Video
ID			        : 1
Format			: HEVC
Format/Info		: High Efficiency Video Coding
Format profile		: Main 10@L4@Main
Codec ID			: V_MPEGH/ISO/HEVC
Duration			: 30 s 0 ms
Bit rate			: 6 603 kb/s
Width			: 1 920 pixels
Height			: 1 038 pixels
Display aspect ratio		: 1.85:1
Frame rate mode		: Constant
Frame rate		: 24.000 FPS
Color space		: YUV
Chroma subsampling	: 4:2:0
Bit depth			: 10 bits
Bits/(Pixel*Frame)		: 0.138
Stream size		: 23.6 MiB (100%)
Writing library		: x265 2.3+17-6e348252e902:[Windows][GCC 6.3.0][64 bit] 10bit
Encoding settings		: cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1038 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=-6:-6 / no-sao / no-sao-non-deblock / rd=3 / no-early-skip / no-rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=4.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=6500 / qcomp=0.60 / qpstep=1 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.10 / pbratio=1.00 / aq-mode=0 / aq-strength=0.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=64 / rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-optrefine-level=5
Language		: English
Default			: Yes
Forced			: No

with the x265 damn-well looking "identical" to the x264, according to me and my eyes. Once again, --tune grain is integral to maintaining quality.

I'll bet you could probably go well below 6000kbps and maintain "transparent" quality quite easily with --preset slow.

Speaking of which, I stopped using ABR because it was too slow, and it used the average bitrate even when it didn't need to. This might change if I ever get myself a Kaby Lake or, dare I say it, Ry--- no, I dare not say it.

NOTE: there are additional --multi-pass* options which improve speed/quality, but I've never investigated them.

[pingfr]

Originally Posted by WhatZit

If you have to hit bitrate targets AND maintain quality, then that sounds like a perfect job for ABR!

I'll bet you could probably go well below 6000kbps and maintain "transparent" quality quite easily with --preset slow.

One of the few gripes I always have had with x265 over x264 is that there is no way to really calculate or estimate the following values:

1) What does "equal" 4000kbits for a 720p and 8000kbits for a 1080p in the x264 in the x265 world?

It seems to me that 4000kbits x264 =! 4000kbits x265, likewise for the 8000kits x264 =! 8000kbits x265.

2) The CRF values are "off" as well, in the x264 world whenever I've had to use CRF; a sane value was 17 or 18, but there again a CRF 18 in the x264 world does not equal a CRF value of 18 in the x265 world.

It is clear that CRF 18 x264 =! CRF 18 x265.

If only there was a calculator, a .pdf or .xls or online doc of roughly translations back and forth between both encoders...

[LigH]

AVC and HEVC are different algorithms. There is no "equal quality", as long as quality is subjective, and even any kind of measurable difference depends a lot on the video content (because both standards use partially different techniques to spare bitrate). It's like expecting two master painters to paint "the same painting": They will always differ in style, no matter how realistic and exact their results will be.

You will not be able to create a reliable relation without efforts that would rival corporational MMO gold farmers: Hundreds of different movies encoded with dozens of different parameter combinations, and eventually, hundreds of people judging each of these results in ABX tests.

[Boulder]

Some observations from me since I was mentioned

Don't set any specific bitrate limits in your mind. The average bitrate is entirely dependent on the source. For example, I just processed the first season of Mr. Robot, and the episodes required very, very few bits at 720p. I'm talking about less than 1 Mbps! Then I processed the first season of The X-Files, and the bitrate almost shot through the roof using almost the same VapourSynth script.

As I've mentioned, I basically use --tune grain --preset slower --no-strong-intra-smoothing --deblock -3:-1 --crf 21 with some added things from slower presets, such as --bframes 10 --ref 5 --tu-inter-depth 4 --tu-intra-depth 4 --max-merge 4 and some speedups like --limit-refs 3 --limit-modes --limit-tu 3 --rskip --merange xx (xx = 38 for 720p, 25 for 480/576p). I have compared --tune grain against my default x264 settings which were based on Level 4.1 @ CRF 18 and found out that x265 will perform better and end up with a lower bitrate. I came up with CRF 21 for x265 after making a series of encodes with varying CRF and comparing still frames to the original one. I found out that CRF 21 is enough to my eyes, CRF 22 was causing things I didn't like in the image.

The difference in bitrate has generally been 10-30%. You should also note that the 10-bit encode with x264 will require less bits than the 8-bit one but with x265 it's the other way around. So the difference in performance is even more substantial. For quality reasons, you should encode at 10 bits unless the devices you use require otherwise. As far as I know, 10-bit HEVC should be HW decoded in many cases already. For what it's worth, my Celeron-based Chromebox has been able to decode 720p HEVC stuff in software as well.

I've criticized x265 heavily in the past for destroying the details, and it is true if you don't use --tune grain. It is a unique setting which is a must for me, otherwise I would still be using x264 for my encodes.

[WhatZit]

Originally Posted by pingfr

If only there was a calculator, a .pdf or .xls or online doc of roughly translations back and forth between both encoders...

Originally Posted by LigH

You will not be able to create a reliable relation without efforts that would rival corporational MMO gold farmers: Hundreds of different movies encoded with dozens of different parameter combinations, and eventually, hundreds of people judging each of these results in ABX tests.

Which is exactly why this thread from 3 years ago fizzled out.

Plus, everyone simply got used to the idea of x265 being a totally different kettle of fish than x264.

[LigH]

OK, not "totally" ... but already different enough in different resolutions due to different Coding Unit sizes and partitions, etc. Hard to simplify without a lot of constraints.

[aymanalz]

Is this a universal opinion here, that for quality, you need "tune grain"? For all sources, including non-grainy ones?

[Boulder]

Quality is in the eye of the beholder --tune grain is the only one biased toward keeping detail - and detail in this context is "real" detail, grain, noise etc. Some people prefer a clean image for which --tune grain is probably not a perfect choice.

[LigH]

Maybe less "opinion", rather "experience"? ... HEVC usually has a habit of rather blurring the material than revealing artifacts, which is often more appreciated by the people when the bitrate supply is not that generous, and has a different impact in UHD resolutions. I could imagine that you may enjoy the default behaviour as well for cartoons or computer generated movies which are very clean per se, or get an advantage from cleaning out low-detail areas. After all, there is also a matter of taste involved...

[sneaker_ger]

I have seen --tune grain produce bad effects in the past. It can hurt quality. It's not something I would blindly use for all sources.

https://forum.doom9.org/showthread.p...53#post1762253 ff

[Boulder]

That's almost a year-old thing. Has anyone made a new test since x265 has developed quite a bit since then?

[pingfr]

This is an endless charade in my opinion.

No disrespect but... one of the main developers (and I said a dev, not a PR person or a salesman) from MulticoreWave needs to step up for once and all and thoroughly explain us the full logic/philosophy along with the benefits and drawbacks of using specific --presets linked with specific --tuning parameters and how they all interact with each other.

It is no genius the average x265 user wants one thing: retain maximum subjective quality at the smallest achievable resulting file-size (at the cost of encoding time and CPU cycles), according to wikipedia, the initial x265 release was 4 years ago and despite the fact it is undeniable we've come a long way and made a lot of progress and improvements since commit 09fe406 on the 2013/03/07 there is IMHO (and with a grain of salt) still progress to do in that field.

[CruNcher]

Originally Posted by LigH

Maybe less "opinion", rather "experience"? ... HEVC usually has a habit of rather blurring the material than revealing artifacts, which is often more appreciated by the people when the bitrate supply is not that generous, and has a different impact in UHD resolutions. I could imagine that you may enjoy the default behaviour as well for cartoons or computer generated movies which are very clean per se, or get an advantage from cleaning out low-detail areas. After all, there is also a matter of taste involved...

Could you see SAO amplifying the blurring ?

[Zebulon84]

Originally Posted by pingfr

Not exactly, I am archiving commercial Blu-Ray discs. So quality matters, has to be "on par" with what an encode would be in x264.

I usually go by the rule of:

720p = min bitrate 4000kbits.
1080p = min bitrate 8000kbits.

And it has to be visually "identical" to the source.

Originally Posted by pingfr

x265 --preset superfast --crf 21 --tune grain --deblock=-1:-1 --no-strong-intra-smoothing Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o grainsuperfast.hevc
[...]

encoded 600 frames in 26.86s (22.33 fps), 5632.71 kb/s, Avg QP:23.04
[...]
Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Width : 1 920 pixels
Height : 1 080 pixels
[...]

13.4MB... no thanks!

If x265 --crf 21 --tune grain gives you 30% smaller file than your usual x264 encodes, why do you reject it without any comment on the quality, just the file size ?

[pingfr]

Originally Posted by Zebulon84

If x265 --crf 21 --tune grain gives you 30% smaller file than your usual x264 encodes, why do you reject it without any comment on the quality, just the file size ?

Because I don't have a technical way to judge/assess/comment the quality with any other tools than my "bare eyes"?

And because my complicated encode string without --tune grain yields an encode that is 5 times smaller as a comparison point?

2MB file vs. 13MB file.

[Rinzler0x7BB]

Originally Posted by aymanalz

Is this a universal opinion here, that for quality, you need "tune grain"? For all sources, including non-grainy ones?

No, I made a different experience. I encoded a low noise source one time with "tune grain" and one time with "--pbratio 1.2 --psy-rd 2.4 --psy-rdoq 5.0 --rdoq-level 2".
The "tune grain"-version had less details and was also a little bigger.

Tune grain does disable aq and cu-tree. This is one reason the resulting file is typically significantly bigger.

Parameters I used with tune grain:

--crf 20 --profile main10 --output-depth 10 --ctu 32 --tune grain --qcomp 0.65  --rc-lookahead 30 --no-sao --level-idc 4.1 --high-tier --rd 4 --bframes 8 
--no-strong-intra-smoothing --weightb --b-intra --rect --limit-modes

Parameters I used without tune grain:

--crf 20 --profile main10 --output-depth 10 --ctu 32 --pbratio 1.21 --aq-mode 3  --aq-strength 0.8 --qcomp 0.65 --psy-rd 2.4 --psy-rdoq 5.0 --rdoq-level 2 
--rc-lookahead 30 --no-sao --level-idc 4.1 --high-tier --rd 4  --bframes 8 --no-strong-intra-smoothing --weightb --b-intra --rect --limit-modes

It is always a tradeoff in quality, speed and encoding efficiency. For me all three are important. And everyone needs to find his suitable settings. I like tune grain as it produces are more constant quality also in high motion. But as the size is important for me too I needed to find settings with a better encoding efficiency. So I ended up in the settings above without tune grain.

[LoRd_MuldeR]

If you compare quality of files with different size (i.e. different average bitrate), you are comparing apples and oranges. Such comparison would inherently be biased.

Also, the same CRF value gives the same quality, roughly, for different sources, provided that no other options are changed. Changing other options, such as the "tuning" option, changes the meaning of CRF values!

There is no reason to assume that a specific CRF value still produces the same quality with "tune grain" that it did with "default" settings, or any other particular settings. And, therefore, comparing file sizes this way is not meaningful.

Conclusion:
- If you want to compare quality in a "fair" meaningful way, you have to compare files of identical size, i.e. identical average bitrate. This is most easily achieved by using 2-Pass mode.
- If you want to compare file size (i.e. average bitrate) in a "fair" meaningful way, you have to compare files of identical quality. This can be achieved by adjusting CRF value of each file until the "perceived" quality matches.

The latter clearly is much more difficult to achieved, which is why you probably want to do the former.

Also be sure that the average bitrate chosen for a quality comparison isn't too high. If the bitrate is chosen too high, then both files will look flawless and thus the (not very helpful) conclusion will be that there is no difference...

(And, of course, choosing the average bitrate too low is deceptive too. If both files look like a mess you don't learn much either)

[nevcairiel]

Originally Posted by pingfr

retain maximum subjective quality at the smallest achievable resulting file-size (at the cost of encoding time and CPU cycles)

Clearly that is every video codecs target. Best quality at smallest file size. The question is what do you favor, size? quality? And to what degree? Only one answer to those questions can be the "default" behavior, which apparently for x265 seems to favor size more then absolute quality.

The presets mostly influence the speed/quality trade-off, so that leaves the size/quality ratio up to the remaining settings. Primarly thats of course the bitrate/crf, but a lot of other options on top, which many people coming from x264 are likely not used to, since it had different defaults that favored keeping more quality by default.

Looking at what options tune grain modifies can be a good starting point, and some additional tune's or better documentation could definitely help - but its certainly something we as the community could easily create, a set of settings that generally keep more quality, but not focused on grain directly.
The presets and tune parameters are not "magic", they just modify a fixed set of the options you could also manually modify, and you can just look those up in the sources if the documentation doesn't list them.

I'm not sure anyone here on doom9 can really speak for an "average" x265 user without knowing anything about the userbase of x265 outside of this forum, however.