x265 HEVC Encoder

[pingfr]

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]

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]

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]

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

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 (https://forum.doom9.org/showthread.php?t=170236) 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" :o ... 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"? :o ... 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... :rolleyes:

[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.php?p=1762253#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]

Maybe less "opinion", rather "experience"? :o ... 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... :rolleyes:

Could you see SAO amplifying the blurring ?

[Zebulon84]

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.


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! :eek:

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]

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]

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]

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.

[Zebulon84]

x265 really needs to massively improve in details retention in that specific area if it wants to be "taken seriously" compared to other HEVC encoders.
The loss of details is so ugly, it makes XviD (aka a 15 years old obsolete codec) look better in those regards. :eek:

So which other HEVC encoders gives much better detail retention at 1100 kb/s for 1080p ?

[elahn]

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.

I would love that! I struggle to understand many of the parameters and I feel like it'll be a long time over many sources before I do, if ever.

[Majorlag]

elahn,
I would look over at http://x265.readthedocs.io/en/default/cli.html and read up on what each option does. This is where I went back to, through many iterations of encodes. I found that there is nothing like trial and error to see what options are worth enabling and others disabling.

The defaults are generally set for a reason, to give an all around acceptable quality for the time it takes to encode at the users desired bitrate. Use a short 24 minute episode to try different settings. Too short of a clip will not show some fine tuning. and long clips will be forever to decide if things like that --preset plecebo was worth it.

Don't get caught up in the chasing options forever and enabling or changing everything, presets are there for a reason, then apply small changes for your needs.

~Majorlag

[LigH]

So which other HEVC encoders gives much better detail retention at 1100 kb/s for 1080p ?

a) That would be off-topic here.

b) They all are HEVC encoders, so they all behave in a similar way, and none does miracles. Bitrate is usually spared by decisions which details can be reduced with little annoyance. Such decisions can be more or less appropriate, depending on both the video material and the person looking at it.

[benwaggoner]

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.
Also, --tune grain is very often suboptimal for quality @ bitrate. So if getting as good subjective quality as is possible at a low bitrate is the goal, --tune grain is only useful with really grainy content, mainly at higher resolutions where the actual spatial frequencies are mainly noise.

[pingfr]

Also, --tune grain is very often suboptimal for quality @ bitrate. So if getting as good subjective quality as is possible at a low bitrate is the goal, --tune grain is only useful with really grainy content, mainly at higher resolutions where the actual spatial frequencies are mainly noise.

Not to throw oil on the fire but... finally someone who has a clue and common sense!

--tune grain is for grainy content as the name implies... duh!

--tune grain is not, never was and never will be a "cookie cutter all-around" parameter to always consider when doing encodes. It is not the "always 100% right" solution as others have wrongly implied in the past 3 pages of this thread.

[Boulder]

For what it's worth, the encoder cannot tell grain from actual detail or noise. What we --tune grain users have been saying is that the tuning tends to bias towards keeping things as they are in the source; be it grain, detail or noise. It does this at a cost of a higher bitrate so you most likely will not see the advertised 50% bitrate savings compared to H.264.

As always, everything depends on what you personally seek - you must test things yourself and then use whatever looks best to your eyes. We are only spoon-feeding you options to test.

EDIT: Earlier I posted some sample screenshots here: https://forum.doom9.org/showthread.php?p=1734222#post1734222 when I compared x264 and "non-tune-grain" settings of x265 more. I have made short tests after that with more recent builds of x265 every now and then, but the problem of vanishing details is still there unless I use --tune grain.

[pingfr]

It does this at a cost of a higher bitrate so you most likely will not see the advertised 50% bitrate savings compared to H.264.

And therefore should be avoided at all costs as it nullifies the whole point of using x265 over x264 to begin with. /thread

[Boulder]

As I mentioned earlier, my encodes with x265 have generally been 10-30% smaller than the ones with x264 with at least similar visual (subjective) quality.

