[HEVC] x265.EXE: mingw builds

[Selur]

Totally missed that, thanks.

[LigH.de]

Another "weekly" again: x265 1.5+258-6461985f33ac

[LigH.de]

Next: x265 1.5+370-cc496665280f

[LigH.de]

Out-of-schedule, here are some additional builds, experimenting with jb_alvarado's media-autobuild_suite.

x265_1.5+420-24fdb661bb57.7z (MSYS, MinGW32, GCC 4.8.2, package from xhmikosr + 4x cross compile script, EXE+DLL)
x265_1.5+420-24fdb661bb57.GCC492.7z (MSYS2, MinGW64, GCC 4.9.2, media-autobuild_suite, EXE only, stripped and UPX'ed)

[LigH.de]

Another weekly, stable merge build.

x265 1.5+448-22a312799bb0 (GCC 4.8.2 EXE + DLL)
x265 1.5+448-22a312799bb0 (GCC 4.9.2 UPX-EXE)

It seems that the x265 project will allow easier configuring for native architecture optimized builds. If I would enable this feature, my builds would probably still be generated for SSE2 or SSE3, using AMD K10 architecture (Phenom-II). I did not yet change my workflow.

[Gravitator]

Does it make sense CBR mode for 2-pass encoding?

[sneaker]

No

[LigH.de]

Belated Happy Easter:

x265 1.6+85-e0523096bb21 (stable merge)
x265 1.6+117-095ed87526e5 (with "implementation of fine grained adaptive quantization")

Furthermore, some spring-cleaning (removing v1.3 archives).
__

P.S.: trying to add --qgsize 16 to the parameter set, I get only a syntax help page as error result, instead of an encode.

P.P.S.: My fault, insert another hyphen: --qg-size

[LigH.de]

x265 1.6+174-4cccf22b00ee

Supports a switch for the "Annex B" format internally, which may be interesting for builds supporting already multiplexed outputs. Raw HEVC video shall always be formatted according to Annex B, I was told.

Coming builds may require a decision to be either compatible to Vista without — or to Win7+ with support for NUMA thread pools. May my Win32 builds be XP compatible (and without much use for multi-socket encoding anyway), but my Win64 builds will then probably prefer Win7+ compatibility with NUMA support.

[LigH.de]

x265 1.6+239-5c3443546ccc

News: Support for SMPTE ST 2086 (HDR / Wide Gamut display metadata) and piping reconstructed video to a Y4M viewer.

[LigH.de]

x265 1.6+298-4a7176bab742

New published parameter:

   --qpstep <integer>            The maximum single adjustment in QP allowed to rate control. Default 4

[LigH.de]

Another weekly: x265 1.6+332-c4d9ee2cef03

[Selur]

@LigH: did you do anything specific to make your 32bit builds Windows XP compatible? see: https://github.com/jb-alvarado/media-autobuild_suite/issues/85

[LigH.de]

Nothing special. GCC 4.8.2 in MSYS package prepared by XhmikosR.

~/rebuild_x265.sh

#!/bin/sh
cd x265/build/msys
make clean-generated
cmake -G "MSYS Makefiles" -DWINXP_SUPPORT:BOOL=TRUE ../../source
make
/mingw/bin/strip.exe x265.exe
/mingw/bin/strip.exe libx265.dll
cd ../msys_hbd
make clean-generated
cmake -G "MSYS Makefiles" -DWINXP_SUPPORT:BOOL=TRUE -DHIGH_BIT_DEPTH:BOOL=TRUE -DENABLE_ASSEMBLY:BOOL=FALSE ../../source
make
/mingw/bin/strip.exe x265.exe
/mingw/bin/strip.exe libx265.dll
cd ../msys64
make clean-generated
cmake -G "MSYS Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake ../../source
make
/mingw/x86_64-w64-mingw32/bin/strip.exe x265.exe
/mingw/x86_64-w64-mingw32/bin/strip.exe libx265.dll
cd ../msys64_hbd
make clean-generated
cmake -G "MSYS Makefiles" -DCMAKE_TOOLCHAIN_FILE=toolchain-x86_64-w64-mingw32.cmake -DHIGH_BIT_DEPTH:BOOL=TRUE ../../source
make
/mingw/x86_64-w64-mingw32/bin/strip.exe x265.exe
/mingw/x86_64-w64-mingw32/bin/strip.exe libx265.dll

[LigH.de]

A new "merge with stable" to prepare a coming v1.7 era: x265 1.6+412-b642b3d8cc1e

Also support for "content light level" (HDR SEI info).

[Selur]

btw. has anyone tried the patched builds from VTT ?
- Patch to enable high bit depth for 32-bit target
- Patch that adds missing aligment declaration
see: http://vtt.to/refined%20x265%20builds

[LigH.de]

If these alignment declarations are generally useful, this patch should have been offered to the main repository.

[LigH.de]

x265 1.6+417-f2081ef64fd2 publishes a switch to select the output (and internal) bit depth at run time:

-D/--output-depth 8|10           Output bit depth (also internal bit depth). Default {8|10}

Default depth depends on the compile options.

Now I wonder: If a 64 bit executable should support both 8 and 10 bit depths, shouldn't the building process create "more or less identical" binaries containing both code groups, so that switching between 8 and 10 bit depths at run time is at all possible? But normal and HBD builds still differ (DLLs as well as EXEs). I doubt this works as desired (but not tested yet...).

This package has also DETAILED_CU_STATS enabled.
__

P.S.: The documentation reads like it doesn't have to. If a specific depth is unsupported (because not linked in), it seems to fall back to a supported one. I guess that a dynamic EXE linking both 8 and 10 bit DLLs would be an easier way to make a CLI encoder supporting both at run time?

[x265]

The -D switch allows you to build a High Bit Depth DLL, calling it libx265_main10.dll and placing it alongside your 8 bit x265.exe. With this "package" the x265 command line interface can dynamically choose either Main or Main10 profiles (if you add "-D 10" to your command line), and it will use either the 8 bit library (built into x265.exe), or the high bit depth build (in the DLL).

[LigH.de]

On the occasion of the new milestone:

x265 1.7+2-d7b100e51e82

Please note: Contains different file names, starting with v1.7, to be more easily compliant with the new Multi-library Interface.
__

P.S.: Additional MSYS2-64 GCC 4.9.2 build, each one pair only (8-bit EXE + 10-bit DLL), as built with media-autobuild_suite by jb_alvarado

[LigH.de]

Must have forgotten the last one. So today, two releases.

x265 1.7+37-dc4fcfc574ad
—

[LigH.de]

x265 1.7+95 removed in favour of 1.7+96:

api: fix for crash in x265_api_query caused by function type casting error

In x265_api_query, after retrieving the function pointer of x265_api_query from external DLL, it is then incorrectly type cast into x265_api_get function, the patch is intended for this fix.

x265 1.7+96-093618ce0b26

[LigH.de]

Current builds appear to be really a lot bigger, especially 16bpp binaries (EXE: 3.3 => 4.6 MB; DLL: 2.9 => 4.1 MB; each about +1.2 MB). Furthermore, the "full help" output shrunk to 70% of its previous amount.

x265 1.7+166-32590b25678b

P.S.: Compressed with 7-zip 15.05 beta; please check if you can unpack even with slightly older versions (but min. 9.20 beta).

[LigH.de]

Because "merge with stable":

x265 1.7+180-d6c32960b5df

[LigH.de]

Weekly (with a just even fixed typo in the XP compatible X265 Name Space refactoring):

x265 1.7+207-83a7d8244424

[LigH.de]

A first release with "multilib" EXE: x265 1.7+234-b1af4c36f48a

[LigH.de]

Weekly: x265 1.7+257-483c85f83f07

[LigH.de]

"Merge with stable" and working CPU features identification for alternative encoder libraries (i.e. -D 10 -V warns about "noasm" option for Win32 builds in multilib EXE as well as 8-bit EXE with 10-bit DLL):

x265 1.7+266-68d089360477 (GCC 4.8.2)
x265 1.7+266-68d089360477 (GCC 4.9.2)

[LigH.de]

WARNING! HIGHLY EXPERIMENTAL!

x265 1.7+282-1867f1703846 (GCC 4.9.2) containing separate EXE and DLL files as well as a multilib EXE (possible by manually patching listfile.rsp) with 8 bit + 10 bit + 12 bit encoder

In addition, some new samples with a downscaled "L4D2 Fireworks" clip (640x360) in 8 / 10 / 12 bit encoding resolution.

LAV Filters can't play the 12 bit sample correctly. I guess it is not yet supported?

[Selur]

LAV Filters can't play the 12 bit sample correctly. I guess it is not yet supported?

afaik no decoder supports 12bit atm. (same for 16 bit), so to compare these you probably will have to output a y4m file.