x265 HEVC Encoder

[markiemarcus]

I often see this also. But I don't understand why they use it. I did tests and noticed that CTU 32 and qg-size 8 is not better than CTU 64 qg-size 32 (and sometimes even worse). And also it seems to me that aq-mode 2 is better than 1. I'm not a professional, it's only my humble opinion.
Ps: I looked at your settings, do you sure that ctu 32 merange 40 is better for 1080p than ctu 64 merange 57?

Found the same thing. I even find CTU 32 worse for grain retention, though it does make it look less boxy if using RDOQ Level 2. No-cutree I've seen cause issues in animation.

Aq mode 1 I find more consistent than 2 if the source has intermittent low luma. Aq mode 3 obviously works well, though in my experience not always better than Aq-mode 1. Metrics don't tell the whole story.

[markiemarcus]

Sure, the below is always my starting point then I tweak from there if necessary with a dial or two down on --aq-strength and/or a notch or two up on --psy-rd. This is for a broad range of film sources at 1080p resolution.

I see I'm not the only one who disables rect! The difference is so fractional on most content I've tested.

[redbtn]

Aq mode 1 I find more consistent than 2 if the source has intermittent low luma. Aq mode 3 obviously works well there, though in my experience not always better than Aq-mode 1. Metrics don't tell the whole story.

I use aq-mode 2 for HDR 10bit encodes. For SDR maybe better 1, I didn't much tests with SDR.

Any thoughts about using no-rskip? Does it make sense?

I see I'm not the only one who disables rect! The difference is so fractional on most content I've tested.

I use no-rect too.

[markiemarcus]

I use aq-mode 2 for HDR 10bit encodes. For SDR maybe better 1, I didn't much tests with SDR.

Any thoughts about using no-rskip? Does it make sense?



I use no-rect too.

I have zero experience with HDR I'm afraid, but at least a few hundred hours with SDR. I've heard a number of people say that too, though.

I never bother with no-rskip. Rskip works very well. Some other preferences:

I use rdLevel 4 and almost exclusively --limit-refs 1. If the performance impact weren't so dramatic, I'd use rdLevel 6. It's just better, there's no getting around that, but it is awfully slow.

Considering the performance boost, early-skip isn't half bad either. You seem to be able to overcome most of its shortcomings with a 0.1 to 0.2 drop in CRF, which is not the case with some of the other settings.

I've seen animated content that benefits from Sub-me 7 (yes, really), RC lookahead 80 and lookahead slices 1. It really doesn't hurt performance all that much either, but otherwise, the slower preset values for those are spot on.

I've seen reproducible grain freezing and other blocking craziness with tu-intra 4, tu-inter 4 so I'm weary of anything other than 1. Limit-tu I don't know what to make of. I don't fully understand it either, or its relation to intra/inter. If the content is super flat animation and clean as a whistle, values of 4, 4 and 4 seem to work well enough.

--cbqpoffs -1 --crqpoffs -2 works well for animation. x265 seems to struggle with deep reds without this.

-tskip is nice. t-skip-fast causes problems in animation.

--aq-motion is decent with Aq-mode 1 and generally allows a 0.5 drop in CRF for the same filesize, for which there is a noticeable benefit. I don't understand the dislike or distrust of the feature.

--weightb I think is a must, along with b-intra.

Both Rect and Amp are of extremely limited use IMO. Perhaps it's just the content I've been testing. I've seen comparable results with both disabled, to having both enabled along with limit-modes. With --no-limit-modes, yes, the difference I could spot, but it's dog slow. This was on animated content though; I haven't tested that on live action.

6 bframes I think is a good compromise for most content, though I've seen some small benefits to using double that on animated content.

--selective-sao 1 is nice and now my go-to.

qg-size 64 works well, even at 1080p. It's great on animated content.

I don't go higher than max-merge 3. I've seen 4 and 5 produce worse results than 3 during fast motion in animated content. I don't know why.

As I'd mentioned previously, I'm really not a fan of RDOQ Level 1 or 2. I much prefer Level 0 with much higher Psy-rd values instead. I understand why people like it, I just think it's ugly.

--deblock -4:-1 on grainy or dithered stuff, --deblock -3:0 or -2:0 otherwise.

--fades seems to work well.

Default Me range and Star. UMH is better, but it's fractional.