[WhatZit]

--tune grain is for grainy content as the name implies... duh!

Do I have a different interpretation of this section of the manual than everyone else?

"Tune grain also biases towards decisions that retain more high frequency components."

That's a quality algorithm, right there.

EDIT: Besides, there was NO GRAIN in that Yacht Ride comparison I posted, was there? The non-grain encode was 6.27mb, the grain encode was 10.7mb. Given the massive quality superiority of the grain encode, I consider the expanded bitrate to be well worth it.

[LoRd_MuldeR]

"Tune grain also biases towards decisions that retain more high frequency components."

That's a quality algorithm, right there.

You need to keep in mind that you have a limited bit budget. And, therefore, any bits you spent for one thing will be missing for something else.

Consequently, the more bits you spend on retaining "more high frequency components", the less bits will be available for the lower frequency components, of course. It's all a trade-off!

At high enough target bitrate that may be okay, but at medium to lower bitrates it can definitely cause problems.

Surely, you can just crank up the bitrate when using "tune grain" - which in CRF mode happens kind of "automatically" - but then again you end up with files of different size (i.e. different average bitrate).

If the file with "tune grain" is allowed to use more bits than the file with "default" settings (without "tune grain"), then any quality comparison of those files will inherently be biased/unfair.

[WhatZit]

It does this at a cost of a higher bitrate so you most likely will not see the advertised 50% bitrate savings compared to H.264.

And therefore should be avoided at all costs as it nullifies the whole point of using x265 over x264 to begin with. /thread

Wait a minute... wasn't it YOU who said THIS: (https://forum.doom9.org/showthread.php?p=1798758#post1798758)

I'm trying to optimize for top-notch quality at a 10%~15% size/compression efficiency over x264, bitrate isn't an issue and never will be.

Everything I've said so far will allow you to do exactly, precisely THAT!

By now, all I think you want to do is to troll x265, i.e.: complaining about quality while encoding in 8-bits, complaining about quality while encoding at low-bitrates, and/or complaining about size or speed when detail preservation techniques are used.

[aymanalz]

Wait a minute... wasn't it YOU who said THIS: (https://forum.doom9.org/showthread.php?p=1798758#post1798758)



Everything I've said so far will allow you to do exactly, precisely THAT!

By now, all I think you want to do is to troll x265, i.e.: complaining about quality while encoding in 8-bits, complaining about quality while encoding at low-bitrates, and/or complaining about size or speed when detail preservation techniques are used.

You don't want to be throwing accusations of trolling etc, when you are solely responsible for the confusion and misinformation over the last two pages. It was your suggestion that "tune grain" should be renamed to "tune quality", with the implication that it is a universal silver bullet for quality. I specifically had to ask everybody else's opinion becaue of your statement, and clearly, the consensus is that "tune grain" is best used for grainy or other noisy sources.

The point of the codec is to get maximum quality at lower bitrates than previous gen codecs. For maximum quality per bitrate, tune grain is suboptimal for non grainy or non noisy sources. As the name implies, it is meant to preserve detail (grain, noise) in grainy sources.

[aymanalz]

Do I have a different interpretation of this section of the manual than everyone else?


To begin with, you have a different interpretation of the name itself than everybody else. "Tune grain" means precisely that - a preset to retain grain in grainy sources. That is why the developers named it so, instead of as "tune quality", as you suggested.

Do I have a different interpretation of this section of the manual than everyone else?

"Tune grain also biases towards decisions that retain more high frequency components."

That's a quality algorithm, right there.


Nope. High frequency = grain. That's a grain algorithm. Or more generally, to spend more bits on high frequency components alone. Which works well to retain grain, but not other kinds of detail.


EDIT: Besides, there was NO GRAIN in that Yacht Ride comparison I posted, was there? The non-grain encode was 6.27mb, the grain encode was 10.7mb. Given the massive quality superiority of the grain encode, I consider the expanded bitrate to be well worth it.

