Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > High Efficiency Video Coding (HEVC)

Reply
 
Thread Tools Search this Thread Display Modes
Old 22nd October 2019, 18:39   #7121  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
HME Current Opinions

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.
brumsky is offline   Reply With Quote
Old 23rd October 2019, 03:06   #7122  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
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

stax76 is offline   Reply With Quote
Old 23rd October 2019, 09:42   #7123  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by brumsky View Post
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
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 23rd October 2019, 20:03   #7124  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by froggy1 View Post
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?
brumsky is offline   Reply With Quote
Old 24th October 2019, 04:59   #7125  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by brumsky View Post
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)
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 24th October 2019, 18:23   #7126  |  Link
brumsky
Registered User
 
Join Date: Jun 2016
Posts: 116
Quote:
Originally Posted by froggy1 View Post
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?
brumsky is offline   Reply With Quote
Old 24th October 2019, 21:03   #7127  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 63
Quote:
Originally Posted by stax76 View Post
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!
_kermit is offline   Reply With Quote
Old 25th October 2019, 06:43   #7128  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by brumsky View Post
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.
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 26th October 2019, 03:00   #7129  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Quote:
Originally Posted by stax76 View Post
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!!
Blue_MiSfit is offline   Reply With Quote
Old 26th October 2019, 03:07   #7130  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
Next release will have it sorted alphabetically.

Code:
    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:

Code:
    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

Last edited by stax76; 26th October 2019 at 03:18.
stax76 is offline   Reply With Quote
Old 27th October 2019, 18:53   #7131  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
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?
aymanalz is offline   Reply With Quote
Old 27th October 2019, 19:58   #7132  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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.
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 27th October 2019, 21:03   #7133  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
.EXE 3.2+9-971180b is ready.

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

Last edited by filler56789; 27th October 2019 at 21:14.
filler56789 is offline   Reply With Quote
Old 27th October 2019, 21:51   #7134  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by Boulder View Post
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.
aymanalz is offline   Reply With Quote
Old 28th October 2019, 01:26   #7135  |  Link
redbtn
Registered User
 
redbtn's Avatar
 
Join Date: Jan 2019
Location: Russia
Posts: 105
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?

Quote:
Originally Posted by aymanalz View Post


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.

Last edited by redbtn; 28th October 2019 at 01:41.
redbtn is offline   Reply With Quote
Old 28th October 2019, 06:40   #7136  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by aymanalz View Post
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
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 28th October 2019, 07:20   #7137  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
Quote:
Originally Posted by redbtn View Post
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.
Blue_MiSfit is offline   Reply With Quote
Old 28th October 2019, 08:04   #7138  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by froggy1 View Post
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.
aymanalz is offline   Reply With Quote
Old 28th October 2019, 09:19   #7139  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by Blue_MiSfit View Post
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
__________________
And if the band you're in starts playing different tunes
I'll see you on the dark side of the Moon...
Boulder is offline   Reply With Quote
Old 28th October 2019, 09:41   #7140  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 68
Quote:
Originally Posted by froggy1 View Post
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.
aymanalz is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.