refs 4 is generally speaking adequate IMO.

I keep strong-intra-smoothing on.

Aq strength is difficult. Generally the default or 0.9 is fine, but if the content is super, super grainy, I've gone as low as 0.6 and put the difference into a lower CRF for better results.

So my settings are a bit weird. I've arrived at them from probably thousands of 2 pass tests over a few years, aiming for 2:1 over x264 and no more.

[redbtn]

I have zero experience with HDR I'm afraid, but at least a few hundred hours with SDR. I've heard a number of people say that too, though.



I never bother with no-rskip. Rskip works very well. Some other preferences:



I use rdLevel 4 and almost exclusively --limit-refs 1. If the performance impact weren't so dramatic, I'd use rdLevel 6. It's just better, there's no getting around that, but it is awfully slow.



Considering the performance boost, early-skip isn't half bad either. You seem to be able to overcome most of its shortcomings with a 0.1 to 0.2 drop in CRF, which is not the case with some of the other settings.



I've seen animated content that benefits from Sub-me 7 (yes, really), RC lookahead 80 and lookahead slices 1. It really doesn't hurt performance all that much either, but otherwise, the slower preset values for those are spot on.



I've seen reproducible grain freezing and other blocking craziness with tu-intra 4, tu-inter 4 so I'm weary of anything other than 1. Limit-tu I don't know what to make of. I don't fully understand it either, or its relation to intra/inter. If the content is super flat animation and clean as a whistle, values of 4, 4 and 4 seem to work well enough.



--cbqpoffs -1 --crqpoffs -2 works well for animation. x265 seems to struggle with deep reds without this.



-tskip is nice. t-skip-fast causes problems in animation.



--aq-motion is decent with Aq-mode 1 and generally allows a 0.5 drop in CRF for the same filesize, for which there is a noticeable benefit. I don't understand the dislike or distrust of the feature.



--weightb I think is a must, along with b-intra.



Both Rect and Amp are of extremely limited use IMO. Perhaps it's just the content I've been testing. I've seen comparable results with both disabled, to having both enabled along with limit-modes. With --no-limit-modes, yes, the difference I could spot, but it's dog slow. This was on animated content though; I haven't tested that on live action.



6 bframes I think is a good compromise for most content, though I've seen some small benefits to using double that on animated content.



--selective-sao 1 is nice and now my go-to.



qg-size 64 works well, even at 1080p. It's great on animated content.



I don't go higher than max-merge 3. I've seen 4 and 5 produce worse results than 3 during fast motion in animated content. I don't know why.



As I'd mentioned previously, I'm really not a fan of RDOQ Level 1 or 2. I much prefer Level 0 with much higher Psy-rd values instead. I understand why people like it, I just think it's ugly.



--deblock -4:-1 on grainy or dithered stuff, --deblock -3:0 or -2:0 otherwise.



--fades seems to work well.



Default Me range and Star. UMH is better, but it's fractional.



refs 4 is generally speaking adequate IMO.



I keep strong-intra-smoothing on.



Aq strength is difficult. Generally the default or 0.9 is fine, but if the content is super, super grainy, I've gone as low as 0.6 and put the difference into a lower CRF for better results.



So my settings are a bit weird. I've arrived at them from probably thousands of 2 pass tests over a few years, aiming for 2:1 over x264 and no more.Thank you for very useful information! I'll try selective-sao 1 and tu intra inter 1 (if I recall correctly, it's gives 8-10% more bitrate but 10% faster).
I didn't find on my tests that --strong-intra-smoothing is giving better results, but maybe I was wrong. My target bitrate is 16-18mbps for 1080p, so maybe it's a reason?

[markiemarcus]

Thank you for very useful information! I'll try selective-sao 1 and tu intra inter 1 (if I recall correctly, it's gives 8-10% more bitrate but 10% faster).
I didn't find on my tests that --strong-intra-smoothing is giving better results, but maybe I was wrong. My target bitrate is 16-18mbps for 1080p, so maybe it's a reason?

No sweat. I'm only guessing the CRF you're going to need. The results are very sensitive to it; very fine noise requires a low CRF. I'd say that the useful range is CRF 16 to 19. Bear in mind that there's no RDOQ level 2, which immediately knocks around 0.6 off the CRF of any corresponding preset that uses it and another 0.6 from aq-motion. CRF 16 here is more like CRF 17.5 by default.