A 10.7 mb file has higher quality than a 6.27 mb file. Surprised? You would see that same quality improvement by feeding more bits to the encode, whether by adjusting CRF or bitrate for a multi pass encode.

If you want to compare quality, do so at the same bitrate/filesize.

[LigH]

Nope. High frequency = grain.

Not exclusively. High frequencies are also useful for more or less regular patterns, as well as sharp edges.

That's the main problem of "noise filters": They can't "see" whether an area contains desired structure or undesired noise.

[pingfr]

They can't "see" whether an area contains desired structure or undesired noise.

Clearly not an expert on the subject but isn't what chroma and luma analysis per "area" of a given frame are for?

I mean they could be used to help the encoder "see" whether an area is a background with less details where less details/less bitrate can be spent over a foreground area where details/higher grain retention is more crucial because that's the area of the frame our eyes are focused on?

[WhatZit]

High frequency = grain.

You know what ELSE is high frequency?

Hair, textiles, vegetation, dirt, architecture, fur, water, eyelashes, fences, cobblestones, cliff-faces, bulletholes, control panels, spoked wheels, wood... basically, anything which needs to be represented by hard edges.

Now, what would you call those picture elements? I'd call them detail.

A 10.7 mb file has higher quality than a 6.27 mb file. Surprised? You would see that same quality improvement by feeding more bits to the encode, whether by adjusting CRF or bitrate for a multi pass encode.

In fact, you wouldn't see the same quality improvement with a simple application of more bits, because the default x265 removes detail even at low CRF's. You'd have to manipulate a dozen or more options to even come close to the single --tune grain option, or ABR it.

That was the purpose of the demonstration, in fact that's all I'm going on about: to show how one single option can produce output that is the same quality (subjectively) as 20 individually specified options. Yes, different sizes because different regimes. But I don't starve my encodes of bits, so I never run into any "suboptimal" situations.

I've used --tune grain ubiquitously for 100's of encodes in the last 9 months. It never leaves the command line. A year ago, my x265 options stretched for 3 lines! Some people think that makes themselves an elite special snowflake. To me, it was annoying to maintain.

Now, I only vary the preset & crf as required for light, dark, high-motion, high-detail, grainy, clean or any other type of content you care to name, because I have the experience to know what to use. For me, it DOES work as a quality silver bullet, probably because I never starve my encodes of bits. Quality is number one.

Naturally, if you simply don't like it, don't use it. If quality is also not number one for you, definitely don't use it.

[pingfr]

Some people think that makes themselves an elite special snowflake.

Uuuuhhhhh... okay? :mad:

[Romario]

Can someone, please, tell me how can I retain details in 720p and 1080p encodes, bitrate around 1000 for 720p and about 1650 for 1080p

Gesendet von meinem GT-I9295 mit Tapatalk

[LigH]

bitrate around 1000 for 720p and about 1650 for 1080p

Assuming 24 fps as low anchor:

1,000,000 bps : 1280 : 720 : 24 fps ~ 0.045 bppf (bits per pixel and frame)

1,650,000 bps : 1920 : 1080 : 24 fps ~ 0.033 bppf

I hope you encode only talk shows or landscape stills. Any more action, and the "pixel bitrate" may be too small to retain enough quality to be satisfied. It is not a reliable estimation, but you seem to expect miracles (thumb rule for DivX was 0.3 bppf, a decimal magnitude more than your target).

[Romario]

Assuming 24 fps as low anchor:

1,000,000 bps : 1280 : 720 : 24 fps ~ 0.045 bppf (bits per pixel and frame)

1,650,000 bps : 1920 : 1080 : 24 fps ~ 0.033 bppf

