x265 HEVC Encoder

[brumsky]

I was wondering where does HME currently stand? Use it, don't use?

Is it good for anime or film?

I experimented with it a bit a few months ago when it came out. It seems to take longer and I can't really tell a differences in quality. At best I was able to get a file 2.2% smaller but it was around a 50% increase in encoding time.

[stax76]

My newest GUI is for MediaInfo which supports now a presentation for encoder parameters, maybe it's useful for somebody here.

https://forum.doom9.org/showthread.php?t=176886

[microchip8]

Originally Posted by brumsky

I was wondering where does HME currently stand? Use it, don't use?

Is it good for anime or film?

I experimented with it a bit a few months ago when it came out. It seems to take longer and I can't really tell a differences in quality. At best I was able to get a file 2.2% smaller but it was around a 50% increase in encoding time.

HME shows good benefits at high resolutions. For FHD and lower, the benefit is much smaller and as you say, it has a performance hit. I only use it for anything higher that FHD resolution

[brumsky]

Originally Posted by froggy1

HME shows good benefits at high resolutions. For FHD and lower, the benefit is much smaller and as you say, it has a performance hit. I only use it for anything higher that FHD resolution

Well that's good to know! haha I've been mostly doing UHD encodes. My tests are normally done with 1080p content though... Hmmm I'll have to find a good 4K test clip.

What settings do you typically use for HME and UHD? What has your experience been with HME?

[microchip8]

Originally Posted by brumsky

Well that's good to know! haha I've been mostly doing UHD encodes. My tests are normally done with 1080p content though... Hmmm I'll have to find a good 4K test clip.

What settings do you typically use for HME and UHD? What has your experience been with HME?

For 4k I use hme=1 and hme-search=umh,umh,star. This gives pretty good quality without sacrificing performance too much. It still has a performance hit but is faster (at least here on my Core i7 7700K) than any other combinations I did excluding hex (so all possible combinations of umh and star)

[brumsky]

Originally Posted by froggy1

For 4k I use hme=1 and hme-search=umh,umh,star. This gives pretty good quality without sacrificing performance too much. It still has a performance hit but is faster (at least here on my Core i7 7700K) than any other combinations I did excluding hex (so all possible combinations of umh and star)

Do you see an improvement in quality or a reduction in file size? How much of a performance hit have you seen?

[_kermit]

Originally Posted by stax76

My newest GUI is for MediaInfo which supports now a presentation for encoder parameters, maybe it's useful for somebody here.

https://forum.doom9.org/showthread.php?t=176886

Thank you!

[microchip8]

Originally Posted by brumsky

Do you see an improvement in quality or a reduction in file size? How much of a performance hit have you seen?

Quality improvement is difficult to spot in moving frames. You have to look at stills to notice it and you won't always notice it. I was able to spot it in some stills but not in moving frames.

File size reduction here is about a few %. Performance hit is the same as for FHD here. The best compromise between speed and quality seems to be hme-search=umh,umh,star. Excluding hex/dia, other combinations don't bring noticable difference in quality while have slightly bigger performance hit.

[Blue_MiSfit]

Originally Posted by stax76

My newest GUI is for MediaInfo which supports now a presentation for encoder parameters, maybe it's useful for somebody here.

https://forum.doom9.org/showthread.php?t=176886

VERY nice!!

[stax76]

Next release will have it sorted alphabetically.

    Rate Control
        aq-mode=1 / no-aq-motion / aq-strength=1.00
        bitrate=4200 / cbqpoffs=0 / no-const-vbv
        crqpoffs=0 / cutree / ipratio=1.40 / no-lossless
        nr-inter=0 / nr-intra=0 / pbratio=1.30
        qcomp=0.60 / qg-size=32 / qpmax=69 / qpmin=0
        qpstep=4 / rc=abr / no-rc-grain / no-strict-cbr
        zone-count=0

    Analysis
        amp / analysis-reuse-level=5 / b-intra
        ctu=64 / no-cu-lossless / dynamic-rd=0.00
        no-dynamic-refine / no-early-skip / no-fast-intra
        no-hevc-aq / limit-modes / limit-refs=2
        limit-tu=4 / max-tu-size=32 / min-cu-size=8
        psy-rdoq=0.00 / qp-adaptation-range=1.00
        rd=3 / rdoq-level=2 / rdpenalty=0 / no-rd-refine
        rect / refine-ctu-distortion=0 / refine-inter=0
        refine-intra=0 / refine-mv=0 / rskip / scale-factor=0
        no-splitrd-skip / no-ssim-rd / no-tskip
        no-tskip-fast / tu-inter-depth=2 / tu-intra-depth=2

    Slice Decision
        b-adapt=2 / bframe-bias=0 / bframes=4 / b-pyramid
        ctu-info=0 / gop-lookahead=0 / no-intra-refresh
        keyint=100 / lookahead-slices=4 / min-keyint=100
        no-open-gop / radl=0 / rc-lookahead=30
        ref=4 / refine-analysis-type=0 / scenecut=0
        scenecut-bias=0.05

    Motion Search
        no-analyze-src-pics / max-merge=3 / me=3
        merange=57 / subme=3 / temporal-mvp / no-weightb
        weightp

    Loop Filter
        deblock=0:0 / no-limit-sao / sao / no-sao-non-deblock

    VUI
        chromaloc=0 / colormatrix=9 / colorprim=9
        no-dhdr10-opt / display-window=0 / no-hdr
        no-hdr-opt / max-cll=0,0 / max-luma=1023
        min-luma=0 / overscan=0 / range=0 / sar=1
        transfer=18 / videoformat=5

    Bitstream
        annexb / no-aud / hash=0 / no-hrd / no-idr-recovery-sei
        info / log2-max-poc-lsb=8 / no-multi-pass-opt-rps
        no-opt-cu-delta-qp / no-opt-qp-pps / no-opt-ref-list-length-pps
        no-repeat-headers / no-single-sei / no-temporal-layers
        vui-hrd-info / vui-timing-info

    Input/Output
        input-csp=1 / input-res=3840x2160 / interlace=0
        total-frames=0

    Performance
        copy-pic=1 / frame-threads=1 / no-pme / no-pmode
        slices=1 / wpp

    Statistic
        log-level=2 / no-psnr / no-ssim / stats-read=0
        stats-write=0

    Other
        cpuid=1111039 / high-tier=1 / level-idc=0
        max-ausize-factor=1.0 / no-allow-non-conformance
        no-constrained-intra / no-lowpass-dct / no-splice
        psy-rd=2.00 / signhide / strong-intra-smoothing
        uhd-bd=0