--crf 16 --preset slow --output-depth 10 --limit-refs 1 --limit-tu 4 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 0 --no-rect --tskip --early-skip --b-intra --qg-size 64 --aq-strength 0.7 --cbqpoffs -1 --crqpoffs -2 --aq-motion --subme 7 --weightb --bframes 6 --rc-lookahead 80 --lookahead-slices 1 --deblock -4:-1 --psy-rd 5 --fades --selective-sao 1 --aq-mode 1

Everybody seems to have their own way of doing these things, this just happens to be mine. It's fast also. There's no reason why Aq-mode 2 wouldn't work if that's what you want, but it is a little less detailed on SDR sources from what I've tested, especially with regards to dither preservation. --qg-size 32 also works, but I prefer the look of 64 and I'd swear it's more detailed in low luma and holds together the deep reds better. --aq-mode 3 also works well if you prefer.

It's worth tuning aq strength. The value depends on the source obviously, but 0.7 is a good a place to start.

RainyDog's suggestion looks really nice and is far better than the default IMO. CRF 19.5 there is about the same size as CRF 16 here. Most of my testing was done on grainy animation, or animation with a lot of dither. They're quite different looking.

[RainyDog]

I often see this also. But I don't understand why they use it. I did tests and noticed that CTU 32 and qg-size 8 is not better than CTU 64 qg-size 32 (and sometimes even worse). And also it seems to me that aq-mode 2 is better than 1. I'm not a professional, it's only my humble opinion.
Ps: I looked at your settings, do you sure that ctu 32 merange 40 is better for 1080p than ctu 64 merange 57?

I've just done another test of CTU 32 vs 64 on my current encode and it's really just splitting hairs at the bitrates I aim for at least. Some parts of the frame might appear slightly better on extreme scrutiny with one then the other but it's generally a wash other than CTU 32 is slighty faster.

Me-range 40 is about the cut off point where you just get diminishing returns for 1080p content at least.

Qg-size is still a bit of ahead scratcher for me. In theory, 8 should yield bigger size encodes with the most detail retention but at the expense of more artifacting. Yet everytime I've tested at the same settings and CRF, qg-size 16 comes out the biggest, size 8 by far the smallest with 32 sat somewhere in between! So I usually just leave it at the default of 32.

[LigH]

@redbtn: Thank you for considering not to quote a several pages long post to reply only briefly. Often a @name is sufficient. Or trim the quote to a relevant part.

[RainyDog]

--selective-sao 1 is nice and now my go-to.

You do realise that all selective sao 1 does is apply SAO to I-frames which are less than 1% of your encode, right? :p

SAO really needs a strength setting more than anything else. I feel it could be highly useful for all content if it could be tuned.

[markiemarcus]

You do realise that all selective sao 1 does is apply SAO to I-frames which are less than 1% of your encode, right? :p

SAO really needs a strength setting more than anything else. I feel it could be highly useful for all content if it could be tuned.

Yup! But I agree.

[markiemarcus]

Qg-size is still a bit of ahead scratcher for me. In theory, 8 should yield bigger size encodes with the most detail retention but at the expense of more artifacting. Yet everytime I've tested at the same settings and CRF, qg-size 16 comes out the biggest, size 8 by far the smallest with 32 sat somewhere in between! So I usually just leave it at the default of 32.

If you restore limit-tu , tu-intra-depth and tu-inter-depth to the default, I suspect things will start behaving like you'd expect with the filesize.

[_kermit]

Sure, the below is always my starting point then I tweak from there if necessary with a dial or two down on --aq-strength and/or a notch or two up on --psy-rd. This is for a broad range of film sources at 1080p resolution.

thanks, I'll give that a try.

Can anyone provide something like that for UHD/HDR?

[RainyDog]

thanks, I'll give that a try.

Can anyone provide something like that for UHD/HDR?

I use the same template for HDR encodes just with the additional required HDR knobs (hdr-opt etc.) turned on. CRF needs to be bumped down a couple of notches for HDR though ie. CRF 17 for SDR = CRF 15 for HDR.

Again, this is all at 1080p resolution. For UHD all I'd probably change is CTU 32 > 64, me-range 40 > 57 and possibly qg-size 32 > 64.