I hope you encode only talk shows or landscape stills. Any more action, and the "pixel bitrate" may be too small to retain enough quality to be satisfied. It is not a reliable estimation, but you seem to expect miracles (thumb rule for DivX was 0.3 bppf, a decimal magnitude more than your target).
No, you don't understand me good. I meant which encoding settings are best, slowest preset or custom insane settings?

I want as much detail as possible at these bitrate.

Yes, it's landscape. And one or two talk shows.

Gesendet von meinem GT-I9295 mit Tapatalk

[pingfr]

Assuming 24 fps as low anchor:

1,000,000 bps : 1280 : 720 : 24 fps ~ 0.045 bppf (bits per pixel and frame)

1,650,000 bps : 1920 : 1080 : 24 fps ~ 0.033 bppf

I hope you encode only talk shows or landscape stills. Any more action, and the "pixel bitrate" may be too small to retain enough quality to be satisfied. It is not a reliable estimation, but you seem to expect miracles (thumb rule for DivX was 0.3 bppf, a decimal magnitude more than your target).

720p should be around 2800kbits whereas 1080p should be around 6500kbits if you want "acceptable" quality, depends on the fps and the crop.

[LigH]

I can only agree: For optimal detail retention, enough bitrate is the most important detail. You seem to have missed the last 2 pages of this thread, it just mentioned "--tune grain" shifting the weight towards higher frequencies, but away from the lower frequencies which are more important for the overall image.

"Insane" is never good. And "placebo" requires you to believe in its advantage. "Enough bitrate" is the only universal active ingredient. You will know the analogy to cars: No spoiler will substitute more cylinder capacity.

[Romario]

Ok I understand that, but I don't want too big files for my encodes. That's unacceptable for me.

I don't know how is fine tune working. I have bought x265 encoder and decoder directly from x265 site, with gui.

Can you please explain me better what I need to know?

I make always two pass encodes, of course.

I also plan, on sumer, to buy Ryzen 1800x and to overclock him on 4.2 Ghz.

Gesendet von meinem GT-I9295 mit Tapatalk

[WhatZit]

I want as much detail as possible at these bitrate.

As has been pointed out, your target bitrates are extremely limited.

BUT... just to prove a point, I have exactly the solution you want.

Copy the batch file from this post: https://forum.doom9.org/showthread.php?p=1799950#post1799950

Replace all instances of "--bitrate 6500" with "--bitrate 1650", and all instances of "--preset medium" to "--preset slow".

Run your files through it (this will take quite a while), and mux the audio with MKVMerge.

I was able to turn a 23500kbps source into a 1694kbps quite watchable encode. I wouldn't say its good, but here's a juicy screenshot comparison for you to decide for yourself:

http://screenshotcomparison.com/comparison/202908

[Romario]

As has been pointed out, your target bitrates are extremely limited.

BUT... just to prove a point, I have exactly the solution you want.

Copy the batch file from this post: https://forum.doom9.org/showthread.php?p=1799950#post1799950

Replace all instances of "--bitrate 6500" with "--bitrate 1650", and all instances of "--preset medium" to "--preset slow".

Run your files through it (this will take quite a while), and mux the audio with MKVMerge.

I was able to turn a 23500kbps source into a 1694kbps quite watchable encode. I wouldn't say its good, but here's a juicy screenshot comparison for you to decide for yourself:

http://screenshotcomparison.com/comparison/202908
Wow, thanks. That's very nice from you.

Unfortunately I also have compressed sources, so it's not always so easy... I have couple of old MPEG2 sources in HD and Full HD.

What is here recommended?

Gesendet von meinem GT-I9295 mit Tapatalk

[benwaggoner]

720p should be around 2800kbits whereas 1080p should be around 6500kbits if you want "acceptable" quality, depends on the fps and the crop.
Bits per pixel requirements go down as resolution goes up. The classical rule of thumb was "to the power of 3/4ths", so going from 720 to 1080 would increase total pixels by 2.25x, bitrate would need to increase by around 1.8x (2.25^0.75) to yield similar quality.

