A better compromise between medium and slow preset

[benwaggoner]

Have you tried using a better motion estimation for HME instead of hex? I personally use umh,umh,star
For this quality/perf range and for stars (or other particle-effect like small independently moving details), I wonder if something like this might be a good balance:

--hme --hme-range 16,32,32 --hme-search hex,umh,star

The coarser ME passes should pick up on the stars, with the last stage really only for refinement. A smaller, more exhaustive search could help quite a bit to get the 1/8th pel optimal.

I've not really tested this personally, however.

[benwaggoner]

Just a thought: would --rdpenalty 1 help here to push for smaller TUs?
Maybe? That was a sometimes-useful parameter for x265 in 2014-2015, but I've not heard of it being used in the last five years.

[tonemapped]

I find the built-in presets to be flawed. That's why I always use my own settings. Crispy sharp, no banding, no blocking, noise preservation, etc

If you were going to change the current Medium presets to reflect the maturity of x265, what would you change? Personally, I'd change (from the defaults):

-rskip-edge-threshold 4
--psy-rd 2.10
--psy-rdoq 1.1
--rskip 2
--me umh
--rc-lookahead 30 (or 25)

Based on testing on a slow CPU (Skylake-era Xeon 4C/4T), the penalty is ~6% increased time but retaining much more detail and better detail in moving scenes.

[benwaggoner]

If you were going to change the current Medium presets to reflect the maturity of x265, what would you change? Personally, I'd change (from the defaults):

-rskip-edge-threshold 4
--psy-rd 2.10
--psy-rdoq 1.1
--rskip 2
--me umh
--rc-lookahead 30 (or 25)

Based on testing on a slow CPU (Skylake-era Xeon 4C/4T), the penalty is ~6% increased time but retaining much more detail and better detail in moving scenes.
It's content dependent of course, but those seem like some good options.

The x265 presets haven't bee refactored in several years now, and don't include a lot of features that would help.

--selective-sao 2 is an essentially free speedup, for example, and should be default in every preset except maybe placebo. And even placebo could use --selective-sao 3. (SAO does very little for bidirectional prediction or non-reference frames).

--dynamic-refine is a great quality/speed feature for VBV-limited encodes, as it cranks up complexity when quality is VBV-limited, and then lets it drop down where the CRF quality can be met. Encoding time will vary with source more, but it averages out to a good quality/speed win by spending more cycles just where it improves quality.

[Boulder]

Which areas of the frame should be affected by --selective-sao 2 compared to --selective-sao 0? I just did a quick test regarding filesize and at the same CRF, the filesize for 0 was 2651 kbps / avg QP 18.23 while for 2 they were 2926.94 / 17.86 and based on the stats, the QPs for P-frames were substantially lower. I-frames pretty much the same for both versions.

EDIT: it's also odd that --selective-sao 2 is faster even though it produces a bigger file and should require more computation than no SAO at all.

[benwaggoner]

Which areas of the frame should be affected by --selective-sao 2 compared to --selective-sao 0? I just did a quick test regarding filesize and at the same CRF, the filesize for 0 was 2651 kbps / avg QP 18.23 while for 2 they were 2926.94 / 17.86 and based on the stats, the QPs for P-frames were substantially lower. I-frames pretty much the same for both versions.

EDIT: it's also odd that --selective-sao 2 is faster even though it produces a bigger file and should require more computation than no SAO at all.
That is a concerning result! --selective-sao should have a <1% impact on file size and QP. You should file an issue with MCW.

[PatchWorKs]

Question: do you think is possible to perform only the 1st pass with hw accelleration (qsv) in order to speedup the whole encode ?

Thanks !

[rwill]

Do you think it is possible to perform the 1st pass with x264 ?

[benwaggoner]

Do you think it is possible to perform the 1st pass with x264 ?
You can import a x264 encode as data to refine, but I've never tried it.

Tweaking a faster firstpass with x265 is probably going to give better speed/performance. x265 defaults to --no-slow-firstpass to avoid 1/2nd pass mismatches. But IIRC, as long as you use the same --ref and --bframes between passes, you can speed up --me, add a bunch of early-exit options, etcetera. It's been years since I've tried it, but with some testing I'm sure compatible yet faster 1st pass settings can be determined.