[RainyDog]

If you restore limit-tu , tu-intra-depth and tu-inter-depth to the default, I suspect things will start behaving like you'd expect with the filesize.

I'll have a look at that then.

I've never really seen much difference in quality or size between tu-intra-depth inter-depth and limit-tu all set to 4 versus 1, 1 and 0 anyway. I only really use the former as it's a buffed setting with minor performance hit.

I think the gains from increasing tu-intra and inter-depth are probably only really seen without using limit-tu. But the speed decrease is pretty severe then.

[markiemarcus]

I'll have a look at that then.

I've never really seen much difference in quality or size between tu-intra-depth inter-depth and limit-tu all set to 4 versus 1, 1 and 0 anyway. I only really use the former as it's a buffed setting with minor performance hit.

I think the gains from increasing tu-intra and inter-depth are probably only really seen without using limit-tu. But the speed decrease is pretty severe then.

I don't really understand them to be perfectly honest lol. But I have found instances where tu-intra and tu-inter being set to 4, with limit-tu 0, causes grain freezing and huge blocks on flat textures. It spooked me so I've dodged them since.

[fauxreaper]

Without limit-tu, higher values of tu-intra and tu-inter only increase compression, not visual quality. limit-tu 1 + tu-inter 4 + tu-intra 4 should give better quality than using limit-tu 0.

[markiemarcus]

Without limit-tu, higher values of tu-intra and tu-inter only increase compression, not visual quality. limit-tu 1 + tu-inter 4 + tu-intra 4 should give better quality than using limit-tu 0.

That makes sense. I've also observed less severe versions of the issue with limit-tu 4 + tu-inter 4 + tu-intra 4. Would limit-tu 1 + tu-inter 4 + tu-intra 4 be higher quality?

Edit: Nope. After some more testing I prefer the results with limit-tu 4 + tu-inter 3 + tu-intra 3.

[vpupkind]

...

I use rdLevel 4 and almost exclusively --limit-refs 1. If the performance impact weren't so dramatic, I'd use rdLevel 6. It's just better, there's no getting around that, but it is awfully slow.



Try --dynamic-rd, it typically provides a pretty decent quality boost over rd-level=4

[markiemarcus]

Try --dynamic-rd, it typically provides a pretty decent quality boost over rd-level=4

Cheers for the suggestion. How would one go about using this reliably in CRF mode? Seems to rely on VBV.

[l00t]

Try --dynamic-rd, it typically provides a pretty decent quality boost over rd-level=4

Over? According to the manual it should be helpful at 4 and below...

--dynamic-rd <0..4>
Increases the RD level at points where quality drops due to VBV rate control enforcement. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.

[markiemarcus]

Over? According to the manual it should be helpful at 4 and below...

"By comparison to" I assume.

[Yanak]

