x265 HEVC Encoder

[Boulder]

I'm thinking about a memory upgrade for my systems.

Does anyone know if bandwidth or latency has an impact on x265 performance, if any at all, on AMD machines?
On x265, the difference is very small if it's even measurable. It's good to just have enough memory, I've seen 4K sources use up to 16GB for Avisynth+ and x265 depending on the script.

With Zen2 at least, you'll want to have the IF and memory speed match. In that sense, a 3600MHz kit should be the best bang for buck.

[LeXXuz]

Thanks for your input guys. :)

[_kermit]

I've encoded a few UHD movies using wrong parameters.
Instead of providing the proper values for mastering display luminance, like:

Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 4000 cd/m2
Maximum Frame-Average Light Level : 1391 cd/m2

instead of:
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 4000 cd/m2
Maximum Frame-Average Light Level : 1391 cd/m2

Are those values always used directly in the encoding process, hence I have to redo them or are those properties I could somehow set properly?

cheers

[benwaggoner]

I've encoded a few UHD movies using wrong parameters.
Instead of providing the proper values for mastering display luminance, like:

Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 4000 cd/m2
Maximum Frame-Average Light Level : 1391 cd/m2

instead of:
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 4000 cd/m2
Maximum Frame-Average Light Level : 1391 cd/m2

Are those values always used directly in the encoding process, hence I have to redo them or are those properties I could somehow set properly?

Those values are pure metadata, and don't impact how the video is encoded at all. The only impact would be if a display used the mastering_display metadata to change how it tone maps.

AFAIK, no displays use mastering_display anyway, so I doubt there would be any impact from your only somewhat incorrect values. MaxCLL is the only one that gets used much, and even then only on some TVs (LG in particular).

A tool could just "remux" the current encode and replace the metadata SEI messages with the correct ones without actual reencoding. Maybe ffmpeg? But you're safe to just ignore the issue entirely, as you got the important metadata right.

[Asmodian]

AFAIK, no displays use mastering_display anyway, so I doubt there would be any impact from your only somewhat incorrect values.

And now they will never be able to, since there are too many files in the wild with bad metadata. :scared: ;)

[benwaggoner]

And now they will never be able to, since there are too many files in the wild with bad metadata. :scared: ;)
Yeah, it was a mistake to make master_display mandatory. MaxCLL and MaxFALL are optional (setting to 0 is undefined). But everything has to have master_display, so if it isn't known, some random example gets pasted in or set to a default.

Of course in those early days of HDR, we didn't really know what metadata we needed or how it could be used. Turns out that the metadata we really wanted was dynamic metadata.

[_kermit]

Those values are pure metadata, and don't impact how the video is encoded at all. The only impact would be if a display used the mastering_display metadata to change how it tone maps.

AFAIK, no displays use mastering_display anyway, so I doubt there would be any impact from your only somewhat incorrect values. MaxCLL is the only one that gets used much, and even then only on some TVs (LG in particular).

A tool could just "remux" the current encode and replace the metadata SEI messages with the correct ones without actual reencoding. Maybe ffmpeg? But you're safe to just ignore the issue entirely, as you got the important metadata right.

I've confirmed that even my Video Processor only utilizes MaxCLL, so that means I don't have to re-encode or even update some metadata, I guess.
That's great.

thanks!

[benwaggoner]

I've confirmed that even my Video Processor only utilizes MaxCLL, so that means I don't have to re-encode or even update some metadata, I guess.
That's great.
Yep. AFAIK only MaxCLL is ever used for anything, and only on some devices.

[_kermit]

Yep. AFAIK only MaxCLL is ever used for anything, and only on some devices.

as it turns out, not that easy.
Quote from the processor vendor:

"I should have noted that the Radiance Pro also uses the Mastering Monitor Max to limit the MaxCLL to no more than the Mastering Monitor Maximum reported in the HDR10 Metadata.

One example of why is Mad Max Fury Road. It was mastered on a 4000 nit monitor, but has a specified MaxCLL around 9900 (if my memory serves on this). On a 4000 nit monitor anything above 4000 nits would be clamped to the maximum the monitor can reproduce. Nothing over 4000 nits would have been seen in Post Production. So there is no reason to set any scene maximum higher than the Mastering Monitor Maximum.

While we have seen a lot of content where MaxCLL is wrong, as I recall, when reported (so not 0 which would be ignored by the Pro), the Max Mon Metadata has been correct."