probably also easy to built would be columns like so:

    Rate Control
        aq-mode=1         no-aq-motion      aq-strength=1.00
        bitrate=4200      cbqpoffs=0        no-const-vbv
        crqpoffs=0        cutree            ipratio=1.40
        no-lossless       nr-inter=0        nr-intra=0
        pbratio=1.30      qcomp=0.60        qg-size=32
        qpmax=69          qpmin=0           qpstep=4
        rc=abr            no-rc-grain       no-strict-cbr
        zone-count=0

[aymanalz]

Is enabling --rect worth the increased encoding time? Does it give enough quality improvement? It slows down my encode by 41%.

My settings are approximately the same as the "slow" preset, except that I use CTU 32 instead of 64, and merange of 26. (2 pass encode, 1080p.)

Should I change parameters other than rect, to gain more quality per bit? Or does rect bring enough quality improvement to justify the 41% increase in encode time?

[Boulder]

I find it usable at least in frame-by-frame checks. Make sure you have --limit-refs 3 and --limit-modes set to gain some performance back, but I think 'slow' already uses them.

[filler56789]

.EXE 3.2+9-971180b is ready.

http://msystem.waw.pl/x265/

[aymanalz]

Originally Posted by Boulder

I find it usable at least in frame-by-frame checks. Make sure you have --limit-refs 3 and --limit-modes set to gain some performance back, but I think 'slow' already uses them.

I have set limits-refs 3 and limit modes, and yet I get a 41% increase in encode time.

Of all the settings in the "slow" preset, this is the one that causes the biggest speed hit for me. That's why I'm wondering if it is really worth it.

[redbtn]

I'd like to know lowering --cbqpoffs -3 and --crqpoffs -3 makes x265 spend more bits to chroma taking them from luma, or it just lowers QP for chroma but don't touch luma?

Originally Posted by aymanalz

Of all the settings in the "slow" preset, this is the one that causes the biggest speed hit for me. That's why I'm wondering if it is really worth it.

I decided that it's not worth it, at least for me. My target bitrate 17-18mb for FHD. Maybe at lower bitrate it gives more quality, I don't know.

[microchip8]

Originally Posted by aymanalz

I have set limits-refs 3 and limit modes, and yet I get a 41% increase in encode time.

Of all the settings in the "slow" preset, this is the one that causes the biggest speed hit for me. That's why I'm wondering if it is really worth it.

Not worth it. You won't notice a difference in moving frames, only still ones and not always

if you want to squeeze out a bit more quality and lower file size by a % or few, better use --hme=1 --hme-search=umh,umh,star

[Blue_MiSfit]

Originally Posted by redbtn

I decided that it's not worth it, at least for me. My target bitrate 17-18mb for FHD. Maybe at lower bitrate it gives more quality, I don't know.

At those rates you may very well get better results with AVC, to be honest.

[aymanalz]

Originally Posted by froggy1

Not worth it. You won't notice a difference in moving frames, only still ones and not always

if you want to squeeze out a bit more quality and lower file size by a % or few, better use --hme=1 --hme-search=umh,umh,star

Thanks. Ironically, I started off by using and tweaking your own settings posted in this thread, in which you had enabled rect.

Is --hme=1 beneficial for 1080p? I am targeting around 5-6 mbps.

[Boulder]

Originally Posted by Blue_MiSfit

At those rates you may very well get better results with AVC, to be honest.

That's true. For a regular, non-grainy source, over 10 Mbps at 1080p is already quite a lot. My 720p encodes with rather sharp downsizing and very light denoising, I usually get bitrates around 3-7 Mbps at CRF 18. Some episodes of Dark Matter have been below 2 Mbps

[aymanalz]

Originally Posted by froggy1

Not worth it. You won't notice a difference in moving frames, only still ones and not always

if you want to squeeze out a bit more quality and lower file size by a % or few, better use --hme=1 --hme-search=umh,umh,star

I just did that, and found that the resulting speed decrease is almost exactly the same as having --rect enabled. ie, using rect or using --hme umh,umh,star causes exactly the same amount of fps loss.

So if --hme gives better quality improvement than --rect, the takeaway should be to use hme and eschew rect, for squeezing out more quality for bitrate. I question whether the "slow" preset should have --rect enabled by default.

I notice that with --hme enabled, the second pass is much faster than the first. I wonder why that is.