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. |
29th July 2019, 12:01 | #6962 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
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 |
29th July 2019, 12:56 | #6963 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
There was a comment in the sources in previous versions. From a former issue report:
Quote:
Last edited by LigH; 29th July 2019 at 13:03. |
|
30th July 2019, 00:21 | #6964 | Link | |
Noob
Join Date: Mar 2017
Posts: 221
|
Quote:
|
|
31st July 2019, 19:53 | #6965 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
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/ |
1st August 2019, 07:24 | #6966 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
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.
|
1st August 2019, 13:54 | #6969 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
Quote:
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. |
|
1st August 2019, 16:28 | #6970 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
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... |
1st August 2019, 17:46 | #6971 | Link | |
結城有紀
Join Date: Dec 2003
Location: NJ; OR; Shanghai
Posts: 894
|
Quote:
It's literally the same thing as before, just in a different way. |
|
2nd August 2019, 07:21 | #6972 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,781
|
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? |
2nd August 2019, 11:54 | #6973 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,346
|
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 |
3rd August 2019, 21:44 | #6974 | Link | |
Registered User
Join Date: Jan 2007
Posts: 729
|
Quote:
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. 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. |
|
4th August 2019, 09:05 | #6975 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
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... |
8th August 2019, 21:46 | #6976 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
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 Last edited by benwaggoner; 8th August 2019 at 21:53. Reason: spelling |
8th August 2019, 21:55 | #6977 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
I think https://forum.doom9.org/showpost.php...postcount=6935 worked for me.
|
9th August 2019, 11:27 | #6978 | Link | |
Registered User
Join Date: Sep 2015
Posts: 48
|
Quote:
|
|
9th August 2019, 16:34 | #6979 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
|
|
Thread Tools | Search this Thread |
Display Modes | |
|
|