x265 HEVC Encoder

[pingfr]

@sneaker_ger: Are you sure --psy-rd 2.0 is the expected default behaviour now?

avs4x265 [info]: "x265.exe" - --frames 6497 --fps 30/1 --input-res 1280x720 --input-csp i420 --crf 18 --preset placebo --tune grain --aq-mode 3 --output source.hevc
yuv [info]: 1280x720 fps 30/1 i420p8 unknown frame count
raw [info]: output file: source.hevc
x265 [info]: HEVC encoder version 1.9+73-6d06de58c316
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: frame threads / pool features : 5 / wpp(12 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 60 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.3 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.80
x265 [info]: tools: rect amp rd=6 psy-rd=0.50 rdoq=2 psy-rdoq=10.00 tskip
x265 [info]: tools: signhide tmvp strong-intra-smoothing deblock(tC=-2:B=-2)
x265 [info]: tools: sao

I can see psyrd=0.50 default value, right there?

[sneaker_ger]

--tune grain overrides it.

[pingfr]

So are they mutually exclusive parameters? or should I bother enforcing both?

[sneaker_ger]

You can in turn override it by manually specifying --psy-rd 2. (Whether that makes sense is a different question. --tune grain will likely be overhauled soon, they have a patch waiting to be committed. But detail is not the same as grain anyways.)

[pingfr]

You can in turn override it by manually specifying --psy-rd 2.

Which is what I was doing until now and will continue to do so.

(Whether that makes sense is a different question.

Would you care to elaborate a bit more?

--tune grain will likely be overhauled soon, they have a patch waiting to be committed.

May I ask, is the patch publicly available and what does it changes/enhances?

But detail is not the same as grain anyways.)

I always was under the assumption that it was the case; grain = details?

[sneaker_ger]

Would you care to elaborate a bit more?
It's not far-stretched to assume the x265 devs chose that value for --tune grain for a reason. So I do not know whether it makes sense to combine --psy-rd 2 and --tune grain now or with the upcoming patch. And I mean "don't know" when I say "don't know", I'm not implying it's a bad idea. Maybe someone else can give you more insight.

May I ask, is the patch publicly available and what does it changes/enhances?
You can see it on the x265 devel mailing list. I suggest you wait until it has been committed.

I always was under the assumption that it was the case; grain = details?
Grain may be similar to detail but not all detail is grain. They are not equal.

[pingfr]

@sneaker_ger: Thank you for your answers. I'll be waiting until said patch has been committed to the stable tree and to see if they can shed some light on this whole grain =! details =! whatever sha-bang. :)

[pingfr]

Anyone would know what kind of decimal values can be passed to the --aq-strength parameter?

The reason why I'm asking this is, I've encoded a clip with --aq-strength 1.90 it looked flawless (placebo effect?), then re-encoded the same clip with --aq-strength 1.85 it started to show ugly blocks in the sky (placebo effect?)... then I am attempting with --aq-strength 1.88 but I see in the console it is reported as 1.9 value.

So what kind of decimal values can be passed to that parameter? 1.87 1.88? 1.899? 1.9000009009090? :)

[pingfr]

Also, an additional question here, I have all reasons to believe there is some sort of "bug" with the placebo preset.

Here are my findings:

x265-1.9+73-6d06de58c316 (8bit)
Used source sample: lighthouse_lossless.mp4 2.05GB
Sample grabbed from: https://mega.nz/#!osdxQbCR!vim8f5gAD5nf0w0jf-vEAA3mGySmEOoZQOH_GE3Z2uw
Encoded: The first 520 frames only out of the 2852 frames, enough to do a reliable test.

First doing an encode with the preset veryslow:

avs [info]: AviSynth 2.60 (ICL10)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x1080
avs [info]: Video framerate: 24/1
avs [info]: Video framecount: 2852
avs4x265 [info]: "x265.exe" - --frames 520 --fps 24/1 --input-res 1920x1080 --input-csp i420 --crf 18 --preset veryslow --psy-rd 2 --aq-mode 3 --aq-strength 1.75 --qcomp 0.68 --output source.hevc
yuv [info]: 1920x1080 fps 24/1 i420p8 unknown frame count
raw [info]: output file: source.hevc
x265 [info]: HEVC encoder version 1.9+73-6d06de58c316
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 24 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / 0 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.8 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.68
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing deblock sao

x265 [info]: frame I: 4, Avg QP:10.15 kb/s: 28106.88
x265 [info]: frame P: 85, Avg QP:11.75 kb/s: 30704.38
x265 [info]: frame B: 431, Avg QP:17.04 kb/s: 7381.13
x265 [info]: Weighted P-Frames: Y:44.7% UV:43.5%
x265 [info]: Weighted B-Frames: Y:28.1% UV:24.8%
x265 [info]: consecutive B-frames: 4.5% 1.1% 2.2% 31.5% 7.9% 15.7% 5.6% 11.2% 20.2%

encoded 520 frames in 264.99s (1.96 fps), 11353.01 kb/s, Avg QP:16.12

Outcome: The resulted file is looking loss-less or so to speak to the human eye compared to the original uncompressed source, the 5960X crunched it pretty quickly at 1.96 fps under 265 seconds and the resulted file weights 29.3MB (30 750 859 bytes) and x265 reports an Avg QP of 16.12.

Now let's do it again with the placebo preset, shall we?

