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 July 2019, 19:19   #6941  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by froggy1 View Post
the former. it's for better quality/accuracy. Here's an article that explains it. It is also low computational but highly efficient

http://homepages.inf.ed.ac.uk/rbf/CV...stimation.html
So, it can make things faster at the same quality, higher quality at the same speed, or a mix of the two.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th July 2019, 12:46   #6942  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 478
Quote:
Originally Posted by benwaggoner View Post
So, it can make things faster at the same quality, higher quality at the same speed, or a mix of the two.
Could you share your settings? By simply setting --hme, I'm seeing a reduction of around 40% in speed on my encodes. Thanks!
aegisofrime is offline   Reply With Quote
Old 24th July 2019, 13:12   #6943  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by aegisofrime View Post
Could you share your settings? By simply setting --hme, I'm seeing a reduction of around 40% in speed on my encodes. Thanks!
I don't see such a high penalty on my i7 7700K processor. I use hme=1 and hme-search=umh,umh,umh
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 24th July 2019, 15:16   #6944  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 377
My friend tried star,star,umh and caught a crash on frame 50, but umh,star,umh works fine (but slower).
__________________
Me on GitHub
PC Specs: Ryzen 5950X, 64 GB RAM, RTX 2070
DJATOM is offline   Reply With Quote
Old 24th July 2019, 15:20   #6945  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by DJATOM View Post
My friend tried star,star,umh and caught a crash on frame 50, but umh,star,umh works fine (but slower).
yes, I experienced the same crash when using star for all levels (L0,1,2) hme-search=star

