[HEVC] x265.EXE: mingw builds

[eca2424]

Hmm, strange. The location of the scripts appears to be correct (in C:\MSYS\home\2016, not in C:\MSYS\bin). I don't know why they are "not found". Please show the output of "ls -l" in your shell; in mintty, "ls -Flash" should look even prettier.

And yes, the link seems to be correctly edited.

I try msys.bat and work it but follow error
http://i.hizliresim.com/L1mLAa.png

[LigH.de]

It seems that compiling failed, therefore no exe and no dll exists.

Running ./remake_x265.sh should take a while if it is successful, and produce a lot of console output. Are there any error messages? Maybe I forgot to mention that you have to install CMake as well...

[eca2424]

It seems that compiling failed, therefore no exe and no dll exists.

Running ./remake_x265.sh should take a while if it is successful, and produce a lot of console output. Are there any error messages? Maybe I forgot to mention that you have to install CMake as well...

you right ı forgot cmake okay i did Now, I just need to use what code to make 1.7 or 1.8?

[LigH.de]

You should have executed hg clone https://bitbucket.org/multicoreware/x265 and then ./uptodate_x265.sh once to prepare your local source copy and the building subdirectories. Then...

To build the revision with the tag "1.7":

• hg update --cwd x265 -r 1.7
• ./remake_x265.sh
• ./makemulti.sh
• ./release_x265.sh
• Archive the content of C:\MSYS\home\2016\release after testing if x265_ml -V in C:\MSYS\home\2016\release\Win32 reports the version correctly.

To build the revision with the tag "1.8":

• hg update --cwd x265 -r 1.8
• ./remake_x265.sh
• ./makemulti.sh
• ./release_x265.sh
• Archive the content of C:\MSYS\home\2016\release after testing if x265_ml -V in C:\MSYS\home\2016\release\Win32 reports the version correctly.

Please note: Trying to build versions before 12 bit code has been developed will probably fail without editing the shell scripts.

[eca2424]

You should have executed hg clone https://bitbucket.org/multicoreware/x265 and then ./uptodate_x265.sh once to prepare your local source copy and the building subdirectories. Then...

To build the revision with the tag "1.7":

• hg update --cwd x265 -r 1.7
• ./remake_x265.sh
• ./makemulti.sh
• ./release_x265.sh
• Archive the content of C:\MSYS\home\2016\release after testing if x265_ml -V in C:\MSYS\home\2016\release\Win32 reports the version correctly.

To build the revision with the tag "1.8":

• hg update --cwd x265 -r 1.8
• ./remake_x265.sh
• ./makemulti.sh
• ./release_x265.sh
• Archive the content of C:\MSYS\home\2016\release after testing if x265_ml -V in C:\MSYS\home\2016\release\Win32 reports the version correctly.

Please note: Trying to build versions before 12 bit code has been developed will probably fail without editing the shell scripts.

thats all.Thank you very much.and Thank you for your patience.

[eca2424]

Hi @LigH.de, me again. What code 8+10 bit for multilib.sh ? not 8+10+12. only 8+10

[Selur]

you would need to modify multilib.sh to only build 8+10 -> Have you ever read it and understood how it works?

[eca2424]

you would need to modify multilib.sh to only build 8+10 -> Have you ever read it and understood how it works?

Yes. Multilib.sh edit with visual studio. What code only 8+10 bits? Do you now sir?

[Selur]

If you are using Visual Studio, editing and/or using multilib.sh which is a shell script meant for linux enviroments, doesn't make any sense at all!

What you need to edit and use is the multilib.bat which resides in the corresponding build/vc... folder which matches your Visual Studio version.
Looking at for example at: https://bitbucket.org/multicoreware/x265/src/425b583f25dbb57af86fc5c128548038954baf31/...e-view-default

you would need to delete:

@mkdir 12bit

@cd 12bit
cmake -G "Visual Studio 12 Win64" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON
if exist x265.sln (
  MSBuild /property:Configuration="Release" x265.sln
  copy/y Release\x265-static.lib ..\8bit\x265-static-main12.lib
)

if not exist x265-static-main12.lib (
  msg "%username%" "12bit build failed"
  exit 1
)

and exchange:

cmake -G "Visual Studio 12 Win64" ../../../source -DEXTRA_LIB="x265-static-main10.lib;x265-static-main12.lib" -DLINKED_10BIT=ON -DLINKED_12BIT=ON
if exist x265.sln (
  MSBuild /property:Configuration="Release" x265.sln
  :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
  move Release\x265-static.lib x265-static-main.lib
  LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib x265-static-main12.lib
)

with:

cmake -G "Visual Studio 12 Win64" ../../../source -DEXTRA_LIB="x265-static-main10.lib" -DLINKED_10BIT=ON 
if exist x265.sln (
  MSBuild /property:Configuration="Release" x265.sln
  :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
  move Release\x265-static.lib x265-static-main.lib
  LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib
)