avs [info]: AviSynth 2.60 (ICL10)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x1080
avs [info]: Video framerate: 24/1
avs [info]: Video framecount: 2852
avs4x265 [info]: "x265.exe" - --frames 520 --fps 24/1 --input-res 1920x1080 --input-csp i420 --crf 18 --preset placebo --psy-rd 2 --aq-mode 3 --aq-strength 1.75 --qcomp 0.68 --output source.hevc
yuv [info]: 1920x1080 fps 24/1 i420p8 unknown frame count
raw [info]: output file: source.hevc
x265 [info]: HEVC encoder version 1.9+73-6d06de58c316
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut : 24 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 60 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / 0 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.8 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.68
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 tskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing deblock sao

x265 [info]: frame I: 4, Avg QP:10.14 kb/s: 28074.24
x265 [info]: frame P: 86, Avg QP:13.58 kb/s: 24380.51
x265 [info]: frame B: 430, Avg QP:21.51 kb/s: 6460.87
x265 [info]: Weighted P-Frames: Y:45.3% UV:43.0%
x265 [info]: Weighted B-Frames: Y:27.9% UV:24.4%
x265 [info]: consecutive B-frames: 4.4% 1.1% 2.2% 33.3% 5.6% 17.8% 4.4% 14.4% 16.7%

encoded 520 frames in 485.48s (1.07 fps), 9590.76 kb/s, Avg QP:20.11

Okay this is where things get weird and don't make sense: Sure it encoded much slower than the veryslow preset at the average rate of 1.07 fps for a grand total of 485s but this is where things get ugly; instead of yelding an encoded result that is supposedly better quality than a veryslow encode since we spent twice the amount of time to encode it, the quality is far far worse, there are lots of artefacts all over the frame, the Avg QP increased from 16.12 all the way up to 20.11 (from what I understood, the lower this value is, the better the quality should be) and there is where it gets really weird: the resulted file is much smaller, with a file weighting 24.7MB "only" (25 978 082 bytes), shouldn't it be the other way around since we specifically asked the encoder to spend more computing bits here and there?

So in this test that I was able to reproduce several times; placebo preset yields files that are smaller than veryslow, raises the Avg QP by roughly 5% (worse results), takes twice more time & ressources to encode than veryslow (counterproductive, really) and introduces banding, artefacts and compression "errors" here and there, rending a terrible quality encode over a much faster "simpler" preset.

Does that make sense to anyone here or have I missed something?

[LigH]

So what kind of decimal values can be passed to that parameter?

You can specify any precision. But the value may get rounded to a sensible precision either during the processing or during the report formatting. You may not notice an obvious difference between 1.8 and 1.9, so I guess the output format of this value in the log summary was reduced to one decimal just to limit the output width; the value used in the encoder may have a higher precision, but it won't matter much.

[TalasNetrag]

I have a warping (dont know how else to describe it) problem with x265 during motion.
This is the place to look out for:
https://www.mediafire.com/convkey/dccd/thvcezwop1f6ogc4g.jpg (http://www.mediafire.com/view/thvcezwop1f6ogc/scene1_x265_CRF18.png)

