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. |
1st November 2017, 15:39 | #5662 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
Visual Studio 2017 build folders have been added now
https://bitbucket.org/multicoreware/...b8d?at=default |
2nd November 2017, 13:29 | #5663 | Link |
Unavailable
Join Date: Mar 2009
Location: offline
Posts: 1,480
|
Regarding https://www.mail-archive.com/x265-de.../msg10362.html
my piece of advice is, if you want to use MSYS2, then use the real, the standalone MSYS2 itself, not the Media Autobuild Suite --- at least if your only goal is keep compiling x265.exe. FWIW, the GCC packages provided by Nev and redistributed by XhmikosR can be used without modifications in the mingw32 directory of an MSYS2 environment, so that updating the "all-in-one" x265.exe building script (i.e., makemulti.sh) would be unnecessary. But as I said, I'm talking about a "normal" MSYS2 environment, because I really don't know what the MABS thing actually does. Also, this question: if you manage to make MSYS2 do exactly what MSYS1 does, regarding the "fully-automated" compilation of x265.exe, ¿then what is the point of the upgrade? Last edited by Midzuki; 2nd November 2017 at 13:33. Reason: clarity |
2nd November 2017, 14:03 | #5664 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
I see it as an advantage that MABS uses pacman as package manager to keep its MSYS2 environment up to date automatically each time you run it. Apart from that, the media tools compilation script is based on a pretty generic MSYS2 environment and installs additional packages for those tools which need extras. That means, chances are good that all the tools required to build x265 are more recent than waiting for any other person uploading a package and manually exchanging files (in fact, only overwriting or adding, but not removing outdated ones, which a package manager will do instead).
As I already wrote, I discovered that I am not able to run the MSYS script provided by Multicoreware in the MSYS2 environment which gets installed by MABS from official package sources. The differences are in the presence of cross compilation twins of GCC applications, which are used when Win64 flavours of x265 should be built in a MinGW32 environment. The differences are: toolchain-x86_64-w64-mingw32.cmake Code:
SET(CMAKE_SYSTEM_NAME Windows) SET(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc) SET(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++) SET(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres) SET(CMAKE_RANLIB x86_64-w64-mingw32-ranlib) SET(CMAKE_ASM_YASM_COMPILER yasm) If one knew that they are indeed the mirrored binaries of the opposite MinGW bitness, I guess one could add symbolic links to each opposite MinGW branch, enabling an optional cross-compilation of either the Win64 build of x265 using MinGW32 compilers (analogue to the behaviour in the current MSYS scripts) or the Win32 build of x265 using MinGW64 compilers (possibly preferred for more efficiency). But if they differ in their functionality (e.g. have to be aware of building a binary not matching the native bitness of the environment), then they may have to get installed at least once manually into the MSYS2 system, hoping that the MABS updater will keep them up to date just along with the packages MABS needs, simply because pacman will find updates for these cross-compilation packages as well. Last edited by LigH; 2nd November 2017 at 14:24. |
2nd November 2017, 14:04 | #5665 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,347
|
Quote:
Stuff like MABS is just way too annoying to handle.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders Last edited by nevcairiel; 2nd November 2017 at 14:07. |
|
2nd November 2017, 14:26 | #5666 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
But why waste twice the space with two separate MSYS2 environments (one automatically updated by MABS which I still occasionally use to build everything, and the other manually updated on demand but only specifically used to build x265)?
If the MSYS scripts provided by Multicorecare generally work in MSYS2 too, then all I need to know is why some cross-compilation GCC binaries are missing, and how to add them in a way that pacman is aware of them, to possibly update them along. __ P.S.: Apparently I would need to install MinGW-w64 as cross-compilation package... Last edited by LigH; 2nd November 2017 at 14:47. |
2nd November 2017, 15:17 | #5667 | Link |
Unavailable
Join Date: Mar 2009
Location: offline
Posts: 1,480
|
First of all, one really should forget the auto-update mania.
Updating for the sake of updating is pointless: if the system works, there is no need to fix it. When I switched to MSYS2 many moons ago I used pacman only for downloading the missing stuff, EXCEPT the MinGW_w64+GCC packages. In the beginning I used the archives provided by Nev, but later I learned how to compile (and organize) the compilers themselves =) IMHO the point of MSYS2 is *simplicity*: build 32-bit binaries through mingw32, build 64-bit binaries through mingw64, case closed |
2nd November 2017, 18:05 | #5669 | Link |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,347
|
Why indeed. I build everything just fine with my manual environment.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
2nd November 2017, 19:19 | #5670 | Link |
Registered User
Join Date: Jan 2007
Posts: 729
|
Apparently x265 can be up to 5% faster on AMD Ryzens if it doesn't use AVX2: link (RZN = Ryzen, CFL = Coffee Lake, SKL-X = Skylake-X)
Can we get some change to CPU detection/dispatcher that would make x265 not use AVX2 assembly on Zen cores? (this also hapens on Excavator) AFAIK. I know I can override the autodetection in commandline, but it should really be done by default, because most people aren't going to know about this, plus it gets more iffy for GUI/frontend users. |
2nd November 2017, 21:52 | #5672 | Link |
Registered User
Join Date: Feb 2016
Posts: 5
|
Unrecognized option 'master-display'.
Hello. First time post here. I am trying to get HDR working. I Compiled a 10bit ffmpeg.exe and I can get everything else like bt.2020 to work. But I can't seem to get the metadata for the -master-display to work. Comes up with Unrecognized option 'master-display' when I start.
Bit of a nub with this. Any help would be appreciated. |
2nd November 2017, 22:06 | #5673 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
Which version of x265 do you use? And do you prepend it with a double dash?
Code:
--master-display <string> SMPTE ST 2086 master display color volume info SEI (HDR) format: G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min) Oh, wait, you said ffmpeg. So, it would be a part of Code:
-x265-params <string> E..V.... set the x265 configuration using a :-separated list of key=value parameters Last edited by LigH; 2nd November 2017 at 22:10. |
2nd November 2017, 22:20 | #5674 | Link | |
Registered User
Join Date: Feb 2016
Posts: 5
|
Quote:
I compiled it with media-autobuild_suite-master. I assume it gets the latest x265. double dash has the same error. -max-cll "1000,400" has the same problem also. |
|
2nd November 2017, 22:34 | #5676 | Link | |
Registered User
Join Date: Feb 2016
Posts: 5
|
Quote:
Im getting somewhere now. I no longer get the Unrecognized option error now but when I run it i get this instead. "Unable to find a suitable output format for 'G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1)' G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1): Invalid argument" this is what I am using. x265-params -master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)" |
|
2nd November 2017, 22:36 | #5677 | Link | |
ffx264/ffhevc author
Join Date: May 2007
Location: /dev/video0
Posts: 1,844
|
Quote:
x265-params master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)" |
|
3rd November 2017, 11:55 | #5679 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,782
|
One more thought regarding MSYS2 ... MABS seems to be able to switch from the MinGW32 to the MinGW64 environment. Once I discover how it does that, I may be able to fully automate my own x265-only build script to generate one after another, each using the native compiler bitness.
|
3rd November 2017, 13:40 | #5680 | Link |
Registered User
Join Date: Feb 2007
Location: Sweden
Posts: 483
|
x265 v2.5+33-6a310b24c6a2 (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)
Code:
https://bitbucket.org/multicoreware/x265/commits/branch/default |
|
|