The actual value is probably somewhat less than 0.75 for HEVC due to its greater relative efficiency at encoding higher resolutions. But still, it is just a rule of thumb, and will vary widely with content.

But, assuming full screen playback, more pixels means any given error is spatially smaller and thus less objectionable. Also, visually relevant frequencies are generally lower, so with more pixels, content can be quantized more aggressively and still retain the same amount of visually relevant information.

tl;dr - bbp requirements go down as frame size goes up. The degree varies with content, but a constant bbp across frame sizes isn't appropriate for real-world content.

[microchip8]

@pingfr

at this point in time, x265 is not on-par with x264's detail retention, and no amount of knobs tweaking will change that. Sorry to say it, but you'll have to accept this for the moment. Also, it's not very clear to me what you exactly want. First you say you want very good (equal?) quality compared to x264, then you complain about file sizes

[x265_Project]

Video professionals - MulticoreWare's x265 development team will be attending and exhibiting at the National Association of Broadcasters convention in Las Vegas, April 24-27. We'll have lots of interesting and exciting things to announce and demonstrate. Message us if you need a registration code, or to schedule a meeting. Or just come visit us in the South Hall, Upper, booth SU14604.

[WhatZit]

Unfortunately I also have compressed sources, so it's not always so easy... I have couple of old MPEG2 sources in HD and Full HD.

I don't usually deal with such low bitrates, so I'm having to make educated guesses here.

One thing I will tell you is that, under --tune grain, the slower the preset, the more detail x265 will try to retain. This means that ABR will become more and more bit-starved the more detail you preserve, producing artifacts like the "blotchy" sunrays.

In these cases, you can dial back the speed preset to tune the amount of detail preservation, which will allow ABR to more evenly distribute the bitrate among all picture elements.

To demonstrate clearly what I mean, here's another screenshot comparison (I wish there was a non-WaReZ version of this site):

http://screenshotcomparison.com/comparison/202948

This compares the --preset slow setting I told you about above to a --preset fast setting (no other changes). You can see that there is less detail retained (look at the sunbeams), but overall a "cleaner"/smoother image.

Which you prefer is a matter of taste. The key is to find what works for you.

With your other Full HD sources, you may have to drop the preset speed back to get an "acceptable" picture due to the presence of noise or grain, or the simple light properties of the film.

ffmpeg, which is used to pipe to x265 in the batch file, should be able to read most of the compressed filetypes you have.

EDIT: For such low bitrates, you should also change the deblock from -6:-6 to something like 2:-5. Deblock is, in practice, a strange beast, but it works as a pair, which I've interpreted as in the form of (how_much) : (how_often). In other words, the first offset is what type of deblocking to apply, and the second is when to use it.

The x265 manual itself is not very clear on how this loop filter operates, but you can read about HEVC Deblock theory here: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6324414

Ripped off from that submission:

"The first number (tC) controls the selection between the normal and strong filter and determines the maximum absolute value of modifications that are allowed for the pixel values for a certain QP for both normal and strong filtering operations. This helps adaptively limit the amount of blurriness introduced by the deblocking filtering."

"The second number (β) controls what edges are filtered, controls the selection between the normal and strong filter, and controls how many pixels from the block boundary are modified in the normal filtering operation. One can observe that the value of β increases with QP. Therefore, deblocking is enabled more frequently at high QP values compared to low QP values, high QP values correspond to coarse, and low QP values correspond to fine quantization."

At 1080P 1650kbps, you will get significant blocking in high-motion elements, so raising the (how_much) higher than the default strength of 0 will help blend those out. However, since you don't want any of your detail smoothed out in static elements, you have to tell (how_often) to restrict when it chooses to blend. I think -5 will limit the decisions to only high-motion scenes.

Regardless, this is DEFINITELY something that you'll need to experiment with yourself if you want to employ those extremely low bitrates for general use.