Hi,
answering to myself about this (https://forum.doom9.org/showthread.php?p=1892638#post1892638), apparently the problem is there since a while now :

Found out this
https://bitbucket.org/multicoreware/x265/issues/487/errors-in-asm-primitivescpp-when-using
It fixes the cli if you make it with a single lib, but trying to make a multilib exe you end up with this :
https://bitbucket.org/multicoreware/x265/issues/488/error-lnk2005-__intel_cpu_indicator_init

Then in the end i found the full fix needed for the code, it's this :
https://github.com/msg7086/x265-Yuuki-Asuna/commit/5a62786ae6d479d72c4b605fbb35c659d71beac9

Multilib 8+10+12Bit compiles correctly now with ICC 1910 from latest Intel System Studio 2020 integrated in VS2019 .

Posting it in case it helps someone else, spent a few days banging my head on this thing...

[vpupkind]

Over? According to the manual it should be helpful at 4 and below...

Quality-wise, it can give you (combined with rd-level=4) quality improvement getting you closer to rd-level=6 performance.

We've seen 3% BD-SSIM improvement from using it.

[Boulder]

Quality-wise, it can give you (combined with rd-level=4) quality improvement getting you closer to rd-level=6 performance.

We've seen 3% BD-SSIM improvement from using it.

According to the manual, it applies only to VBV capped encodes in special situations in the material. I think quite many of us don't use VBV constraints in personal encodes.

[Barough]

x265 v3.2+22-a8a2c4c37267 (http://www.mediafire.com/file/6mb2m4dabqsjpni/x265-3.2%252B22-a8a2c4c37267_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[alexantr]

Did anybody notice enabled b-intra makes more blur artifacts in motion?

[bjoker]

Hi,

I'm basically into CLI stuff. I have no issues running ffmpeg with x265 10-bit using CRF with any x265 parameter value but can't figure out 2-pass encoding which fails in the 2nd pass. Could any one please guide me where I am doing wrong? @Selur please

Microsoft Windows [Version 10.0.18362.535]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\admin\Desktop\REMUX>ffmpeg -y -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -x265-params "pass=1:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 NUL
ffmpeg version git-2019-12-19-99f505d Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9.2.1 (GCC) 20191125
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
libavutil 56. 36.101 / 56. 36.101
libavcodec 58. 65.100 / 58. 65.100
libavformat 58. 35.101 / 58. 35.101
libavdevice 58. 9.101 / 58. 9.101
libavfilter 7. 69.101 / 7. 69.101
libswscale 5. 6.100 / 5. 6.100
libswresample 3. 6.100 / 3. 6.100
libpostproc 55. 6.100 / 55. 6.100
[matroska,webm @ 0000015de81d9d80] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 0000015de81d9d80] Could not find codec parameters for stream 3 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 0000015de81d9d80] Could not find codec parameters for stream 4 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, matroska,webm, from 'Testing-1min.mkv':
Metadata:
title : testing clip
encoder : libebml v1.3.9 + libmatroska v1.5.2
creation_time : 2019-12-18T23:24:19.000000Z
Duration: 00:01:00.02, start: 0.000000, bitrate: 23880 kb/s
Chapter #0:0: start 0.000000, end 12.012208
Metadata:
title : Chapter 09
Chapter #0:1: start 12.012208, end 60.008000
Metadata:
title : Chapter 10
Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc
Metadata:
BPS-eng : 22031553
DURATION-eng : 00:00:59.977000000
NUMBER_OF_FRAMES-eng: 1438
NUMBER_OF_BYTES-eng: 165173310
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:1(por): Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s16p (default)
Metadata:
title : Surround 5.1
BPS-eng : 1787265
DURATION-eng : 00:01:00.011000000
NUMBER_OF_FRAMES-eng: 5626
NUMBER_OF_BYTES-eng: 13406948
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:2(eng): Subtitle: hdmv_pgs_subtitle (default)
Metadata:
BPS-eng : 55145
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 382812
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:3(chi): Subtitle: hdmv_pgs_subtitle
Metadata:
BPS-eng : 40979
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 284474
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:4(chi): Subtitle: hdmv_pgs_subtitle
Metadata:
BPS-eng : 42596
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 295697
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> hevc (libx265))
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool 0 using 32 threads on numa nodes 0
x265 [info]: Slices : 1
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 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 25 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 4 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-5000 kbps / 0.60
x265 [info]: tools: rect limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: rskip signhide tmvp strong-intra-smoothing lslices=4
x265 [info]: tools: deblock stats-write
Output #0, mp4, to 'NUL':
Metadata:
title : testing clip
encoder : Lavf58.35.101
Chapter #0:0: start 0.000000, end 12.012208
Metadata:
title : Chapter 09
Chapter #0:1: start 12.012208, end 60.008000
Metadata:
title : Chapter 10
Stream #0:0(eng): Video: hevc (libx265) (hev1 / 0x31766568), yuv420p10le, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 5000 kb/s, 23.98 fps, 24k tbn, 23.98 tbc
Metadata:
BPS-eng : 22031553
DURATION-eng : 00:00:59.977000000
NUMBER_OF_FRAMES-eng: 1438
NUMBER_OF_BYTES-eng: 165173310
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
encoder : Lavc58.65.100 libx265
Side data:
cpb: bitrate max/min/avg: 0/0/5000000 buffer size: 0 vbv_delay: N/A
frame= 1438 fps=9.9 q=-0.0 Lsize= 38964kB time=00:00:59.85 bitrate=5333.1kbits/s speed=0.412x
video:38945kB audio:0kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: 0.050550%
x265 [info]: frame I: 12, Avg QP:19.99 kb/s: 27830.30
x265 [info]: frame P: 268, Avg QP:20.89 kb/s: 16318.63
x265 [info]: frame B: 1158, Avg QP:26.00 kb/s: 2539.48
x265 [info]: Weighted P-Frames: Y:0.4% UV:0.4%
x265 [info]: consecutive B-frames: 4.3% 0.7% 2.1% 52.9% 5.0% 6.1% 5.0% 21.8% 2.1%

