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 27th July 2019, 00:28   #6961  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 221
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, 12:01   #6962  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
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, 12:56   #6963  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
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 13:03.
LigH is offline   Reply With Quote
Old 30th July 2019, 00:21   #6964  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 221
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, 19:53   #6965  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 480
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, 07:24   #6966  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
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, 08:09   #6967  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
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, 13:50   #6968  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
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, 13:54   #6969  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
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 16:55.
nevcairiel is online now   Reply With Quote
Old 1st August 2019, 16:28   #6970  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
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, 17:46   #6971  |  Link
MeteorRain
結城有紀
 
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
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.
__________________
Projects
x265 - Yuuki-Asuna-mod Download / GitHub
TS - ADTS AAC Splitter | LATM AAC Splitter | BS4K-ASS
Neo AviSynth+ filters - F3KDB | FFT3D | DFTTest | MiniDeen | Temporal Median
MeteorRain is offline   Reply With Quote
Old 2nd August 2019, 07:21   #6972  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,752
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
Old 2nd August 2019, 11:54   #6973  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
The concept of "tip" in mercurial is flawed anyway, would never rely on it. Someone pushed an experimental half-broken branch, and suddenly thats the tip? Clearly not what everyone wants to build off of. The "most recent change" seems like a particular worthless point of reference to use.
You should always be aware of what branch you build from.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 3rd August 2019, 21:44   #6974  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
Quote:
Originally Posted by Boulder View Post
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.
I tested HME (with umh/umh/umh, merange 92, against umh with same merange) on some cel anime bluray footage with motion (both full camera motion and objects in scene only motion).

I got notably decreased SSIM score with HME, so be careful, at these low resolutions it looks like it is possible that HME doesn't help but harms.
Why? The first ME pass with merange 92 is done on 4X downscale. So if you have 1080p resolution, you are down on 240p. It is likely that small objects won't get tracked properly at this stage. After that, the second (480p) and last (1080p) ME stage only only lower merange (search distance), I assume? So if the large downscaling fools the first pass, the second and third stage might not be able to correct it.

My footage was 1440x1080 and you would have even worse situation at 720p. Basically this factor may cause HME to be counter productive unless you use it on 4K for which ts was intended (IIRC).

Code:
"n:\x265-3.1+8-21db162c8622.exe" - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16 
--pass 2 --bitrate 10000 --tune ssim --ssim --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me star --subme 7 --merange 92 --amp --rect --ref 6 
--weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --rd 5 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 --qcomp 0.7 
--no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 2 --wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree --cu-lossless 
--lookahead-slices 2 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2

encoded 853 frames in 5108.02s (0.17 fps), 10064.24 kb/s, Avg QP:19.49, SSIM Mean Y: 0.9820175 (17.451 dB)


"n:\x265-3.1+8-21db162c8622.exe" - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16 
--pass 2 --bitrate 10000 --tune ssim --ssim --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me umh --subme 7 --merange 92 --amp --rect --ref 6 
--weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --rd 5 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 --qcomp 0.7 
--no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 2 --wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree --cu-lossless 
--lookahead-slices 2 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2

encoded 853 frames in 11135.11s (0.08 fps), 10064.75 kb/s, Avg QP:19.49, SSIM Mean Y: 0.9820200 (17.452 dB)

"n:\x265-3.1+8-21db162c8622.exe" - --input-depth 8 --input-res 1440x1080 --fps 24000/1001 --preset slower --output-depth 10 --ctu 32 --max-tu-size 16 
--pass 2 --hme --hme-search umh,umh,umh --bitrate 10000 --tune ssim --ssim --tu-intra-depth 2 --tu-inter-depth 2 --rdpenalty 2 --me umh --subme 7 
--merange 92 --amp --rect --ref 6 --weightb --weightp --keyint 300 --min-keyint 1 --bframes 8 --rd 5 --no-sao --no-open-gop --rc-lookahead 80 --max-merge 5 
--qcomp 0.7 --no-strong-intra-smoothing --no-limit-modes --limit-refs 0 --limit-tu 0 --frame-threads 2 --wpp --deblock -2:-2 --qg-size 8 --pbratio 1.2 --no-cutree 
--cu-lossless --lookahead-slices 2 --sar 1:1 --range limited --chromaloc 0 --colormatrix bt709 --no-rskip --rd-refine --cbqpoffs -2 --crqpoffs -2

encoded 853 frames in 7319.99s (0.12 fps), 10051.98 kb/s, Avg QP:19.52, SSIM Mean Y: 0.9819607 (17.438 dB)

