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 1st November 2017, 13:37   #5661  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
Support for Visual Studio 2017 will probably be available soon.

No reply to my request for MSYS2 yet, though.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 1st November 2017, 15:39   #5662  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 481
Visual Studio 2017 build folders have been added now
https://bitbucket.org/multicoreware/...b8d?at=default
Barough is offline   Reply With Quote
Old 2nd November 2017, 13:29   #5663  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
Join Date: Mar 2009
Location: offline
Posts: 1,480
Quote:
Originally Posted by LigH View Post
No reply to my request for MSYS2 yet, though.
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
Midzuki is offline   Reply With Quote
Old 2nd November 2017, 14:03   #5664  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
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)
In XhmikosR's MSYS environment, several binaries named "x86_64-w64-mingw32-*.exe" do exist, more than binaries named "i686-w64-mingw32-*.exe"; they all are missing in the directory msys64/mingw32/bin of MABS. I have no knowledge about the nature of these files. I wonder if they belong to a "GNU C++ cross-compilation package" which MABS does not need because MABS uses separate MinGW32 and MinGW64 system branches to build matching binaries natively.

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.
__________________

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

Last edited by LigH; 2nd November 2017 at 14:24.
LigH is offline   Reply With Quote
Old 2nd November 2017, 14:04   #5665  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,336
Quote:
Originally Posted by Midzuki View Post
if you want to use MSYS2, then use the real, the standalone MSYS2 itself, not the Media Autobuild Suite
Thats what I do, just use plain vanilla MSYS2 for the shell, and my own compiler package extracted somewhere in PATH, and stuff just works like it did before with MSYS1. Native 32-bit compilers and 64-bit "cross" compilers (not really cross compilers, but they have the prefix).
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.
nevcairiel is offline   Reply With Quote
Old 2nd November 2017, 14:26   #5666  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
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...
__________________

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

Last edited by LigH; 2nd November 2017 at 14:47.
LigH is offline   Reply With Quote
Old 2nd November 2017, 15:17   #5667  |  Link
Midzuki
Unavailable
 
Midzuki's Avatar
 
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
Midzuki is offline   Reply With Quote
Old 2nd November 2017, 15:23   #5668  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
Well, okay ... so my "workaround" will become my habit.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd November 2017, 18:05   #5669  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,336
Quote:
Originally Posted by LigH View Post
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)?
Why indeed. I build everything just fine with my manual environment.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 2nd November 2017, 19:19   #5670  |  Link
mandarinka
Registered User
 
mandarinka's Avatar
 
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.
mandarinka is offline   Reply With Quote
Old 2nd November 2017, 19:23   #5671  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
I would suspect that the optimum may not be disabling it completely, but restricting it to specific thread pools ... just a wild guess, uneducated.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd November 2017, 21:52   #5672  |  Link
jaiden190
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.
jaiden190 is offline   Reply With Quote
Old 2nd November 2017, 22:06   #5673  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
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)
is present in x265 v2.5, but I would not immediately know when it was introduced. Probably before v2.0 already.

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
ffmpeg does not expose all x265 parameters as ffmpeg native parameters, only those which are quite common, especially common among several encoders.
__________________

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

Last edited by LigH; 2nd November 2017 at 22:10.
LigH is offline   Reply With Quote
Old 2nd November 2017, 22:20   #5674  |  Link
jaiden190
Registered User
 
Join Date: Feb 2016
Posts: 5
Quote:
Originally Posted by LigH View Post
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)
is present in x265 v2.5, but I would not immediately know when it was introduced. Probably before v2.0 already.

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
ffmpeg does not expose all x265 parameters as ffmpeg native parameters, only those which are quite common, especially common among several encoders.

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.
jaiden190 is offline   Reply With Quote
Old 2nd November 2017, 22:24   #5675  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
Once again: Did you try putting it into -x265-params (with a syntax like: -x265-params master-display=string:max-cll=1000,400 etc.) for ffmpeg?
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 2nd November 2017, 22:34   #5676  |  Link
jaiden190
Registered User
 
Join Date: Feb 2016
Posts: 5
Quote:
Originally Posted by LigH View Post
Once again: Did you try putting it into -x265-params (with a syntax like: -x265-params master-display=string:max-cll=1000,400 etc.) for ffmpeg?
ahhh sorry about that. Didn't read you correctly.

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)"
jaiden190 is offline   Reply With Quote
Old 2nd November 2017, 22:36   #5677  |  Link
microchip8
ffx264/ffhevc author
 
microchip8's Avatar
 
Join Date: May 2007
Location: /dev/video0
Posts: 1,843
Quote:
Originally Posted by jaiden190 View Post
ahhh sorry about that. Didn't read you correctly.

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)"
it should be...

x265-params master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"
__________________
ffx264 || ffhevc || ffxvid || microenc
microchip8 is offline   Reply With Quote
Old 2nd November 2017, 22:40   #5678  |  Link
jaiden190
Registered User
 
Join Date: Feb 2016
Posts: 5
Quote:
Originally Posted by froggy1 View Post
it should be...

x265-params master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"
ahhhhh thats it. I have only really used handbrake GUI. Not used to CLI. Thank you both for your help.
jaiden190 is offline   Reply With Quote
Old 3rd November 2017, 11:55   #5679  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,746
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.
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 3rd November 2017, 13:40   #5680  |  Link
Barough
Registered User
 
Barough's Avatar
 
Join Date: Feb 2007
Location: Sweden
Posts: 481
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
Barough 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:52.


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