I use umh because I find it preserves details better but is a bit slower than star
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 24th July 2019, 18:20   #6946  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,752
Quote:
Originally Posted by mandarinka View Post
From the description, it looks both aqmode 3 and aqmode 4 are modifications of aqmode 2. Based on the descriptions, the first adds bias for darker scenes/parts and the second (#4) adds bias for detected(?) edges (to improve them?).
Speculation: aq-mode 4 is the non-experimental implementation of --hevc-aq.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 24th July 2019, 21:00   #6947  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 240
@benwaggoner

i don't think so, as hevc-aq and aq-mode 4 coexists...
__________________
AMD Ryzen 9 5950X, 32GB DDR4-3200 CL16, RTX 3060, 2TB NVMe PCIE4.0, NAS with 8x16TB HDD
jlpsvk is offline   Reply With Quote
Old 24th July 2019, 22:41   #6948  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
Quote:
Originally Posted by DJATOM View Post
My friend tried star,star,umh and caught a crash on frame 50, but umh,star,umh works fine (but slower).
I can confirm it doesn't like star on the first instance, I got crash right at start with merange 92 and 1440x1080 source.

Quote:
Originally Posted by aegisofrime View Post
Could you share your settings? By simply setting --hme, I'm seeing a reduction of around 40% in speed on my encodes. Thanks!
To get higher speed, lower your merange. The value given is used as the distance of the first-stage search, so it is effectively quadrupled.
mandarinka is offline   Reply With Quote
Old 25th July 2019, 06:28   #6949  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
I'm currently using merange 32 for my 720p encodes (max CTU and TU is 32 for better CPU utilization). Would it make sense to lower the value for example to 16-20 and enable HME (with umh,umh,umh), or is the first stage range so important that it will start to affect the final result too much?
__________________
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 25th July 2019, 06:55   #6950  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by Boulder View Post
I'm currently using merange 32 for my 720p encodes (max CTU and TU is 32 for better CPU utilization). Would it make sense to lower the value for example to 16-20 and enable HME (with umh,umh,umh), or is the first stage range so important that it will start to affect the final result too much?
I use as ME range a value of 26 for 1080p encodes (ctu is 32 too). ME range is calculated as follows:

ctu size - 4(luma) - 2(chroma) (- 1 if me=hex is used)

You can lower it to 26 and enable HME like I do. Here the performance penalty is very minor, also considering that HME, as explained in the article I linked to a few posts earlier, has computationally low complexity

I wonder what options the poster above uses to hit a 40% reduction in speed when HME is enabled
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 25th July 2019, 10:17   #6951  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Quote:
Originally Posted by froggy1 View Post
I use as ME range a value of 26 for 1080p encodes (ctu is 32 too). ME range is calculated as follows:

ctu size - 4(luma) - 2(chroma) (- 1 if me=hex is used)

You can lower it to 26 and enable HME like I do. Here the performance penalty is very minor, also considering that HME, as explained in the article I linked to a few posts earlier, has computationally low complexity

I wonder what options the poster above uses to hit a 40% reduction in speed when HME is enabled
Thanks, I need to test that change. I also noticed a severe slowdown when testing HME at its default values and with merange 32. This is with basically settings from preset 'slower' with only a few minor changes.
__________________
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 25th July 2019, 11:55   #6952  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by Boulder View Post
Thanks, I need to test that change. I also noticed a severe slowdown when testing HME at its default values and with merange 32. This is with basically settings from preset 'slower' with only a few minor changes.
I don't use presets but my own settings which I'm satisfied with. Here are my libx265 ffmpeg settings

Code:
X265PARAMS="ref=4:me=umh:hme=1:hme-search=umh,umh,umh:bframes=6:rd=4:subme=4:merange=26:strong-intra-smoothing=0:ctu=32:sao=0:cu-lossless=0:cutree=1:fades=1:tu-inter-depth=3:tu-intra-depth=3:rskip=1:max-merge=1:rc-lookahead=60:aq-mode=1:aq-strength=1.0:rdoq-level=1:psy-rdoq=1.5:psy-rd=2.3:limit-modes=1:limit-refs=3:limit-tu=1:rd-refine=0:deblock=-3,-3:weightb=1:weightp=1:rect=1:amp=0:wpp=1:pmode=0:pme=0:b-intra=1:b-adapt=2:b-pyramid=1:tskip-fast=0:fast-intra=0:early-skip=0:min-keyint=24:keyint=240"
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 25th July 2019, 13:45   #6953  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Biggest differences seem to be ref=5, me star, rd=6, rd-refine, strong-intra-smoothing, max-merge=4 and amp in my settings. I don't think those should affect the search for motion though. I really need to test to get some rough values.
__________________
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 25th July 2019, 13:53   #6954  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 478
Quote:
Originally Posted by froggy1 View Post
I use as ME range a value of 26 for 1080p encodes (ctu is 32 too). ME range is calculated as follows:

ctu size - 4(luma) - 2(chroma) (- 1 if me=hex is used)

You can lower it to 26 and enable HME like I do. Here the performance penalty is very minor, also considering that HME, as explained in the article I linked to a few posts earlier, has computationally low complexity

I wonder what options the poster above uses to hit a 40% reduction in speed when HME is enabled
I was using the default ME range of 57. I guess it needs to be dropped once HME is enabled.

I can't wait to get a 3900X or a 16 core Threadripper!
aegisofrime is offline   Reply With Quote
Old 25th July 2019, 13:59   #6955  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by Boulder View Post
Biggest differences seem to be ref=5, me star, rd=6, rd-refine, strong-intra-smoothing, max-merge=4 and amp in my settings. I don't think those should affect the search for motion though. I really need to test to get some rough values.
you're maxing out a few things. rd=6 (combined with rd-refine) is IMHO overkill if you want to compromize between speed and quality

Motion Estimation is where the encoder spends most of its time and takes the biggest penalty the higher you get. rd=6 is very expensive. I'm fine with rd=4 (which is really rd=3 as 4 maps to it)

This is the best I can do on my i7 7700K when turning on HME. I don't want to wait days for an encode to finish and I won't see the difference when watching from afar on the TV

With my settings above and HME turned on, I can shave ~100 MiB of an encode. Encoded Blade Runner once with and once without HME. The result was 100 MiB in size reduction with better subjective quality when HME is on
__________________
ffx264 || ffhevc || ffxvid || microenc

Last edited by microchip8; 25th July 2019 at 14:12.
microchip8 is offline   Reply With Quote
Old 25th July 2019, 17:15   #6956  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Here are my results with my Black Sails testclip, 2748 frames @ CRF 18:

rd 6, no hme - 4333,39 kbps - 2.91 fps
rd 6, hme umh - 4323,63 kbps - 2.16 fps
rd 4, no hme - 4149,59 kbps - 3.95 fps
rd 4, hme umh - 4154,60 kbps - 2.66 fps

So the difference with rd=4 is even bigger than with rd=6 + rd-refine. I'm using a Ryzen 1800X @ 3.8 GHz.
__________________
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 25th July 2019, 17:22   #6957  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by Boulder View Post
Here are my results with my Black Sails testclip, 2748 frames @ CRF 18:

rd 6, no hme - 4333,39 kbps - 2.91 fps
rd 6, hme umh - 4323,63 kbps - 2.16 fps
rd 4, no hme - 4149,59 kbps - 3.95 fps
rd 4, hme umh - 4154,60 kbps - 2.66 fps

So the difference with rd=4 is even bigger than with rd=6 + rd-refine. I'm using a Ryzen 1800X @ 3.8 GHz.
I have the opposite experience. rd=6 is too costly here. But, the tests I did were a long time ago so I'll retest again soon
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 25th July 2019, 18:18   #6958  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Of course, it could be AVX2 which is making the difference here. On a first generation Zen CPU, it's more useful to disable it (as I've done). I'd expect an Intel CPU to benefit from AVX2.
__________________
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 26th July 2019, 14:21   #6959  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
I've reported the segfault when using star for hme-search Level 0 to the x265 devs. One of them came with a patch which I tested and seems to work. Patch is not committed yet but you can find it at https://mailman.videolan.org/piperma...ly/012601.html
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 26th July 2019, 14:35   #6960  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 377
Sweet, thanks.
__________________
Me on GitHub
PC Specs: Ryzen 5950X, 64 GB RAM, RTX 2070
DJATOM 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 09:36.


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