p.s. Ignore the fps values, they are not indicative of the speed due to background cpu usage, system sleeping for a time and so on.
BTW, it would be interesting to determine what is the speed hit of a particular HME setting and then determine how much do you need to increase merange for the normal search mode to get at the same FPS - and then comapre the quality/SSIM. Because obvioously the added computation time could be used to improve quality by just increasing merange too, so that is your reference point for comparisons.

Edit: one other thing. Doing two-pass testing smaples, I found that just switching ME method between star and umh changes content of each frame and block quite a bit due to various indeterministic things going on. Individual frames would look worse and better based on how the rate control stars aligned.
So don't compare the results just by bitrate they give you!
It is quite possible the two files are not the exactly same quality, which would skew your judgement completely.

Last edited by mandarinka; 4th August 2019 at 02:36.
mandarinka is offline   Reply With Quote
Old 4th August 2019, 09:05   #6975  |  Link
Boulder
Pig on the wing
 
Boulder's Avatar
 
Join Date: Mar 2002
Location: Finland
Posts: 5,718
Isn't it the other way around so that the first pass is made at full resolution and then the result is used as a predictor for the next pass which is done after downscaling. I agree that small details could well be lost when downscaling. The code seems to set the limit to use HME at 540 pixels of vertical resolution.

What I was wondering with those results of mine was that umh,umh,star was noticably faster than any other combination.
__________________
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 8th August 2019, 21:46   #6976  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Is there a build which includes the --aq-mode 4 patch? I've tried the latest ones here, and I keep getting:
Code:
C:\Users\benwagg\Desktop\x265>C:\Users\benwagg\Desktop\x265\x265.exe --input D:\Rights_Cleared_Sources\TearsofSteel_1920x800p24.y4m --preset slower --crf 28 --aq-mode 4 -F 1 --min-keyint 72 --keyint 120 --no-open-gop D:\TearsOfSteel\ToS_aqm4_crf28.hevc
y4m  [info]: 1920x800 fps 24/1 i420p8 frames 0 - 17619 of 17620
raw  [info]: output file: D:\TearsOfSteel\ToS_aqm4_crf28.hevc
x265 [info]: HEVC encoder version 3.1.2+1-76650bab70f9
x265 [info]: build info [Windows][GCC 9.1.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [error]: Aq-Mode is out of range
x265 [error]: failed to open encoder
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book

Last edited by benwaggoner; 8th August 2019 at 21:53. Reason: spelling
benwaggoner is offline   Reply With Quote
Old 8th August 2019, 21:55   #6977  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
Join Date: Jan 2007
Posts: 729
I think https://forum.doom9.org/showpost.php...postcount=6935 worked for me.
mandarinka is offline   Reply With Quote
Old 9th August 2019, 11:27   #6978  |  Link
pradeeprama
Registered User
 
Join Date: Sep 2015
Posts: 48
Quote:
Originally Posted by Wolfberry View Post
The new aq-mode and HME is only present in the default branch (3.1)

3.1.1 and 3.1.2 from the Release_3.1 branch only include some bug fixes that are also on the default branch.

x265-3.1+11-de920e0-win64-static-multilib

Code:
x265 [info]: HEVC encoder version 3.1+11-de920e0a3183
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec  58.55.100)
x265 [info]: (libavformat 58.30.100)
x265 [info]: (libavutil   56.33.100)
x265 [info]: (lsmash       2.16.1)
These features will be part of the next release, which will have its own branch. Only bug fixes for v3.1 will go into the Release_3.1 branch
pradeeprama is offline   Reply With Quote
Old 9th August 2019, 16:34   #6979  |  Link
benwaggoner
Moderator
 
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
Quote:
Originally Posted by Wolfberry View Post
The new aq-mode and HME is only present in the default branch (3.1)

3.1.1 and 3.1.2 from the Release_3.1 branch only include some bug fixes that are also on the default branch.

x265-3.1+11-de920e0-win64-static-multilib
It worked! I'm going to knock out some aq-mode 2 versus 4 tests with Tears of Steel.
__________________
Ben Waggoner
Principal Video Specialist, Amazon Prime Video

My Compression Book
benwaggoner is offline   Reply With Quote
Old 14th August 2019, 09:20   #6980  |  Link
jlpsvk
Registered User
 
Join Date: Dec 2014
Posts: 240
@benwaggoner
any thought about aq-mode 2 vs aq-mode 4?
__________________
AMD Ryzen 9 5950X, 32GB DDR4-3200 CL16, RTX 3060, 2TB NVMe PCIE4.0, NAS with 8x16TB HDD
jlpsvk 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 11:06.


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