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. |
2nd February 2018, 12:26 | #5881 | Link | |
Registered User
Join Date: Dec 2014
Posts: 240
|
Quote:
|
|
3rd February 2018, 18:10 | #5883 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 480
|
x265 v2.6+37-1949157705ce (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default |
3rd February 2018, 19:20 | #5884 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
@Barough - interesting, your version info strings still work:
Code:
x265 [info]: HEVC encoder version 2.6+37-1949157705ce x265 [info]: build info [Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit |
3rd February 2018, 21:12 | #5886 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
@LigH - the bug in binutils 2.30 for mingw target is huge, the compiler cannot create executables. If you build the x265.exe encoder it means you probably use binutils 2.29.1.
Mercurial was moved from mercurial.selenic.com to mercurial-scm.org and this is prime suspect for the problem. You can try to execute Code:
hg clone https://bitbucket.org/multicoreware/x265 |
3rd February 2018, 22:15 | #5887 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
I can build it ... despite:
Code:
[2018-01-29 21:24] [ALPM] upgraded mingw-w64-x86_64-binutils (2.29.1-1 -> 2.30-1) And because updating x265 failed with an "unresolved merge", I recently let the whole x265 source get cloned anew, by deleting the whole build/x265-hg directory. There is a new proposed patch to generate the hg version information in a different way, this is not yet committed. It's so confusing ... so many reasons why the base system of two users can be different enough that doing the same which is supposed to bring both systems to the same state still produces different results. Last edited by LigH; 3rd February 2018 at 22:19. |
4th February 2018, 13:07 | #5888 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
After re-installing MABS completely, which updated only to binutils-2.29, version strings are back. Other important changes:
32-bit builds made with GCC can open large files too; MinGW compiles exclude some superfluous libraries; fixes in special conditions with BREF frames, rate control with both weightp and cutree, and unnecessary luma calculations in CSV output x265 2.6+37-1949157705ce (MSYS2/MinGW, GCC 7.3.0) |
4th February 2018, 23:35 | #5889 | Link |
Registered User
Join Date: Jan 2010
Posts: 709
|
I would suggest a possible tune animation:
Code:
aq-mode 3 aq-strength 0.6 aq-motion qg-size 16 rc-lookahead +20 psy-rd 1.2 rdoq-level 2 psy-rdoq 0.3 deblock 1:-1 cbqpoffs -1 crqpoffs -1 Code:
ref +1 bframes +2
__________________
powered by Google Translator |
5th February 2018, 14:30 | #5890 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
I've prepared first version of anime patch with main part:
Code:
+ else if (!strcmp(tune, "anime")) + { + param->rc.aqMode = 3; + param->rc.aqStrength = 0.6; + param->bAQMotion = 1; + param->rc.qgSize = 16; + param->lookaheadDepth += 20; + param->psyRd = 1.2; + param->rdoqLevel = 2; + param->psyRdoq = 0.3; + param->bEnableLoopFilter = 1; + param->deblockingFilterTCOffset = 1; + param->deblockingFilterBetaOffset = -1; + param->cbQpOffset = -1; + param->crQpOffset = -1; + } |
7th February 2018, 00:39 | #5893 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
From my tests the option '--qg-size 16' is broken -- in all bitrates decrease quality.
I don't like '--aq-motion', so my 'anime' proposition is: --rc-lookahead *= 2; --psy-rd /= 2; --keyint *= 2; if (rdoq-level > 0) { --cbqpoffs -1; --crqpoffs -1; } if (preset >= 7) // slower, veryslow & placebo { --frame-threads 1; } |
9th February 2018, 21:06 | #5896 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
I've made some tests about '--qg-size'. For my eyes '--qg-size 32' is better than '--qg-size 16'. After checking all possible values (8, 16, 32 and 64) the best is 64 (PSNR/SSIM and for my eyes). It is a bit strange, the default value in x265 is 32.
My test was encoding first 2222 frames of big_buck_bunny_1080p24.y4m with preset slower, tune anime (which I renamed to cartoon), 10-bit output, ABR mode with bitrates: 300, 450, 750, 1200 and 1950, qg-size from 8 to 64. Command line: Code:
for %b in (300 450 750 1200 1950) do (for %q in (8 16 32 64) do (x265 -D10 --psnr --ssim -p7 -f2222 --tune cartoon --bitrate %b --qg-size %q ../big_buck_bunny_1080p24.y4m m%b-%q.hevc)) Code:
8 16 32 64 300 37.554/11.452 37.538/11.520 37.643/11.568 37.781/11.638 450 39.056/12.742 39.026/12.781 39.143/12.843 39.281/12.907 750 40.993/14.407 40.962/14.445 41.099/14.522 41.225/14.559 1200 42.835/16.004 42.802/16.032 42.958/16.117 43.065/16.136 1950 44.746/17.661 44.713/17.692 44.866/17.774 44.950/17.781 bitrate 300: qg-size 16, qg-size 64 bitrate 450: qg-size 16, qg-size 64 So my question is: what should I look at to see the advantages of qg-size 16? |
9th February 2018, 21:47 | #5897 | Link | |||
Registered User
Join Date: Oct 2001
Location: Germany
Posts: 7,259
|
Quote:
Quote:
Quote:
-> Shouldn't the default be 64 and not 32? |
|||
9th February 2018, 22:08 | #5899 | Link |
Registered User
Join Date: Feb 2015
Posts: 326
|
In documentation the default value of qg-size is 64, in real code it is 32. 'x265 --help' prints options and default values, if you encode there is line
Code:
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1 Anyway, the 32 value is a bit strange for me. ----------- It was changed in 2015-08-03 by https://bitbucket.org/multicoreware/...c4da4450e9f84e Last edited by Ma; 9th February 2018 at 22:33. |
Thread Tools | Search this Thread |
Display Modes | |
|
|