[eca2424]

If you are using Visual Studio, editing and/or using multilib.sh which is a shell script meant for linux enviroments, doesn't make any sense at all!

What you need to edit and use is the multilib.bat which resides in the corresponding build/vc... folder which matches your Visual Studio version.
Looking at for example at: https://bitbucket.org/multicoreware/x265/src/425b583f25dbb57af86fc5c128548038954baf31/...e-view-default

you would need to delete:

@mkdir 12bit

@cd 12bit
cmake -G "Visual Studio 12 Win64" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON
if exist x265.sln (
  MSBuild /property:Configuration="Release" x265.sln
  copy/y Release\x265-static.lib ..\8bit\x265-static-main12.lib
)

if not exist x265-static-main12.lib (
  msg "%username%" "12bit build failed"
  exit 1
)

and exchange:

cmake -G "Visual Studio 12 Win64" ../../../source -DEXTRA_LIB="x265-static-main10.lib;x265-static-main12.lib" -DLINKED_10BIT=ON -DLINKED_12BIT=ON
if exist x265.sln (
  MSBuild /property:Configuration="Release" x265.sln
  :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
  move Release\x265-static.lib x265-static-main.lib
  LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib x265-static-main12.lib
)

with:

cmake -G "Visual Studio 12 Win64" ../../../source -DEXTRA_LIB="x265-static-main10.lib" -DLINKED_10BIT=ON 
if exist x265.sln (
  MSBuild /property:Configuration="Release" x265.sln
  :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
  move Release\x265-static.lib x265-static-main.lib
  LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib
)

I'm using GCC. Should I delete all?

[Selur]

If you use GCC, you should edit the multilib.sh and remove everything related to the 12bit library.

[eca2424]

I did exactly as you say, but it did not work here multilib.sh

[Selur]

Can't follow you, .... your are not usign the multilib.sh, but the makemulti.sh and that still contains lots of call related to 12bit,....

[eca2424]

I'm sorry I misspelled.actually makemulti.sh. thats original. I do not edit.

[LigH.de]

New build with changed 2-pass VBV-CRF conditions (AFAIK, you have to add --vbv-maxrate {kbps} in 1st pass to enable the use of a CRF value for VBV-constrained CRF mode instead of a target bitrate for VBR mode in 2nd pass):

x265 1.9+15-425b583f25db (GCC 5.3.0)

[LigH.de]

x265 1.9+54-291beccb6760 with fixed 2-pass VBR rate control.

[LigH.de]

Some more bitrate control enhancements in x265 1.9+88-b6d8e66e7f71

[LigH.de]

x265 1.9+96-b09998b1256e should have fixed the bitrate control for zones.

[-Habanero-]

Am I the only one who is getting lower quality output now than x265 1.4?

[sneaker]

For the same bitrate and fps? Yes, you are the only one.

[LigH.de]

Experimental UHD Bluray support (--uhd-bd) in x265 1.9+106-c8ec86965e54; is there anyone who can test and confirm?

[Selur]

Is there some sort of overview what this should do?
http://x265.readthedocs.org/en/latest/cli.html?highlight=--uhd#cmdoption--uhd-bd isn't really informative and so a x265/H.265 specific overview would be helpful.

[LigH.de]

I don't know any other detailed documentation yet. For now you may have to inspect the patch source. Sneaker already found a few flaws, reported in the doom9 forum.

[LigH.de]

Several fixes regarding UHD-BD, dithering of different color depths, and documentation clarifications:

x265 1.9+125-40afead3177d

[SameSelf]

Several fixes regarding UHD-BD, dithering of different color depths, and documentation clarifications:

x265 1.9+125-40afead3177d

So x265 can encode UHD BD compliant for authoring software without a need to transcode?

[LigH.de]

I don't have any player or authoring tool, so I am not sure; if I followed the doom9 forum discussion involving a spec verifier well, I believe it is not yet done, there is an issue left regarding the structure of open GOPs (the number of contained frames may get counted beyond the maximum of allowed frames per GOP). And there may be still undetected issues... who knows. The number of available devices and authoring software is small. But if you set x265 up to comply with specified ranges and use only closed GOPs, the result should already be very compatible.

[LigH.de]

x265 1.9+140-34a3d35c5f97: UHD-BD compatibility forces closed GOPs; --limit-refs clarified to be on/off; and a bunch of fixes and speed-ups (ARM implementations don't matter for x86 platform)

[LigH.de]

x265 1.9+150-00ea3784bd36: Unicode filenames support for output and stats; and some rate control improvements

[LigH.de]

x265 1.9+167-bebae72f9db7 provides a few changes regarding the grain handling, and a new tweak:

   --[no-]recursion-skip         Enable early exit from recursion. Default enabled

[LigH.de]

x265 1.9+183-4723933fdec9: --slow-firstpass is now enabled as default; quantization is clipped in 2-pass with grain tuning; --qpfile and --csv support Unicode too.