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 16th October 2019, 14:54   #7121  |  Link
sonnati
Registered User
 
Join Date: Jun 2008
Posts: 18
Quote:
Originally Posted by benwaggoner View Post
There are tons of devices where HEVC is the only supported 10-bit codec. I'd expect pretty much all streaming of 4K or HDR content to those devices to be in HEVC. I don't know of anyone doing HDR or >1080p in H.264.

It'd probably take something like Wireshark to figure out what is being used in other cases. In the adaptive streaming world, there can be dozens of encoded variants of a given title, in different frame sizes, bitrates, DRM, and codecs.

As a wild personal guess, I'd expect a lot more premium content is delivered in HEVC than in VP9+AV1. The On2 stuff has always been most focused on browser-based user generated content without DRM, and there aren't any AV1 HW DRM + decode products in the market, or even announced.

As for quality versus speed, At the same encoding speed, x265 beats x264 in the cases I've tested in the last couple of years. Sure, it doesn't take full advantage of what HEVC can do, but it's still better for most content (there are likely edge cases with a lot of grain). The fastest possible x264 will be faster than the fastest possible x265, of course. x265 and HEVC in general takes better advantage of AVX, multithreading, and 64-bit than x264, so the newer the processor, the better quality @ perf HEVC has.
I would be no surprised if Netflix delivered H.265 to connectedTV even when content is below 4K. This would increase the market share of H.265 considerably because vast majority of Netflix's traffic is on TV and a wide % of those TV has H.265 decoding capabilities. Add to this the 100s millions of iOS devices supporting H.265 (with possible use by Netflix) and the real share should be higher than what can be derived classically from the share seen by cloud encoders vendors or similar.

Last edited by sonnati; 16th October 2019 at 14:57.
sonnati is offline   Reply With Quote
Old 16th October 2019, 22:29   #7122  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 337
x265 v3.2+7-37648fca915b (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 16th October 2019, 22:52   #7123  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,855
Quote:
Originally Posted by Barough View Post
x265 v3.2+7-37648fca915b (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Thanks for the build. Why is it that large? 20 MB is too much for staxrip as it consumes 550 MB disk space and 200 MB download space, build by Patman is 2 MB.
stax76 is offline   Reply With Quote
Old 16th October 2019, 22:57   #7124  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 337
Quote:
Originally Posted by stax76 View Post
Thanks for the build. Why is it that large? 20 MB is too much for staxrip as it consumes 550 MB disk space and 200 MB download space, build by Patman is 2 MB.
I guess that Patman use some kind of compression on his EXE.

Skickat från min SM-G975F via Tapatalk
Barough is offline   Reply With Quote
Old 19th October 2019, 17:33   #7125  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,176
Quote:
Originally Posted by stax76 View Post
Thanks for the build. Why is it that large? 20 MB is too much for staxrip as it consumes 550 MB disk space and 200 MB download space, build by Patman is 2 MB.
UPX is your friend.
https://upx.github.io/
Atak_Snajpera is online now   Reply With Quote
Old 19th October 2019, 19:18   #7126  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,855
Quote:
Originally Posted by Atak_Snajpera View Post
UPX is your friend.
https://upx.github.io/
I'll use that if it's easy enough, thanks.
stax76 is offline   Reply With Quote
Old 19th October 2019, 19:30   #7127  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,176
Quote:
Originally Posted by stax76 View Post
I'll use that if it's easy enough, thanks.
Basically drag and drop
Atak_Snajpera is online now   Reply With Quote
Old 19th October 2019, 19:47   #7128  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,855
That's easy. I use context menu.

https://github.com/stax76/OpenWithPlusPlus
stax76 is offline   Reply With Quote
Old 21st October 2019, 09:42   #7129  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,943
^ Nice extension.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 22nd October 2019, 19:39   #7130  |  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, 04:06   #7131  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,855
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, 10:42   #7132  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,550
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
froggy1 is online now   Reply With Quote
Old 23rd October 2019, 21:03   #7133  |  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, 05:59   #7134  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,550
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
froggy1 is online now   Reply With Quote
Old 24th October 2019, 19:23   #7135  |  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, 22:03   #7136  |  Link
_kermit
Registered User
 
Join Date: Apr 2017
Posts: 12
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, 07:43   #7137  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,550
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
froggy1 is online now   Reply With Quote
Old 26th October 2019, 04:00   #7138  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,557
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, 04:07   #7139  |  Link
stax76
Registered User
 
stax76's Avatar
 
Join Date: Jun 2002
Location: Chamber 36
Posts: 5,855
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 04:18.
stax76 is offline   Reply With Quote
Old 27th October 2019, 18:53   #7140  |  Link
aymanalz
Registered User
 
Join Date: May 2015
Posts: 67
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
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 18:40.


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