encoded 1438 frames in 145.06s (9.91 fps), 5318.55 kb/s, Avg QP:25.00

C:\Users\admin\Desktop\REMUX>ffmpeg -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -x265-params "pass=2:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 Testing-1min-2pass.mp4
ffmpeg version git-2019-12-19-99f505d Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9.2.1 (GCC) 20191125
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
libavutil 56. 36.101 / 56. 36.101
libavcodec 58. 65.100 / 58. 65.100
libavformat 58. 35.101 / 58. 35.101
libavdevice 58. 9.101 / 58. 9.101
libavfilter 7. 69.101 / 7. 69.101
libswscale 5. 6.100 / 5. 6.100
libswresample 3. 6.100 / 3. 6.100
libpostproc 55. 6.100 / 55. 6.100
[matroska,webm @ 00000198d82d9cc0] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 00000198d82d9cc0] Could not find codec parameters for stream 3 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 00000198d82d9cc0] Could not find codec parameters for stream 4 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, matroska,webm, from 'Testing-1min.mkv':
Metadata:
title : testing clip
encoder : libebml v1.3.9 + libmatroska v1.5.2
creation_time : 2019-12-18T23:24:19.000000Z
Duration: 00:01:00.02, start: 0.000000, bitrate: 23880 kb/s
Chapter #0:0: start 0.000000, end 12.012208
Metadata:
title : Chapter 09
Chapter #0:1: start 12.012208, end 60.008000
Metadata:
title : Chapter 10
Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc
Metadata:
BPS-eng : 22031553
DURATION-eng : 00:00:59.977000000
NUMBER_OF_FRAMES-eng: 1438
NUMBER_OF_BYTES-eng: 165173310
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:1(por): Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s16p (default)
Metadata:
title : Surround 5.1
BPS-eng : 1787265
DURATION-eng : 00:01:00.011000000
NUMBER_OF_FRAMES-eng: 5626
NUMBER_OF_BYTES-eng: 13406948
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:2(eng): Subtitle: hdmv_pgs_subtitle (default)
Metadata:
BPS-eng : 55145
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 382812
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:3(chi): Subtitle: hdmv_pgs_subtitle
Metadata:
BPS-eng : 40979
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 284474
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:4(chi): Subtitle: hdmv_pgs_subtitle
Metadata:
BPS-eng : 42596
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 295697
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> hevc (libx265))
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool 0 using 32 threads on numa nodes 0
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [error]: different scenecut setting than first pass (40 vs 40)
[libx265 @ 00000198d8356500] Cannot open libx265 encoder.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!

C:\Users\admin\Desktop\REMUX>

[Selur]

try '-pix_fmt yuv420p10le -strict -1' instead of just '-pix_fmt yuv420p10le'

[bjoker]

try '-pix_fmt yuv420p10le -strict -1' instead of just '-pix_fmt yuv420p10le'

Thank you Selur

Now it throws: (pasted last few lines)

x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [error]: different scenecut setting than first pass (40 vs 40)
[libx265 @ 000001bb8d550300] Cannot open libx265 encoder.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!

I ran 2 commands (for 2 passes separately) like this: (First pass goes fine but 2nd one fails)

ffmpeg -y -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -strict -1 -x265-params "pass=1:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 NUL

ffmpeg -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -strict -1 -x265-params "pass=2:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 Testing-1min-2pass.mp4

[Greenhorn]

Thank you Selur

Now it throws: (pasted last few lines)

x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [error]: different scenecut setting than first pass (40 vs 40)
[libx265 @ 000001bb8d550300] Cannot open libx265 encoder.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!

I ran 2 commands (for 2 passes separately) like this: (First pass goes fine but 2nd one fails)

ffmpeg -y -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -strict -1 -x265-params "pass=1:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 NUL

ffmpeg -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -strict -1 -x265-params "pass=2:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 Testing-1min-2pass.mp4


