x265 HEVC Encoder

[j1731630]

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

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]

Originally Posted by nandaku2

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

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

Originally Posted by pingfr

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]

Originally Posted by pingfr

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

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

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]

Originally Posted by littlepox

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.

Originally Posted by littlepox

2. To implement the above, just download http://www.msystem.waw.pl/x265/x265-...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.

Originally Posted by littlepox

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]

Originally Posted by littlepox

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]

Originally Posted by pingfr

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.

Originally Posted by pingfr

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

Originally Posted by littlepox

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?

Originally Posted by littlepox

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...

Originally Posted by littlepox

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]

Originally Posted by pingfr

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]

Originally Posted by pingfr

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]

Originally Posted by pingfr

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]

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

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]

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

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]

Originally Posted by littlepox

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

Alrighty.

Originally Posted by littlepox

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.

Originally Posted by littlepox

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.