Using StaxRip: Quality: 18, Preset: Slower, Tune: None
scene1_x265_CRF18.mkv (http://www.mediafire.com/download/dp8fske9uz3nvnb/scene1_x265_CRF18.mkv)
The x264 encoder doesnt have this problem.
Quality: 18, Preset: Slower, Tune: Animation
scene1_x264_CRF18.mkv (http://www.mediafire.com/download/h8303jy3eyr00a5/scene1_x264_CRF18.mkv)
Both were encoded from this file.
scene1_x264_CRF0.mkv (http://www.mediafire.com/download/iriyiegs3n2ix3s/scene1_x264_CRF0.mkv)

[LigH]

Yes, a kind of "motion trails" with alternating distance, which seems to be related to mini-GOP ranges (means, the group of B frames between a pair of P, maybe I, frames).

[pingfr]

Anyone with insights regarding the "preset" issues I have reported last night?

[sneaker_ger]

the resulted file is much smaller, with a file weighting 24.7MB "only" (25 978 082 bytes), shouldn't it be the other way around since we specifically asked the encoder to spend more computing bits here and there?
What are "computing bits"?
I didn't see you telling x265 to create a bigger file. A slower preset means investing more computing time, not spending more bits. If anything, decreasing file sizes are expected with slower presets though crf does not guarantee same quality when used with a different set of options in the first place. So what you experienced may be totally normal though usually the name "placebo" should imply negligible differences in quality and bitrate compared to "veryslow". That said, I don't know if this sample is an edge case or if there actually is some underlying problem.

[littlepox]

@pingfr

try this and see whether you get any improvements.
ps: do NOT change any parameter, just copy and paste it:

--preset slower --ctu 32 --max-tu-size 16 --crf 18 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.6 --psy-rdoq 8.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --pbratio 1.2

See whether this helps you out or not.
This is based on the --tune film we have tested out. Again, do NOT modify any one of the above parameters otherwise you shall destroy the whole combination.

[pingfr]

@littlepox: Holy shit! The results are looking very good, the artefacts have disappeared, barely any banding in the sky, it encoded ultra fast (of course it's "only" the slower preset) and the result file was only 19MB big. :)

I'll try to see what can be tweaked further and/or more aggressively tomorrow, heading for my bed right now, it's past 3AM here, will get back to you tomorrow.

Thanks a ton! :)

[littlepox]

@littlepox: Holy shit! The results are looking very good, the artefacts have disappeared, barely any banding in the sky, it encoded ultra fast (of course it's "only" the slower preset) and the result file was only 19MB big. :)

I'll try to see what can be tweaked further and/or more aggressively tomorrow, heading for my bed right now, it's past 3AM here, will get back to you tomorrow.

Thanks a ton! :)

I'm using this to tell you that using --preset placebo to achieve quality expectation is a silly idea. No matter how slow you can tolerate, you can NEVER achieve any visible quality improvements.

The only solution is to explore rate-control parameters, which we have tested thousands of samples to offer you this combination. stick to it unless you have tested more.

[pingfr]

@littlepox: What about these settings combined with the --preset veryslow then? would it yield better perceptible quality... or at least a smaller out file? :)

[littlepox]

@littlepox: What about these settings combined with the --preset veryslow then? would it yield better perceptible quality... or at least a smaller out file? :)

Theoretically it should be, but we never spot any in our test, NEVER.

anyway, we have overrided a large number of preset-specified parameters like --ref --me --subme.... so --preset slower is not really "slower", but indeed it's running in a speed between slower and veryslow.

Be alerted that some parameters in veryslow/placebo actually DO hurt the quality, for example, --ctu 64 --max-tu-size 32. They create heavily blurring effect to wipe out details. We have reduced it to --ctu 32 --max-tu-size 16, which increases BOTH the speed and quality.

In short, NEVER hold a faith in --preset placebo. it's just a placebo, tasting sweet, no effect.

[pingfr]

@littlepox: Doing a full movie encode with your settings, really heading off to bed this time, will try another test as --preset veryslow afterwards see if it makes a smaller .hevc out file then I'll figure out which one I want to stick with... given the subjective quality are identical... indeed.

Good night.

Thanks a lot.

[nandaku2]

@pingfr

try this and see whether you get any improvements.
ps: do NOT change any parameter, just copy and paste it:

--preset slower --ctu 32 --max-tu-size 16 --crf 18 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.6 --psy-rdoq 8.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --pbratio 1.2

See whether this helps you out or not.
This is based on the --tune film we have tested out. Again, do NOT modify any one of the above parameters otherwise you shall destroy the whole combination.

Impressive! What kind of sources do you use this custom "tune film" on?

An improved tune grain is now available.

[luigizaninoni]

@pingfr

--preset slower --ctu 32 --max-tu-size 16 --crf 18 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.6 --psy-rdoq 8.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --pbratio 1.2


What modifications would you suggest for SD encoding ? Perhaps something like --crf 16 --ctu16 --max-tu-size 8 --merange 25 ?

[pingfr]

@littlepox: Good "morning".

x265 is still crunching, 46.9% done, eta: 11h30m.

At this rate, I will let you know the encoding results... most likely the next day. ;)

[littlepox]

Impressive! What kind of sources do you use this custom "tune film" on?

An improved tune grain is now available.

This is not the first time I showed this "--tune film". I have updated the previous post here with detailed explanation for the modifications: http://forum.doom9.org/showthread.php?t=172458

Basically, this applies to ALL sources with some level of noise/grain and you want to retain them for visual similarities between source and encode. It works especially well on recorded, high-quality sources like film BDs. Furthermore, this combination preserves details better than default or --tune grain. Our tests should have covered enough samples from different types.

We are mainly working on 1080p sources. No ideas about <720p or >1440p. Our primary focus is 10bit encoding, but I'd suppose with heavy grains, 8bit/10bit are not too much different for film sources.

The choice of parameters depend heavily on crf/bitrate. I would not suggest a similar combination if you are encoding around x265_crf=28. Currently, I'd only recommend to use it for crf=16~20, and even within this interval there are some minor but well-justified changes to make.

The settings can be modified to adapt less grainy sources to become a --tune animation, which is actually our primary focus since we are a team doing anime BDRips. It can also be adapted to a --tune grain by setting parameters favoring even more of grain retention, but we have not intensively tested about that given it brings edge artifacts raised from over-placing bits in flat areas and temporal artifacts raised from higher psy-values. We are not interested since it reduces overall quality, which is also true for x264.

This combination is updated with x265 v1.9 stable. I've notice that you are currently working on the RC issues for grainy sources, but I don't know how it is going to change the behavior of our settings. We plan to test further after v2.0. so @pingfr you are advised to use v1.9 stable and NOT the latest builds; we have not tested them so far.

I know you are going to have a new --tune grain, but previously with v1.9 stable, our --tune film outperform the official --tune grain with only 60% of bit-rate on grainy sources for grain retention. No offence, but the official tunings are really disappointing.

[littlepox]

What modifications would you suggest for SD encoding ? Perhaps something like --crf 16 --ctu16 --max-tu-size 8 --merange 25 ?

please use x264 --tune film --qcomp 0.75. This is the only suggestion I'll make.

[littlepox]

@littlepox: Good "morning".

x265 is still crunching, 46.9% done, eta: 11h30m.

At this rate, I will let you know the encoding results... most likely the next day. ;)

Good "evening".

Just repeat my previous hints here that you are advised to use x265 1.9 stable build (x265 1.9+1), which is the one we use to test this combination. We shall have no ideas about later builds until another scheduled testing after v2.0 is released.