Hence this:
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 1655 cd/m2
Maximum Frame-Average Light Level : 117 cd/m2

which I've encoded using 0.0001 and 1000 instead

would also result in 1000 max for CLL :(

This might be the solution though:
https://github.com/YouTubeHDR/hdr_metadata

a custom solution to update that, and not just the header at the beginning, it goes through the whole file, resulting in this, using just some random values.

mkvmerge.exe -o output.mkv --min-luminance 0:0.0001 --max-luminance 0:2000 input.mkv

took a few minutes on an SSD, which resulted in that:

Mastering display luminance: min: 0.0001 cd/m2, max: 2000 cd/m2
MasteringDisplay_Luminance_Original: min: 0.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level: 1000 cd/m2
Maximum Frame-Average Light Level: 293 cd/m2

so, it updated "Mastering display luminance" and made a "backup" entry.

I'm testing this on the processor and if it reports the correct values, I think this should be fine.
Still assuming the values don't play a role during encoding, that they are just written into the stream.

EDIT

Is there a database with that HDR-metadata for movies?


----

It's not working.
While I get the proper values, the processor still reports the old ones.

I've tried the other tool which provides even better values (without "original")

Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 162 cd/m2

Still, I get the old ones reported from the video processor

Can the old values still be embedded in the stream? They must be..
Does anyone have ideas?




SEI_rbsp_stop_one_bit : Missing

[_kermit]

can x265 be brought to re-encode without actually re-encoding?
Basically, process the file, create a new one, but copy everything?

Meant as a solution for my problem with wrong metadata.
The only thing it needs to do is to not "encode/analyze" but update the metadata while doing so.

[benwaggoner]

can x265 be brought to re-encode without actually re-encoding?
Basically, process the file, create a new one, but copy everything?

Meant as a solution for my problem with wrong metadata.
The only thing it needs to do is to not "encode/analyze" but update the metadata while doing so.
x265 vanilla can't do this, but could probably be hacked to. Tools like mp4box or ffmpeg are more commonly used for this kind of muxing-like stuff.

[MrVideo]

Before I go digging into x265, does it support AVISynth (AVISynth+) script file input like x264? I'm set up on my Win7 box to use AVIsynth, not the "+" version.

Also is there a good "how to" out there? I have the readdocs PDF, but that is a command reference, not a nice training tool.

[LigH]

Vanilla x265 without modifications does not support AviSynth scripts or encoded media files as inputs, only raw video files (with or without YUV4MPEG header).

There are modified builds (DJATOM or Yuuki-Asuna) which include AviSynth and libav input modules.

I don't know any detailed guide. But the best advice I can give is: Start with presets and tunings only; do not use extreme presets instead of convenient bitrate, there are no miracles.

It is not important at the moment to insist in the very latest builds, as there are little changes for Windows PC users during the last few months. A version around 3.3-3.4 is fine.

[filler56789]

Before I go digging into x265, does it support AVISynth (AVISynth+) script file input like x264? I'm set up on my Win7 box to use AVIsynth, not the "+" version.

The "normal" builds of x265.exe support Avisynth scripts only indirectly, through command-line programs like avs2yuv and avs2pipe(mod).

[MrVideo]

Thanks for the info guys.

[_kermit]

x265 vanilla can't do this, but could probably be hacked to. Tools like mp4box or ffmpeg are more commonly used for this kind of muxing-like stuff.

I've tested with ffmpeg, that seems to do the trick.

[tonemapped]

The biggest issue with x265 is is that the most capable people left a long time ago and even patch validation has had issues with features getting worse with development.

Is this the general consensus? If so, how incredibly disappointing.

[Gravitator]

I am looking for x265 maximum setting to get closer to the quality of AOM (above placebo).
Download the encoded sample & orig (size 6.4MB) > AOM (https://files.videohelp.com/u/227452/AOM.rar) (1Mbps/10bit was applied and the maximum preset was simplified by lowering the blocks from 128 to 64 - like in x265 ;)).

[Selur]

How to encode to 12 bit?
Using ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -ignore_editlist true -i "G:\TestClips&Co\files\ProRes\Test Patterns Resolve 4444 12-bit.mov" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p12le -strict -1 -vsync 0 -f yuv4mpegpipe - | x265 --input - --output-depth 12 --y4m --profile main444-12 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --output "E:\Temp\2021-07-26@05_29_19_2410_01.265"
seems to feed 12bit to the encoder.
But looking at the output with MediaInfo it reports:
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L3@Main
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 600 ms
Bit rate : 96.5 kb/s
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.009
Stream size : 7.07 KiB (85%)
Title : Core Media Video
Writing library : x265 3.5+10-82786fccc:[Windows][GCC 10.3.0][64 bit] 10bit
Encoding settings : cpuid=1111039 / frame-threads=5 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=720x576 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-eob / no-eos / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=0 / limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.50 / psy-rdoq=10.00 / no-rd-refine / no-lossless / cbqpoffs=-2 / crqpoffs=-2 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=0.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=59:54 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Encoded date : UTC 2021-07-26 03:52:24
Tagged date : UTC 2021-07-26 03:52:24
Color range : Limited
Matrix coefficients : BT.709
Codec configuration box : hvcC
Looking a 'x265 --help' it properly shows:
x265 [info]: HEVC encoder version 3.5+10-82786fccc
x265 [info]: build info [Windows][GCC 10.3.0][64 bit] 8bit+10bit+12bit

Is this a bug or am I missing something?

Cu Selur

[filler56789]

@Selur:

MAYBE you should a try a diferent version of MediaInfo? :confused:
(mine is 19.07)

OR/and......

try an old version of x265? :confused:
(mine is 3.4+7-g38774073d)

[Selur]

WTF,... I restarted my machine and when I run the same command now the output is reported as:
Format/Info : High Efficiency Video Coding
Format profile : Format Range@L3@Main
with:
Writing library : x265 3.5+10-82786fccc:[Windows][GCC 10.3.0][64 bit] 12bit
I don't get it how this could change,... but okay, since I can't reproduce the issue anymore it seems to have fixed itself. (cosmic rays?)

Thanks anyways.

Cu Selur

[benwaggoner]

I am looking for x265 maximum setting to get closer to the quality of AOM (above placebo).
Download the encoded sample & orig (size 6.4MB) > AOM (https://files.videohelp.com/u/227452/AOM.rar) (1Mbps/10bit was applied and the maximum preset was simplified by lowering the blocks from 128 to 64 - like in x265 ;)).
They are different codecs, and AV1 has some tools HEVC doesn't. There will be cases where x265 can't match AV1. Beamr's HEVC encoder seems to handle the scenarios where libaom > x265 well.

If you want to through MIPS at the wall, here's some "try everything" ultraplacebo values, to include in a 3-pass encode.

--profile main10 --preset placebo --no-wpp --pmode --subme 7 --bframes 16 --tskip --cu-lossless --rd-refine --multi-pass-opt-analysis --multi-pass-opt-distortion --opt-qp-pps --opt-ref-list-length-pps --multi-pass-opt-rps --opt-cu-delta-qp

It'd be glacially slow and probably <5% better than placebo for typical film/video content. Clean animation, CGI, and motion graphics could benefit a lot more. The less noise, the greater compression potential and the more extreme settings can benefit.

The source seems a good fit for x265 and HEVC in general. Can you share your current command line and output?

[tonemapped]

Beamr's HEVC encoder seems to handle the scenarios where libaom > x265 well.

Any idea on the cost for a single-user, non-commercial licence? I've looked through the company's website, but I'm guessing it's a case of 'if you have to ask, you can't afford it' 😋

[benwaggoner]

Any idea on the cost for a single-user, non-commercial licence? I've looked through the company's website, but I'm guessing it's a case of 'if you have to ask, you can't afford it' 😋
I believe they were working on ways to make it available for noncommercial use, but haven't checked in on that recently.

COVID-19's disruption of all the trade shows has left me less on top of the industry than I'm used to.

[tonemapped]

I believe they were working on ways to make it available for noncommercial use, but haven't checked in on that recently.

COVID-19's disruption of all the trade shows has left me less on top of the industry than I'm used to.

Thank you for replying. It looks like a fascinating plugin

[benwaggoner]

Say, what are folks' experiences with --lookahead-threads? I don't recall much or any discussion of this feature added back in 2.3

--lookahead-threads <integer>
Use multiple worker threads dedicated to doing only lookahead instead of sharing the worker threads with frame Encoders. A dedicated lookahead threadpool is created with the specified number of worker threads. This can range from 0 upto half the hardware threads available for encoding. Using too many threads for lookahead can starve resources for frame Encoder and can harm performance. Default is 0 - disabled, Lookahead shares worker threads with other FrameEncoders .
Values: 0 - disabled(default). Max - Half of available hardware threads.

For "ultraplacebo" encoding without frame threading it sounds like a potentially useful tool to take advantage of more cores. I've kicked off a test encode, and it does appear to improve --preset placebo speed some.

Anyone tried it or have any thoughts on it?

[tonemapped]

Say, what are folks' experiences with --lookahead-threads? I don't recall much or any discussion of this feature added back in 2.3



For "ultraplacebo" encoding without frame threading it sounds like a potentially useful tool to take advantage of more cores. I've kicked off a test encode, and it does appear to improve --preset placebo speed some.

Anyone tried it or have any thoughts on it?

I tried it on lower-end hardware (my 4C/4T Xeon) and more reasonable hardware (workstation with 8700K and 9700K). Setting it to 2, it seemed to slow down all encodes. I suppose that's to be expected - what's the C/T count of the CPU you use for testing?

[benwaggoner]

I tried it on lower-end hardware (my 4C/4T Xeon) and more reasonable hardware (workstation with 8700K and 9700K). Setting it to 2, it seemed to slow down all encodes. I suppose that's to be expected - what's the C/T count of the CPU you use for testing?
2x18/36, with most cores unused for this encode.

[benwaggoner]

I am looking for x265 maximum setting to get closer to the quality of AOM (above placebo).
Download the encoded sample & orig (size 6.4MB) > AOM (https://files.videohelp.com/u/227452/AOM.rar) (1Mbps/10bit was applied and the maximum preset was simplified by lowering the blocks from 128 to 64 - like in x265 ;)).
That was a thorny clip for x265. It's quite short so it encodes in a single GOP, so rate control isn't great. I had to use a qpfile to set the IDR QP lower to get reasonable quality.

The reflection on the upper right of the solar panel is also quite challenging for adaptive quantization.

Here's the best I could do throwing a bunch of MIPS at it: https://1drv.ms/v/s!AlvIQZWsyeO-k9scZ-4jLg_MNpsqTA?e=68IRmr

[guest]

I have been trying / testing different x265 builds to see if the optimized AVX & AVX2 builds make any difference to encoding times.

Please check here, for my basic findings :-

https://forum.doom9.org/showthread.php?p=1948617#post1948617

Any comments would be more than welcome.

Cheers

[Barough]

x265 v3.5+11-c8905a7450 (https://www.mediafire.com/file/g0cqgbbsg4ywrkb/x265-3.5%252B11-c8905a745_Win_GCC103.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.3.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[charliebaby]

x265 v3.5+11-c8905a7450 (https://www.mediafire.com/file/dlimoxr9z9lc6n1/x265-3.5%252B9-bf91444e0_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.3.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master


this 3.5.9 not 3.5.11

[Gravitator]

Here's the best I could do throwing a bunch of MIPS at it: https://1drv.ms/v/s!AlvIQZWsyeO-k9scZ-4jLg_MNpsqTA?e=68IRmr
Your quality is terrible!:eek:
Here are my > results (https://files.videohelp.com/u/227452/x265%20%28rskip0_rskip2%29.rar)

[Barough]

this 3.5.9 not 3.5.11

Fixed now. Thnx for the headsup. :)

[charliebaby]

Fixed now. Thnx for the headsup. :)

tk you :-)

[DJATOM]

Your quality is terrible!:eek:
Here are my > results (https://files.videohelp.com/u/227452/x265%20%28rskip0_rskip2%29.rar)

I think yours not ideal too. I'm noticing slight blurring on reflector (or whatever it is), while original sample look transparent to me.

[Gravitator]

I think yours not ideal too. I'm noticing slight blurring on reflector (or whatever it is), while original sample look transparent to me.
Can you try to improve it? Your processor should quickly iterate through the settings. Slightly falls short of AOM quality. :rolleyes:

[DJATOM]

https://easyupload.io/djss6b | password: x265
I think going beyond crf 19 is bad and leads to blurred spots on reflector. I tried to optimize quantization by adjusting qp-adaptation-range and qcomp, It doesn't help much. Also I made few experiments with psy-rd, 1.7 looks sane for that sample.

[Gravitator]

https://easyupload.io/djss6b | password: x265
I think going beyond crf 19 is bad and leads to blurred spots on reflector.
The task was to keep within 1Mbps.

[DJATOM]

>The task was to keep within 1Mbps.
I somehow missed that. With such low bitrate the quality indeed suffers and washed details are inevitable.

[benwaggoner]

Your quality is terrible!:eek:
Here are my > results (https://files.videohelp.com/u/227452/x265%20%28rskip0_rskip2%29.rar)
Yeah, I was experimenting with what "throwing MIPS at it" could do more than any clip-specific settings.

What are the settings you used for the rskip 0/2 clips?

[benwaggoner]

this 3.5.9 not 3.5.11
I get
C:\Users\benwagg>C:\Users\benwagg\Desktop\x265\x265.exe --version
x265 [info]: HEVC encoder version 3.5+11-c8905a745
x265 [info]: build info [Windows][GCC 10.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
Biggest recent change in MASTER appears to be improvements in --hist-scenecut. And --hist-scenecut has been made the default? I'll have to test to confirm.

New text:
+ option:`--hist-scenecut` enables scenecut detection using the histograms.
+ It also uses the intra and inter cost info to arrive at a scenecut decision from the default scenecut method.

+ /* Flag to turn on/off traditional scenecut detection in histogram based scenecut detection.
+ * When false, only spatial properties are used for scenecut detection. Default true */
+ int bEnableTradScdInHscd;

[Boulder]

I hope they didn't screw up and make --hist-scenecut a default option. It's broken - the old method is not perfect and seems it's impossible to tune at all to catch scene changes better, but it's still the better option.

[Gravitator]

Yeah, I was experimenting with what "throwing MIPS at it" could do more than any clip-specific settings.

What are the settings you used for the rskip 0/2 clips?
R0
x265 --frame-threads 0 --wpp --no-pmode --no-pme --log-level 2 --input - --output-depth 10 --y4m --profile main10 --high-tier --min-cu-size 8 --ctu 64 --qg-size 64 --opt-cu-delta-qp --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 0 --max-tu-size 32 --hme --hme-search star,star,star --hme-range 16,32,48 --subme 4 --merange 57 --no-analyze-src-pics --no-limit-modes --rect --amp --max-merge 2 --no-early-skip --rskip 0 --temporal-mvp --rdpenalty 0 --tskip --no-tskip-fast --strong-intra-smoothing --no-constrained-intra --open-gop --gop-lookahead 0 --opt-ref-list-length-pps --keyint 250 --min-keyint 0 --max-ausize-factor 1 --radl 0 --bframes 6 --no-weightb --no-b-intra --bframe-bias 0 --b-adapt 2 --b-pyramid --ref 4 --weightp --rc-lookahead 150 --slices 1 --lookahead-threads 0 --qpstep 4 --qpmin 0 --qpmax 69 --qblur 0.50 --cplxblur 20.0 --bitrate 1100 --crf-min 0.00 --crf-max 0.00 --no-strict-cbr --no-opt-qp-pps --no-rc-grain --cbqpoffs 0 --crqpoffs 0 --ipratio 1.40 --pbratio 1.30 --nr-intra 0 --nr-inter 0 --qpfile GENERATED_QP_FILE --limit-refs 0 --rd 5 --no-fast-intra --no-ssim-rd --no-rd-refine --psy-rd 1.00 --rdoq-level 1 --psy-rdoq 10.00 --signhide --no-splitrd-skip --qcomp 0.60 --qp-adaptation-range 1 --no-aq-motion --aq-mode 2 --aq-strength 2 --cutree --no-cu-lossless --no-const-vbv --vbv-maxrate 0 --vbv-bufsize 0 --vbv-init 0.90 --vbv-end 0.000 --min-vbv-fullness 50.00 --max-vbv-fullness 80.00 --no-hrd --no-aud --info --no-idr-recovery-sei --deblock=0:0 --sao --selective-sao 4 --no-sao-non-deblock --no-limit-sao --repeat-headers --no-temporal-layers --log2-max-poc-lsb 8 --no-fades --psnr --no-ssim --no-interlace --range limited --colormatrix bt709 --no-single-sei --no-hdr10 --output OUTPUTFILE

R2
x265 --frame-threads 0 --wpp --no-pmode --no-pme --log-level 2 --input - --output-depth 10 --y4m --profile main10 --high-tier --min-cu-size 8 --ctu 32 --qg-size 32 --opt-cu-delta-qp --tu-intra-depth 4 --tu-inter-depth 4 --limit-tu 0 --max-tu-size 32 --hme --hme-search hex,umh,star --hme-range 16,32,48 --subme 4 --merange 57 --no-analyze-src-pics --no-limit-modes --rect --no-amp --max-merge 5 --no-early-skip --rskip 2 --rskip-edge-threshold 1 --temporal-mvp --rdpenalty 0 --tskip --no-tskip-fast --strong-intra-smoothing --no-constrained-intra --open-gop --gop-lookahead 0 --opt-ref-list-length-pps --keyint 250 --min-keyint 0 --max-ausize-factor 1 --radl 0 --bframes 6 --no-weightb --no-b-intra --bframe-bias 0 --b-adapt 2 --b-pyramid --ref 4 --weightp --rc-lookahead 150 --slices 1 --lookahead-threads 0 --lookahead-slices 0 --qpstep 4 --qpmin 0 --qpmax 69 --qblur 0.50 --cplxblur 20.0 --bitrate 1100 --crf-min 0.00 --crf-max 0.00 --no-strict-cbr --no-opt-qp-pps --no-rc-grain --cbqpoffs 0 --crqpoffs 0 --ipratio 1.40 --pbratio 1.30 --nr-intra 0 --nr-inter 0 --qpfile GENERATED_QP_FILE --limit-refs 0 --rd 5 --no-fast-intra --no-ssim-rd --no-rd-refine --psy-rd 1.00 --rdoq-level 1 --psy-rdoq 10.00 --signhide --no-splitrd-skip --qcomp 0.60 --qp-adaptation-range 1 --no-aq-motion --aq-mode 2 --aq-strength 2 --cutree --cu-lossless --no-const-vbv --vbv-maxrate 0 --vbv-bufsize 0 --vbv-init 0.90 --vbv-end 0.000 --min-vbv-fullness 50.00 --max-vbv-fullness 80.00 --no-hrd --no-aud --info --no-idr-recovery-sei --deblock=0:0 --sao --selective-sao 4 --no-sao-non-deblock --no-limit-sao --repeat-headers --no-temporal-layers --log2-max-poc-lsb 8 --no-fades --psnr --no-ssim --no-interlace --range limited --colormatrix bt709 --no-single-sei --no-hdr10 --output OUTPUTFILE

[benwaggoner]

I hope they didn't screw up and make --hist-scenecut a default option. It's broken - the old method is not perfect and seems it's impossible to tune at all to catch scene changes better, but it's still the better option.
There have been other improvements in --hist-scenecut. It's odd the documentation doesn't specify which is default.

[Boulder]

There have been other improvements in --hist-scenecut. It's odd the documentation doesn't specify which is default.

Yes, but as mentioned earlier in this thread, the "improvements" broke the feature even more.

[Gravitator]

Yes, but as mentioned earlier in this thread, the "improvements" broke the feature even more.
It's like effective managers slow down old smartphones for the sake of new ones (stimulating the free market) :o

[fadedmaple]

Did some tests on ARM, x265 is not optimized for ARM or not enough.
Intel haswell 4 core without HT vs neoverse N1 4 core , compiled with GCC 9.3.0

x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

x264 [info]: using cpu capabilities: ARMv8 NEON
x265 [info]: using cpu capabilities: NEON

ffmpeg is installed from Ubuntu(20.04) packages

ffmpeg -i input.mp4 -f yuv4mpegpipe - | x264 --demuxer y4m - -o output.264
ffmpeg -i input.mp4 -f yuv4mpegpipe - | x265 --y4m - -o output.265

x264 speed Intel is 1.47X of ARM
x265 speed Intel is 2.82X of ARM

[quietvoid]

If you're interested in ARM, there is ongoing work for an arm64 port.
You can find all the patches: https://mailman.videolan.org/pipermail/x265-devel/2021-August/013370.html

The full patch is also at the end of that message.

Not sure anyone has compiled them into a build yet..

[vpupkind]

Yes, but as mentioned earlier in this thread, the "improvements" broke the feature even more.

In my understanding, the latest patch makes some of the improvements conditioned on an extra command line option.
This means you can use either "traditional"-only (the original x264 scenecut, which just looked at bit cost), or histogram-only (more-or-less the initial version of it), or a combination of the two (scenecut invoked if histogram-based method is unsure whether something is a cut or not).