The "different scenecut" error is caused by a bug in x265 builds 3.2+15 through 3.2+17; selur brought it up here a couple/three weeks ago (https://forum.doom9.org/showthread.php?p=1891654#post1891654), and it should be fixed if you can upgrade to a build (in or out of FFMPEG) that's 3.2+18 or later.

[bjoker]

Thanks.
I tested an older version of ffmpeg/x265 and it worked fine.

Unfortunately the latest ffmpeg build still has x265 3.2+15. I think I will have to use external x265.
How could I pipe ffmpeg to external x265 for 2-pass please?

[Greenhorn]

I don't really know shell syntax, but what I'd normally do for standalone x265 would be convert my input files to decompressed .y4m with ffmpeg (ffmpeg -i example_input.file example_output.y4m), then convert the y4m using x265. (x265 example_output.y4m --my_settings -o example_output.hevc) You'll need enough free disk space for the whole .y4m to be stored, and the output will be a raw HEVC stream that needs to be muxed with ffmpeg again-- although that shouldn't pose any problems, unless you've got two buggy libraries in one ffmpeg at once.

[foxyshadis]

I don't really know shell syntax, but what I'd normally do for standalone x265 would be convert my input files to decompressed .y4m with ffmpeg (ffmpeg -i example_input.file example_output.y4m), then convert the y4m using x265. (x265 example_output.y4m --my_settings -o example_output.hevc) You'll need enough free disk space for the whole .y4m to be stored, and the output will be a raw HEVC stream that needs to be muxed with ffmpeg again-- although that shouldn't pose any problems, unless you've got two buggy libraries in one ffmpeg at once.

No ginormous intermediate file needed: ffmpeg -i example_input.file -f yuv4mpegpipe -strict -2 - | x265 - -o example_output.hevc

That's going to be much faster than writing and reading to disk. The "strict -2" allows y4m to be greater than 8 bits, if necessary.

[nghiabeo20]

Does x265 have tuning for monochrome picture? And is it a good practice to convert a RGB black&white source to actual BW in an encode?

[nghiabeo20]

No ginormous intermediate file needed: ffmpeg -i example_input.file -f yuv4mpegpipe -strict -2 - | x265 - -o example_output.hevc

That's going to be much faster than writing and reading to disk. The "strict -2" allows y4m to be greater than 8 bits, if necessary.

May I explain:

ffmpeg -i example_input.file -f yuv4mpegpipe -strict -2 -

The - makes ffmpeg send output to stdout.

x265 - -o example_output.hevc

The - makes x265 receive input from stdin.

The | (pipe) connects stdout to stdin.

[SaboraPie]

why this last versions are so slow. In v3.0 or earlier versions i was encoding at 1.2fps in veryslow mode, and now it is 0.42fps. Is maybe more efficient but much slower?

[Boulder]

The presets were changed at one point. The old "veryslow" became "slower" etc.

[Atak_Snajpera]

How to correctly signal HLG with x265?
So far I'm using following command line
--colorprim bt2020 --transfer bt2020-10 --colormatrix bt2020nc --atc-sei 18
but according to x265 docs there is also another required switch


--pic-struct <integer>
Set the picture structure and emits it in the picture timing SEI message. Values in the range 0..12. See D.3.3 of the HEVC spec. for a detailed explanation. Required for HLG (Hybrid Log Gamma) signalling. Not signalled by default.


What value has to be set there? Is --pic-struct 0 correct/needed for progressive frame?

[foxyshadis]

Yes, 0 for progressive. Odd that HLG requires it. Wouldn't transfer be arib-std-b67 for HLG?

[Atak_Snajpera]

Yes, 0 for progressive. Odd that HLG requires it. Wouldn't transfer be arib-std-b67 for HLG?

Mediainfo detects both so I'm not sure if arib-std-b67 is required...

--transfer bt2020-10
Transfer characteristics : HLG / BT.2020 (10-bit)

--transfer arib-std-b67
Transfer characteristics : HLG / HLG

[FranceBB]

This is the command line of an HLG encode I've done recently:

--colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18

I've never used --pic-struct, but the file has been recognized as an HLG one anyway.

But... Atak_Snajpera made it popping back up in my mind by asking about it, so... should I include --pic-struct 0 as well?

[excellentswordfight]

This is the command line of an HLG encode I've done recently:

--colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18

I've never used --pic-struct, but the file has been recognized as an HLG one anyway.

But... Atak_Snajpera made it popping back up in my mind by asking about it, so... should I include --pic-struct 0 as well?
Mediainfo detects both so I'm not sure if arib-std-b67 is required...

--transfer bt2020-10
Transfer characteristics : HLG / BT.2020 (10-bit)

--transfer arib-std-b67
Transfer characteristics : HLG / HLG
AFIK according to the specc its recommended for HLG that the fallback transfer function should flaged in "--transfer" and the HLG transfer i.e. arib-std-b67 / 18 with the preferred/alternative transfer characteristics flag (--atc-sei).

[hevc_enocder]

hello, may I have question?

What is right scrip for zones I tried this and i alaways get an error

--zones 9277,9328,crf=15.4/9381,9742,crf=15.4/27589,27647,crf=15.4/27885,28012,crf=15.4/28091,28174,crf=15.4/28285,28368,crf=15.4/36778,36848,crf=15.4/71142,71170,crf=15.4/72038,72097,crf=15.4/72401,72422,crf=15.4/157075,157141,crf=15.4/180290,180426,crf=15.4/188329,188459,crf=15.4/199320,199359,crf=15.4/199895,199990,crf=15.4/205184,205327,crf=15.4/221411,221500,crf=15.4/222062,222108,crf=15.4/237130,243727,crf=22

So my final setting is this:
--crf 16 --output-depth 10 --level-idc 5.1 --high-tier --ref 5 --bframes 12 --rd 6 --me 3 --subme 5 --merange 32 --ipratio 1.3 --pbratio 1.2 --weightb --b-intra --hevc-aq --no-rskip --qcomp 0.60 --psy-rd 1.07 --psy-rdoq 1.00 --ctu 64 --rc-lookahead 60 --deblock -3:-3 --cbqpoffs 0 --crqpoffs 0 --qg-size 8 --no-rskip --no-rect --no-amp --no-sao --no-open-gop --no-cutree --range limited --aud --repeat-headers --zones 9277,9328,crf=15.4/9381,9742,crf=15.4/27589,27647,crf=15.4/27885,28012,crf=15.4/28091,28174,crf=15.4/28285,28368,crf=15.4/36778,36848,crf=15.4/71142,71170,crf=15.4/72038,72097,crf=15.4/72401,72422,crf=15.4/157075,157141,crf=15.4/180290,180426,crf=15.4/188329,188459,crf=15.4/199320,199359,crf=15.4/199895,199990,crf=15.4/205184,205327,crf=15.4/221411,221500,crf=15.4/222062,222108,crf=15.4/237130,243727,crf=22

please can you tell me what is wrong about it? Thank you so much.

[Boulder]

I don't think x265 supports setting CRF in zones, you need to define q instead.

[RainyDog]

hello, may I have question?

What is right scrip for zones I tried this and i alaways get an error

So my final setting is this:

please can you tell me what is wrong about it? Thank you so much.

Try replacing all instances of crf=15.4 in your script with b=1.3 (or find your preferred value instead of 1.3).

The 'b' stands for bitrate multiplier so 1.3 will increase the bitrate of the frames designated within zones by a factor of x1.3 (or +30%).

[Magik Mark]

Guys,

When encoding do you use ssim-rdo? Do you see any difference? When is the best time to use this? During 2pass perhaps? or CRF?

It takes longer when this is enabled.

[vpupkind]

I don't think x265 supports setting CRF in zones, you need to define q instead.
You can change crf (as well as some other parameters) per zone using the --zonefile option and a "sidecar file" with frame numbers and zone settings. You can change additional settings beyond crf/bitrate this way.

[vpupkind]

Guys,

When encoding do you use ssim-rdo? Do you see any difference? When is the best time to use this? During 2pass perhaps? or CRF?

It takes longer when this is enabled.
It is heavy but is totally worth it, IMO. We've seen meaningful quality improvements.

[microchip8]

It is heavy but is totally worth it, IMO. We've seen meaningful quality improvements.

From my testing, it produces worse results in dark, mostly clean frames with a little of mosquito noise. Tested on Blade Runner 2049 starting from 6:00 minutes

[Greenhorn]

Oddly, enabling ssim-rd by itself will disable psy-rd, but if you manually specify both they'll both be used.