I'm going to sleep in 2 hours, so I'd check you results when I wake up tomorrow.

[j1731630]

Hi! I have some simple question, which wont have a simple answer.
What software and settings should i use to encode video library(100gb mostly 8bit) into HEVC ?

Shotcut
Handbrake
Something else...

[Sharc]

please use x264 --tune film --qcomp 0.75. This is the only suggestion I'll make.
Isn't --qcomp effective for multipass only?

[LigH]

@ j1731630:

1. Do you really have to? You may save a little space (not certain!), but will lose some quality (quite certain), and spend some amount of electricity.

2. What runs on your machine (tell us some specs, especially OS and a little CPU/GPU details) and has a user interface you can handle.

[littlepox]

Isn't --qcomp effective for multipass only?

No. It is effective for all rc options.

[j1731630]

@ j1731630:

1. Do you really have to? You may save a little space (not certain!), but will lose some quality (quite certain), and spend some amount of electricity.

2. What runs on your machine (tell us some specs, especially OS and a little CPU/GPU details) and has a user interface you can handle.
1) I will do this only, if there is some settings which can provide minimum quality loss, and encode time wont be weeks per 1gb file.
2) MiddlePC, i5 4460, 12GB DDR3 1600, GTX 660. Win8.1_64

[LigH]

Alright, quite good hardware available.

Handbrake is a quite common tool, but a little more targeted towards portability across different OS'. There is also VidCoder as an additional UI, using Handbrake as converter engine, which is itself based on ffmpeg. You may also try Hybrid (by Selur) or TEncoder.

But there are more flexible tools specifically for Windows, using AviSynth rather than ffmpeg. One quite common converter of this family is StaxRip; MeGUI is a bit more technical, for advanced users. I bet I forgot about half a dozen more. But there are software archives with a lot of video converters, e.g. at VideoHelp.

[sneaker_ger]

An improved tune grain is now available.
I still get some weird effect:

Original:
http://abload.de/img/original_oduca.png
No tuning:
http://abload.de/img/no_tuning_q6uqn.png
Tune grain with weird effect:
http://abload.de/img/tune_grain_3luci.png

x265 1.9+86 10 bit 2pass, --preset slower (--tune grain) --bitrate 7000
Source and output files download (https://mega.nz/#F!51cRURzb!KtTjtCeP1e6rF9eb5tSAsA)

[pingfr]

@littlepox: The results are here. :)

First infos about the source:

General
Unique ID : 149648185676370562747073954039042049003 (0x709531337A3D6C98B6E41B9A40DA83EB)
Complete name : D:\source.mkv
Format : Matroska
Format version : Version 1
File size : 19.4 GiB
Duration : 2h 8mn
Overall bit rate mode : Variable
Overall bit rate : 21.6 Mbps
Encoded date : UTC 2016-03-10 02:21:51
Writing application : eac3to
Writing library : Haali DirectShow Matroska Muxer 1.13.138.14

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=3, N=24
Muxing mode : Container profile=@0.0
Codec ID : V_MPEG4/ISO/AVC
Duration : 2h 8mn
Bit rate mode : Variable
Bit rate : 21.2 Mbps
Maximum bit rate : 28.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.426
Stream size : 19.1 GiB (98%)
Default : No
Forced : No
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Then the .avs script used:

LoadPlugin("C:\Program Files (x86)\MeGUI\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("D:\source.mkv")
#deinterlace
crop(0, 20, 0, -20)
#resize
#denoise

Then the x265 parameters used:

@echo off
avs4x265.exe -P x265.exe --preset slower --ctu 32 --max-tu-size 16 --crf 18 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.6 --psy-rdoq 8.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --pbratio 1.2 --output slower.hevc %1
pause

Then what the log output spit out:

avs [info]: AviSynth 2.60 (ICL10)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x1040
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 185220
avs4x265 [info]: "x265.exe" - --frames 185220 --fps 24000/1001 --input-res 1920x1040 --input-csp i420 --preset slower --ctu 32 --max-tu-size 16 --crf 18 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.6 --psy-rdoq 8.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --pbratio 1.2 --output slower.hevc
yuv [info]: 1920x1040 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: slower.hevc
x265 [info]: HEVC encoder version 1.9+73-6d06de58c316
x265 [info]: build info [Windows][GCC 5.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: frame threads / pool features : 5 / wpp(33 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 16 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : star / 44 / 5 / 4
x265 [info]: Keyframe min / max / scenecut : 1 / 360 / 40
x265 [info]: Intra 32x32 TU penalty type : 2
x265 [info]: Lookahead / bframes / badapt : 80 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / 1 / 0
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 16 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.80
x265 [info]: tools: rect limit-modes rd=5 psy-rd=1.60 rdoq=1 psy-rdoq=8.00
x265 [info]: tools: signhide tmvp b-intra lslices=4 deblock(tC=-2:B=-2)

x265 [info]: frame I: 1520, Avg QP:14.06 kb/s: 27871.26
x265 [info]: frame P: 36198, Avg QP:16.17 kb/s: 18701.89
x265 [info]: frame B: 147502, Avg QP:18.18 kb/s: 7831.84
x265 [info]: Weighted P-Frames: Y:1.3% UV:0.9%
x265 [info]: Weighted B-Frames: Y:1.0% UV:0.7%
x265 [info]: consecutive B-frames: 7.5% 5.2% 6.5% 15.3% 7.1% 54.1% 2.9% 0.6% 0.8%

encoded 185220 frames in 77139.97s (2.40 fps), 10120.65 kb/s, Avg QP:17.76
Press a key to continue...

And the resulted file details from mediainfo / mpc-hc:

General
Format : HEVC
Format/Info : High Efficiency Video Coding
File size : 9.10 GiB
Writing library : x265 1.9+73-6d06de58c316:[Windows][GCC 5.3.0][64 bit] 8bit
Encoding settings : wpp / ctu=32 / min-cu-size=8 / max-tu-size=16 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=5 / merange=44 / rect / no-amp / max-merge=4 / temporal-mvp / no-early-skip / rdpenalty=2 / no-tskip / no-tskip-fast / no-strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / no-open-gop / no-temporal-layers / interlace=0 / keyint=360 / min-keyint=1 / scenecut=40 / rc-lookahead=80 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=16 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=5 / psy-rd=1.60 / rdoq-level=1 / psy-rdoq=8.00 / no-rd-refine / signhide / deblock=-2:-2 / no-sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=18.0 / qcomp=0.80 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.20

Video
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L5@Main
Width : 1 920 pixels
Height : 1 040 pixels
Display aspect ratio : 1.85:1
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Writing library : x265 1.9+73-6d06de58c316:[Windows][GCC 5.3.0][64 bit] 8bit
Encoding settings : wpp / ctu=32 / min-cu-size=8 / max-tu-size=16 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=5 / merange=44 / rect / no-amp / max-merge=4 / temporal-mvp / no-early-skip / rdpenalty=2 / no-tskip / no-tskip-fast / no-strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / no-open-gop / no-temporal-layers / interlace=0 / keyint=360 / min-keyint=1 / scenecut=40 / rc-lookahead=80 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=16 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=5 / psy-rd=1.60 / rdoq-level=1 / psy-rdoq=8.00 / no-rd-refine / signhide / deblock=-2:-2 / no-sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=18.0 / qcomp=0.80 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.20

It doesn't tell the actual bitrate until merged into a .mkv container:

General
Unique ID : 226389536216421172588785103110168979842 (0xAA5109E78E571BDBACF0BFAA0BDD2982)
Complete name : D:\slower.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 9.10 GiB
Duration : 2h 8mn
Overall bit rate : 10.1 Mbps
Encoded date : UTC 2016-03-11 00:01:03
Writing application : mkvmerge v8.9.0 ('Father Daughter') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4
DURATION : 02:08:45.218000000
NUMBER_OF_FRAMES : 185220
NUMBER_OF_BYTES : 9773771334
_STATISTICS_WRITING_APP : mkvmerge v8.9.0 ('Father Daughter') 64bit
_STATISTICS_WRITING_DATE_UTC : 2016-03-11 00:01:03
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L5@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2h 8mn
Bit rate : 9 922 Kbps
Width : 1 920 pixels
Height : 1 040 pixels
Display aspect ratio : 1.85:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.207
Stream size : 8.92 GiB (98%)
Writing library : x265 1.9+73-6d06de58c316:[Windows][GCC 5.3.0][64 bit] 8bit
Encoding settings : wpp / ctu=32 / min-cu-size=8 / max-tu-size=16 / tu-intra-depth=2 / tu-inter-depth=2 / me=3 / subme=5 / merange=44 / rect / no-amp / max-merge=4 / temporal-mvp / no-early-skip / rdpenalty=2 / no-tskip / no-tskip-fast / no-strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / no-open-gop / no-temporal-layers / interlace=0 / keyint=360 / min-keyint=1 / scenecut=40 / rc-lookahead=80 / lookahead-slices=4 / bframes=8 / bframe-bias=0 / b-adapt=2 / ref=5 / limit-refs=2 / limit-modes / weightp / weightb / aq-mode=1 / qg-size=16 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=5 / psy-rd=1.60 / rdoq-level=1 / psy-rdoq=8.00 / no-rd-refine / signhide / deblock=-2:-2 / no-sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=18.0 / qcomp=0.80 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.20
Default : Yes
Forced : No

I bolded the important parts for emphasis.

Properties of the .mkv file (and that's without any audio tracks added yet):

slower.mkv 9,10 GB (9.775.362.219 bytes)

So sure, the quality is top notch, it's hard to tell any differences with the original file grabbed straight from the source media which was about 19.4GB with an overall bitrate of 21.6 Mbps with a maximum bitrate peak of 28/0 Mbps but...

A such large file makes it unpractical for archiving purposes, let alone the fact it took no less than 77139 seconds to encode (1285 minutes or 21.43 hours, almost 22 hours!!!).

I was understanding that the main interest in x265/HEVC was to allow "high quality" content streaming/delivering/archiving with bitrate starved media/connections?

The very same movie in x264 with rather high-end settings weights only about 9.40GB once processed through x264 latest version... oh, and that's with a 2 hours DTS 5.1 track embedded within the matroska container versus here a 9.10 GB file *without* any audio tracks, just the video tracked processed through your settings.

What the hell? :)

Edit: Sorry my bad, I meant 9.40GB as x264 encode with audio track; not 6.40GB but with audio track still, versus a x265 encode of 9.10GB and no audio muxed yet. So my point stands still: x265 produced a file larger than x264 would have.

[littlepox]

x265 produced a file larger than x264 would have.

It takes long to explain, but you are comparing apples to oranges.

first of all, I can definitely give you another combination which is just 50% of the bit-rate. and I can give you another with double bit-rate but even more perfect of quality. I can even give you a third combination which encodes the movie into 1Mbps, but then you'd probably say "x265 produced a worse quality than x264 would have."

The point is that except for bit-rate, you must compare the visual quality as well, and the comparison must be rigorous and unambiguous.

We are often doing something like this: take the encoded samples with similar bitrate(<5% of difference), then we take ~20 random frames and compare it one by one:

32256 avc -1
16045 hevc 1
33030 hevc 1
20843 tie 0
05108 hevc 1
32023 hevc 1
15225 avc -1
13857 hevc 1
34702 hevc 1
15489 hevc 1
21942 hevc 1
33808 tie 0
29432 avc -1
03147 tie 0
04602 hevc 1
00156 avc -1
22487 hevc 1
33557 hevc 1
32219 avc -1
15616 avc -1

hevc 11 Mean 0.25
avc 6 SE 0.203586268
tie 3 t-value 1.227980663
P-value 89.70%

For this one, out of 20 random sampled frames, hevc looks better on 11 frames, its counter part wins 6, and 3 end up indistinguishable. Then some statistical computation tells you that you can say HEVC outperforms AVC in this test with 89.7% sure.

This is how we managed to get something better than the default tunings. Without such rigorous benchmarks, nothing can be concluded.

[pingfr]

Still doesn't change the fact the resulted file size makes it highly unpractical to archive as it is and the main key selling point of HEVC and x265 is "equal quality if not better than x264 at half the size/half the bitrate".

That's clearly not the case here.

Would you happen to have a set of parameters which can retain quality pretty well while cutting down on the final target encode file size?

Thanks a lot.

[littlepox]

A such large file makes it unpractical for archiving purposes, let alone the fact it took no less than 77139 seconds to encode (1285 minutes or 21.43 hours, almost 22 hours!!!).

Back to the point where you wish to backup your BDs, here are the suggestions:

1. Use 10bit x265 v1.9 stable. We have not tested further builds so we don't know what's going to happen. Furthermore, 10bit encoding gives you an unconditional, significant improvement.

2. To implement the above, just download http://www.msystem.waw.pl/x265/x265-1.9+5-20f14d7-stable_vs2015-AVX2.7z
upzip the x265-10b.exe, rename it to x265.exe, replace the one in your C:\Program Files (x86)\MeGUI\tools\x265\x64\x265.exe or whichever you were using as the encoder.

3. try the new combination:

-D 10 --preset slower --ctu 32 --max-tu-size 16 --crf 20 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.5 --psy-rdoq 5.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 4 --qcomp 0.75 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --pbratio 1.2

[littlepox]

Still doesn't change the fact the resulted file size makes it highly unpractical to archive as it is and the main key selling point of HEVC and x265 is "equal quality if not better than x264 at half the size/half the bitrate".

That's clearly not the case here.

Would you happen to have a set of parameters which can retain quality pretty well while cutting down on the final target encode file size?

Thanks a lot.

See my replies above.

BTW, never trust those lies telling you that "x265 is equal quality if not better than x264 at half the size/half the bitrate". Out of so much we have tested, for high quality ripping, compared by visual quality, x265 takes ~90% of the bitrate to match up its counter part. If you just use official tunings, it's about ~160%, namely, x264 is equal quality if not better than x265 at half the size/half the bitrate, without highly professional tuning.

[pingfr]

Back to the point where you wish to backup your BDs, here are the suggestions:

1. Use 10bit x265 v1.9 stable. We have not tested further builds so we don't know what's going to happen. Furthermore, 10bit encoding gives you an unconditional, significant improvement.

Compatility-hit, no can do.

2. To implement the above, just download http://www.msystem.waw.pl/x265/x265-1.9+5-20f14d7-stable_vs2015-AVX2.7z
upzip the x265-10b.exe, rename it to x265.exe, replace the one in your C:\Program Files (x86)\MeGUI\tools\x265\x64\x265.exe or whichever you were using as the encoder.

Good guess. That's effectively where my x265.exe resides, I just appended the path to the system variables.

3. try the new combination:

-D 10 --preset slower --ctu 32 --max-tu-size 16 --crf 20 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.5 --psy-rdoq 5.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 4 --qcomp 0.75 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --pbratio 1.2

-D 10 and --crf 20, that's a no go for me. The rest of the settings are worth exploring however when combined with a --crf 18.

Thank you for your time.

[pingfr]

See my replies above.

BTW, never trust those lies telling you that "x265 is equal quality if not better than x264 at half the size/half the bitrate". Out of so much we have tested, for high quality ripping, compared by visual quality, x265 takes ~90% of the bitrate to match up its counter part. If you just use official tunings, it's about ~160%, namely, x264 is equal quality if not better than x265 at half the size/half the bitrate, without highly professional tuning.

Then I think we have a problem here, msu.ru's HEVC Video Codecs Comparison along with quite a few different sites/blogs/articles on the web are claiming that x265/HEVC is vastly superior to x264 in situations where the bitrate is an issue and that x265 yields much smaller files to their x264 counterpart while retaining excellent quality if not better.

When you manage a library of 2600 movies like I do for an online public library (legal) every single megabyte worth of shaved off storage space is worth the effort re-encoding everything to x265... only if the yielded results effectively are smaller than their x264 counterpart that is.

[littlepox]

Compatility-hit, no can do.

All right, then just use x265-8b.exe. BTW our test was done for 10bit, so it's not going to be the best solution under 8bit.



-D 10 and --crf 20, that's a no go for me. The rest of the settings are worth exploring however when combined with a --crf 18.

Thank you for your time.

Bear in mind that --crf here is NOT telling you enough stories. Just compare this --crf 20 with a default --crf 16 and you shall probably prefer --crf 20 version. And the --crf in x265 should never be compared to its counterpart in x264, they just share a same name, that's all.

Furthermore, if you really wish to use --crf 18 with our suggestions, use the previous settings. Every individual parameter has its purpose and should work together as a whole.

[pingfr]

Bear in mind that --crf here is NOT telling you enough stories. Just compare this --crf 20 with a default --crf 16 and you shall probably prefer --crf 20 version.

Not exactly sure to understand what you actually meant here as the reason why would I prefer a --crf 20 encode over a --crf 16 one exactly?

And the --crf in x265 should never be compared to its counterpart in x264, they just share a same name, that's all.

And that sir, I think is one of the things about 54546543765 readers on this forum have been asking for since the very first page of this topic.

Devs have been more or less asked to give us a "table" of what to expect in terms of understanding/equaling/matching CRF values back and forth between x264 and x265.

x264 is nearly a decade old, video enthusiasts have been used for the past 10 years to use either 2-pass encoding (inherited from the XviD days and from the DivX days even before that) or use the CRF values from the very earliest x264 days, therefore the x265 devs should know that powerusers are not going to give up on that.

Good luck with convincing and explaining those users that crf 18 in x265 isn't equal to crf 18 in x264 and so forth.

The day we may see a conversion table added to official docs might actually change that, until then...

Furthermore, if you really wish to use --crf 18 with our suggestions, use the previous settings. Every individual parameter has its purpose and should work together as a whole

So which set of parameters should I use with a -D 8 --crf 18 if I would like to retain the same level of quality while cutting on the file size?

[littlepox]

Then I think we have a problem here, msu.ru's HEVC Video Codecs Comparison along with quite a few different sites/blogs/articles on the web are claiming that x265/HEVC is vastly superior to x264 in situations where the bitrate is an issue and that x265 yields much smaller files to their x264 counterpart while retaining excellent quality if not better.

When you manage a library of 2600 movies like I do for an online public library (legal) every single megabyte worth of shaved off storage space is worth the effort re-encoding everything to x265... only if the yielded results effectively are smaller than their x264 counterpart that is.

1. They are testing with objective benchmarks like psnr/ssim, NOT human eyes. With these digit benchmarks there are dozens of encoders claiming themselves better than x264 in the past a few years. For the most recent one, try daala;).

2. They are primarily focus on low bit-rate cases like crf=28. You can't even stand crf=20, so their conclusion makes no sense to you.

3. Indeed, the lower the bitrate, the better x265 performs. But that's not for the case of ripping so I'd not continue.

[littlepox]

Not exactly sure to understand what you actually meant here as the reason why would I prefer a --crf 20 encode over a --crf 16 one exactly?

OK my point is that --crf itself cannot determine the visual quality completely, you have to look at the other parameters it is using with.

just take the mature, well-recognized x264. try for your film sources:

x264 --preset veryslow --crf 19 --tune film --qcomp 0.7
x264 --preset veryslow --crf 16 --qcomp 0.4 --psy-rd 0.2:0 --aq-strength 0.3

guess what? the first encode with --crf 19 will surely looks better than the second --crf 16. Because the 2nd one, the rc parameters combined is so ill-conditioned.

Do this test and then think about the case, you can't even seek for consistency within x264, do you expect any consistency across encoders, with another set of highly customized settings?

[littlepox]

So which set of parameters should I use with a -D 8 --crf 18 if I would like to retain the same level of quality while cutting on the file size?

-D 8 --preset slower --ctu 32 --max-tu-size 16 --crf 19 --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me 3 --subme 5 --merange 44 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 360 --min-keyint 1 --bframes 8 --aq-mode 1 --aq-strength 1.0 --rd 5 --psy-rd 1.5 --psy-rdoq 5.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 4 --qcomp 0.8 --no-strong-intra-smoothing --deblock -2:-2 --qg-size 16 --pbratio 1.2

pretend that you don't know the crf, test about it, and give me your feedback.

[pingfr]

Gotcha.

Just like we did the experiment with a well provisioned --preset slower or --preset veryslow yielding better perceptible results over a "vanilla" un-tweaked --preset placebo.

Still, there is something I don't get. I've seen (sadly, pirated) content posted on public and popular peer-to-peer trackers for 2160p contents which was ripped from UHD 4k Blu-Ray discs even and let's say that a 4GB encoded file for an over 2 hours encoded fully action packed-action fast paced movie is... quite impressive.

I will not post such links here as I have no interest whatsoever in promoting piracy in any ways/forms/shapes however, I've seen the results myself they are quite... amazing.

Should I bother pasting the used parameters here from the file properties? Would this be of any use to you?

[littlepox]

Gotcha.

Just like we did the experiment with a well provisioned --preset slower or --preset veryslow yielding better perceptible results over a "vanilla" un-tweaked --preset placebo.

Still, there is something I don't get. I've seen (sadly, pirated) content posted on public and popular peer-to-peer trackers for 2160p contents which was ripped from UHD 4k Blu-Ray discs even and let's say that a 4GB encoded file for an over 2 hours encoded fully action packed-action fast paced movie is... quite impressive.

I will not post such links here as I have no interest whatsoever in promoting piracy in any ways/forms/shapes however, I've seen the results myself they are quite... amazing.

Should I bother pasting the used parameters here from the file properties? Would this be of any use to you?

I've seen some of the 4K BDRips, and surprisingly, some of them are using the parameters I posted here:
http://forum.doom9.org/showthread.php?t=172458
which used to be an earlier version of our "--tune film"

Of cause the probability that we are talking about the same encode is really rare. So I guess it could be:

1. You have not seen the sources. It could be that compared to the sources a lot of details are gone, you just don't know.

2. x265 itself is well-tuned for 4K contents with lower bit-rates. You aren't doing the same thing; you are working on 1080p high bit-rates.

3. They've got their own testing to replace the default tunings. Pls post the mediainfo here, see what I can read out of it.

[pingfr]

There you go:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : @L5@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2h 8mn
Width : 3 840 pixels
Height : 1 608 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 10 bits
Writing library : x265 1.8+167-e951ab673b1c:[Windows][GCC 5.2.0][64 bit] 10bit
Encoding settings : wpp / ctu=32 / min-cu-size=16 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=0 / subme=0 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=0 / rc-lookahead=5 / lookahead-slices=8 / bframes=3 / bframe-bias=0 / b-adapt=0 / ref=1 / limit-refs=0 / no-limit-modes / no-weightp / no-weightb / aq-mode=0 / qg-size=32 / aq-strength=0.00 / cbqpoffs=6 / crqpoffs=6 / rd=2 / psy-rd=0.30 / rdoq-level=0 / psy-rdoq=0.00 / no-signhide / deblock / no-sao / no-sao-non-deblock / b-pyramid / no-cutree / no-intra-refresh / rc=abr / bitrate=4300 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
Default : Yes
Forced : No

Resulted .mkv file size: 4.18 GB (4.494.613.248 bytes) and that's even with a freaking audio AAC track.

[littlepox]

There you go:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : @L5@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2h 8mn
Width : 3 840 pixels
Height : 1 608 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 10 bits
Writing library : x265 1.8+167-e951ab673b1c:[Windows][GCC 5.2.0][64 bit] 10bit
Encoding settings : wpp / ctu=32 / min-cu-size=16 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=0 / subme=0 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=0 / rc-lookahead=5 / lookahead-slices=8 / bframes=3 / bframe-bias=0 / b-adapt=0 / ref=1 / limit-refs=0 / no-limit-modes / no-weightp / no-weightb / aq-mode=0 / qg-size=32 / aq-strength=0.00 / cbqpoffs=6 / crqpoffs=6 / rd=2 / psy-rd=0.30 / rdoq-level=0 / psy-rdoq=0.00 / no-signhide / deblock / no-sao / no-sao-non-deblock / b-pyramid / no-cutree / no-intra-refresh / rc=abr / bitrate=4300 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30
Default : Yes
Forced : No

Resulted .mkv file size: 4.18*GB (4.494.613.248 bytes) and that's even with a freaking audio AAC track.

first of all they are using 10bit, which is extremely powerful in low-bitrate since it is immune to banding/blocking artifacts.


second, they are using --preset ultrafast --bitrate 4300. The lowest preset you can ever set, without any tuning, and a fairly low bit-rate for 4K content.

I've done similar test before. The result is that x265-10bit will wash out every film grain or tiny details to give you a clean, blurry video. But after downscaled from 4K to 1080p, you don't feel any uncomfortable as if watching a DVD; you don't see banding/blocking/broken edge neither. This is exactly the power of HEVC-10bit under high resolution, extremely low bit-rates.

BUT this has NOTHING to do with 1080p, high-bitrate encoding.

[pingfr]

first of all they are using 10bit, which is extremely powerful in low-bitrate since it is immune to banding/blocking artifacts.

Alrighty.

second, they are using --preset ultrafast --bitrate 4300. The lowest preset you can ever set, without any tuning, and a fairly low bit-rate for 4K content.

I have noticed that, when manually comparing each parameter they passed to the encoder with the parameters found from the official preset page;

http://x265.readthedocs.org/en/default/presets.html

That's why it was confusing to begin with, that, coupled with the excessively low bitrate of 4300.

I've done similar test before. The result is that x265-10bit will wash out every film grain or tiny details to give you a clean, blurry video. But after downscaled from 4K to 1080p, you don't feel any uncomfortable as if watching a DVD; you don't see banding/blocking/broken edge neither. This is exactly the power of HEVC-10bit under high resolution, extremely low bit-rates.

BUT this has NOTHING to do with 1080p, high-bitrate encoding.

Time to find proper settings for 1080p high quality archival then.

Do you feel it would be possible at this point to find settings for x265 which would result in an encoded 1080p/720p contents weighting 25% less than it's x264 counterpart or am I being delusional here?

Edit; Also encoding a shorter movie (1h23m) with the latest settings you gave me 3 posts ago, it seems to encode much faster, ~6 fps versus ~2.4 fps, but then it could be because I switched from a 1920x1040 source to a 1920x800, less data to encode per frame = faster encoding I guess. ETA is: 6 hours. I will let you know the results whenever I get them done.