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 25th July 2019, 14:53   #6961  |  Link
aegisofrime
Registered User
 
Join Date: Apr 2009
Posts: 462
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, 14:59   #6962  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,551
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

Last edited by froggy1; 25th July 2019 at 15:12.
froggy1 is offline   Reply With Quote
Old 25th July 2019, 18:15   #6963  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,630
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, 18:22   #6964  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,551
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
froggy1 is offline   Reply With Quote
Old 25th July 2019, 19:18   #6965  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,630
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, 15:21   #6966  |  Link
froggy1
ffx264/ffhevc author
 
froggy1's Avatar
 
Join Date: May 2007
Location: Belgium
Posts: 1,551
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
froggy1 is offline   Reply With Quote
Old 26th July 2019, 15:35   #6967  |  Link
DJATOM
Registered User
 
DJATOM's Avatar
 
Join Date: Sep 2010
Location: Ukraine, Bohuslav
Posts: 188
Sweet, thanks.
__________________
Me on GitHub | My Telegram
PC Specs: Ryzen 3900X (no OC with 250W Air cooling), Asus ROG Crosshair Hero VII (WiFi) @ chipset x470, 32 GB RAM @ 3333MHz OC, Gigabyte RTX 2070, Kingston A1000 @ 240 GB
DJATOM is offline   Reply With Quote
Old 27th July 2019, 01:28   #6968  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 219
using --dither and happy that it dithers properly. amazing results. but I want to know which dithering method it uses? and what does it use when this flag isn't enabled?

thanks.
Natty is offline   Reply With Quote
Old 29th July 2019, 13:01   #6969  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 337
x265 v3.1+10-459d3822c608 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default
Barough is offline   Reply With Quote
Old 29th July 2019, 13:56   #6970  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,955
There was a comment in the sources in previous versions. From a former issue report:
Quote:
The dithering algorithm is based on Sierra-2-4A error diffusion.
Without dither, it will probably just strip off less significant bits (but not sure).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid

Last edited by LigH; 29th July 2019 at 14:03.
LigH is offline   Reply With Quote
Old 30th July 2019, 01:21   #6971  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 219
Quote:
Originally Posted by LigH View Post
There was a comment in the sources in previous versions. From a former issue report:


Without dither, it will probably just strip off less significant bits (but not sure).
nice its same as x264 then. i read about this. its similar to floyd. clears my confusion why grain particles were looking finer than ordered, but not as fine as floyd.
Natty is offline   Reply With Quote
Old 31st July 2019, 20:53   #6972  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 337
x265 v3.1.2+1-76650bab70f9 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)
Code:
https://bitbucket.org/multicoreware/x265/commits/
Barough is offline   Reply With Quote
Old 1st August 2019, 08:24   #6973  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,955
Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.

__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 1st August 2019, 09:09   #6974  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 948
Quote:
Originally Posted by LigH View Post
Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.

Yeah, it's becoming a mess :-/
filler56789 is offline   Reply With Quote
Old 1st August 2019, 12:26   #6975  |  Link
HolyWu
Registered User
 
HolyWu's Avatar
 
Join Date: Aug 2006
Location: Taiwan
Posts: 660
Quote:
Originally Posted by LigH View Post
Excuse me, fellow developers, but to a half-wit like me, this graph looks like there might be parallel development for a while now: One branch with mainly code and one with mainly version tags.
Apparently the new commits after tag 3.1 in Release_3.1 branch are not meant to add new functionality, but only meant to fix bug which causes x265 to crash or malfunction.
HolyWu is offline   Reply With Quote
Old 1st August 2019, 14:50   #6976  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,955
So, at the moment, users have to decide between either branch until a merge may happen...
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 1st August 2019, 14:54   #6977  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,833
Quote:
Originally Posted by LigH View Post
So, at the moment, users have to decide between either branch until a merge may happen...
From your screenshot of the history, I don't see any commit that is only on the 3.1 branch thats not also on the default branch. After the earlier fixes there was a merge back to default (through stable), and the later fixes are simply on both branches.
Of course you still have to decide which branch you want, thats why branches exist. If all were identical, what would be their point? The full development "default" branch, or the possibly more stable 3.1 release branch?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 1st August 2019 at 17:55.
nevcairiel is offline   Reply With Quote
Old 1st August 2019, 17:28   #6978  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,630
I tested HME some more, and got quite interesting results.

Source 1080p filtered with my standard methods and downsized to 720p, merange 26 and my standard settings in x265. 1000 frames.

umh,umh,umh 2.05 fps / 5313,76 kbps
umh,umh,star 2.24 fps / 5314,31 kbps
umh,star,star 2.00 fps / 5327,91 kbps
star,star,star 2.01 fps / 5316,15 kbps
hex,umh,umh 2.03 fps / 5299,69 kbps

no HME, umh 2.64 fps / 5323,86 kbps
no HME, star 2.79 fps / 5325,69 kbps

I'll make the same tests with some different clip to see if the difference simply occurs because of the source.
__________________
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 1st August 2019, 18:46   #6979  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 620
Quote:
Originally Posted by LigH View Post
So, at the moment, users have to decide between either branch until a merge may happen...
It's dev & stable branches strategy, except that instead of constantly merge stable to dev, they cherry pick (or duplicate) bug fixes onto dev branch.

It's literally the same thing as before, just in a different way.
MeteorRain is offline   Reply With Quote
Old 2nd August 2019, 08:21   #6980  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 5,955
Okay, I may have missed that some patches were applied to both branches.

The only problem here for casual builders using automated build suites: How shall the suite know which branch the user prefers? It cannot rely on "tip" pointing to either. May the author of such a suite have to add a choice in its configuration?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH 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 20:32.


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