[HEVC] x265.EXE: mingw builds

[Marsia Mariner]

@LigH:

https://addons.mozilla.org/en-US/firefox/addon/titlebar-tweaks/

But obviously only Seamonkey deserves to be called «NETSCAPE(5)»

[LigH.de]

But also a matching UI theme. And disabled anti-aliasing in the menu font. Well, nice disguise.

Back to topic.

[Marsia Mariner]

x265.exe 2.4+24-afdca6b5f90d

4b846d3     rcStats: add more fields to rcStats

afdca6b     rc: Use RcStats information if available from pic_in

[Marsia Mariner]

x265.exe 2.4+36-de49a722b256

Changes since commit f850cdb: https://bitbucket.org/multicoreware/x265/commits/all

[LigH.de]

x265 2.4+36-de49a722b256

New parameters:

   --scale-factor <int>          Specify factor by which input video is scaled down for analysis save mode. Default 0
   --[no-]refine-intra           Enable intra refinement for load mode. Default disabled
   --[no-]refine-inter           Enable inter refinement for load mode. Default disabled

[Selur]

These are all for the analysis mode and not for actual encoding right?

[LigH.de]

x265 2.4+41-82ba8c85f8e9

AVX2 speedup for integral4h; add support for hdr-opt even when aq-mode is disabled; moved CSV feature into libx265; fix slicetype mismatch between analysis save and load modes

[LigH.de]

x265 2.4+61-28bbc349d170 (GCC 6.3.0)
x265 2.4+61-28bbc349d170 (GCC 7.1.0)

major overhaul of x86inc assembler routines (in sync with those in x264)

[Marsia Mariner]

OFF-TOPIC:

@LigH: do you have any good reason to NOT upgrade to GCC 7.1?

XhmikosR updated his MSYS1 bundles last week.

[LigH.de]

Only that I was not told about it until today. I do not check his site daily...

[Marsia Mariner]

https://forum.doom9.org/showthread.php?p=1808689#post1808689

[LigH.de]

OK, will add it later ^ above. / Done.

This set of patches is intended update x86inc.asm file. This synchronises x86inc with that of x264.

[LigH.de]

x265 2.4+75-80c23559084c (GCC 6.3.0)
x265 2.4+75-80c23559084c (GCC 7.1.0)

mostly improvements for SEA integral calculations with AVX2 assembly; some tidy-up.

Note: make directive "ENABLE_DYNAMIC_HDR10" is now renamed to "ENABLE_HDR10_PLUS"

Attention: New archive structure! (May change next time again, it feels bloated already... what to omit, what to keep?)
_

libhdr10plus.dll — separate DLL to handle Dynamic HDR10+ definitions in JSON format (possibly to be used by a custom application, used in parallel to a libx265.dll?)

libx265_main.dll — DLL with 8 bit precision x265 encoder core, to be used by a custom application or another x265 CLI, Dynamic HDR10+ support disabled
libx265_main10.dll — DLL with 10 bit precision x265 encoder core, to be used by a custom application or another x265 CLI, Dynamic HDR10+ support disabled
libx265_main12.dll — DLL with 12 bit precision x265 encoder core, to be used by a custom application or another x265 CLI, Dynamic HDR10+ support disabled
libx265.dll — multi-library DLL with 8+10+12 bit precision x265 encoder cores, to be used by a custom application, Dynamic HDR10+ support disabled

x265_main.exe — CLI application with 8 bit precision x265 encoder core (can use DLLs with different precisions), Dynamic HDR10+ support disabled
x265_main10.exe — CLI application with 10 bit precision x265 encoder core (can use DLLs with different precisions), Dynamic HDR10+ support disabled
x265_main12.exe — CLI application with 12 bit precision x265 encoder core (can use DLLs with different precisions), Dynamic HDR10+ support disabled
x265_ml.exe — multi-library CLI application with 8+10+12 bit precision x265 encoder cores (needs no other DLLs), Dynamic HDR10+ support disabled

HDR10plus\libx265.dll — multi-library DLL with 8+10+12 bit precision x265 encoder cores, to be used by a custom application, Dynamic HDR10+ support enabled
HDR10plus\x265_ml.exe — multi-library CLI application with 8+10+12 bit precision x265 encoder cores (needs no other DLLs), Dynamic HDR10+ support enabled
_

I don't see any reference to the libhdr10plus.dll in any x265 CLI or DLL when built with Dynamic HDR10+ disabled, so I doubt that they will be able to support it simply because the libhdr10plus.dll resides in the same directory (similar to supporting a core with different precision); I guess that if you want Dynamic HDR10+ to be supported, you have to use an enabled build, but then it will already contain the code, so there is no obvious need for that separate DLL, at least for [lib]x265; maybe for a custom application handling both tasks separately.

I did not yet try to discover if it is possible to build a mostly dynamically linked package with Dynamic HDR10+ support, consisting of one CLI and all the rest as DLLs, with the libhdr10plus.dll still separated... I would assume that its code would be included in the CLI or DLLs at least once, if not everywhere.

As a GUI author using any x265 CLI, I assume you would prefer using only the HDR10plus\x265_ml.exe (All-In-One build) as x265.exe called by your GUI.

[Marsia Mariner]

x265.exe 2.4+87-5f2330bdb8fa

[LigH.de]

x265 2.4+87-5f2330bdb8fa (GCC 6.3.0)
x265 2.4+87-5f2330bdb8fa (GCC 7.1.0)

merge with stable; several renames, optimizations, refinements... most obvious CLI changes:

   --analysis-reuse-mode <string|int>  save - Dump analysis info into file, load - Load analysis buffers from the file. Default 0
   --analysis-reuse-file <filename>    Specify file name used for either dumping or reading analysis data. Deault x265_analysis.dat
   --analysis-reuse-level <1..10>      Level of analysis reuse indicates amount of info stored/reused in save/load mode, 1:least..10:most. Default 5

   --[no-]refine-mv              Enable mv refinement for load mode. Default disabled

   --[no-]const-vbv              Enable consistent vbv. turned on with tune grain. Default disabled

[Marsia Mariner]

x265.exe 2.4+93-ef8dfbb70dd6

[Marsia Mariner]

x265.exe 2.4+96-58b4fa89c42d

compiled by Barough @ doom9-dot-org

http://ge.tt/3FD54al2

[LigH.de]

x265 2.4+96-58b4fa89c42d (GCC 7.1.0, Win32+Win64, AIO EXE+DLL only)

merge with stable; several fixes and tweaks

renamed / changed / new CLI options:

   --analysis-reuse-mode <string|int>  save - Dump analysis info into file, load - Load analysis buffers from the file. Default 0
   --analysis-reuse-file <filename>    Specify file name used for either dumping or reading analysis data. Deault x265_analysis.dat
   --analysis-reuse-level <1..10>      Level of analysis reuse indicates amount of info stored/reused in save/load mode, 1:least..10:most. Default 5

   --refine-intra <int>          Enable intra refinement for load mode. Default 0

   --[no-]const-vbv              Enable consistent vbv. turned on with tune grain. Default disabled

[LigH.de]

Not really sure what you want to hide ... I guess: --no-info

Emit an informational SEI with the stream headers which describes the encoder version, build info, and encode parameters. This is very helpful for debugging purposes but encoding version numbers and build info could make your bitstreams diverge and interfere with regression testing. Default enabled

[Marsia Mariner]

x265.exe 2.4+97-006c75cf822e

Aruna Matheswaran  committed 006c75c
2017-06-22

Allocate frame threads based on available pool threads

This patch decides #frame-threads based on #pool-threads available. If pools not
specified, #frame-threads will be decided based on detected #CPU-threads.

This patch also decreases #frame-threads allocated for #pool-threads in the
interval (15 - 31) and (>= 32) as there is high run to run variation in bitrate
and SSIM with higher frame threads.With this reduction in #frame-threads there
is ~3-4 % drop in fps with little SSIM improvement for #pool-threads (15 - 31)
and no significant change in performance for #pool-threads (>= 32).

[LigH.de]

x265 2.4+99-3160e1a0cc5f (merge stable+default)

"Allocate frame threads based on available pool threads" ... + a Mac fix and preps for v2.5 milestone.

[LigH.de]

x265 2.5+2-18fa144d453e (merge with stable; new v2.5 milestone)

SEI payload message writing fixed

[Marsia Mariner]

x265.exe 2.5+6-d11482e5fedb

[LigH.de]

x265_2.5+6-d11482e5fedb (merge with stable)

fixes two memory leaks (threading, HDR10+), improves encoder reconfiguration, and allows forced output flushing:

   --force-flush <integer>       Force the encoder to flush frames. Default 0
                                 0 - flush the encoder only when all the input pictures are over.
                                 1 - flush all the frames even when the input is not over. Slicetype decision may change with this option.
                                 2 - flush the slicetype decided frames only.

I guess this is mainly interesting for scenarios with changing parameters where a quick response is required?

[LigH.de]

x265 2.5+8-eea2afb81ef2

New modes for --refine-intra and --refine-inter

[LigH.de]

x265 2.5+11-d58761d8db4a

supports some new SMPTE-ST/RP/EG colorimetry options and a new split RD skip command* (documented only in full help):

   --[no-]splitrd-skip           Enable skipping split RD analysis when sum of split CU rdCost larger than none split CU rdCost for Intra CU. Default disabled

   --colorprim <string>          Specify color primaries from undef, bt709, bt470m, bt470bg, smpte170m,
                                 smpte240m, film, bt2020, smpte-st-428, smpte-rp-431, smpte-eg-432. Default undef

   --colormatrix <string>        Specify color matrix setting from undef, bt709, fcc, bt470bg, smpte170m,
                                 smpte240m, GBR, YCgCo, bt2020nc, bt2020c, smpte-st-2085, chroma-nc, chroma-c, ictcp. Default undef

* If I understood the patch comment in the mailing list correctly, it should speed up intra split cost calculation a little while possibly preserving identical output.

[LigH.de]

x265 2.5+14-2718cb5dd67f (merge with stable)

cli: Align color primaries names to ffmpeg; Re-evaluate vbv lookahead in the encode that uses --analysis-reuse-mode load

[Marsia Mariner]

x265.exe 2.5+20-0967d0add97e

https://bitbucket.org/multicoreware/x265/commits/all

[LigH.de]

x265 2.5+22-8db95a1da9f8 (MSYS/MinGW, GCC 7.1.0) ... does XhmikosR still update?

Fixes for analysis load, WPP, bitstream payload size, VBV hanging; new (internal?) parameter for disabling lookahead; Windows DLL will export x265_encoder_ctu_info()

[Marsia Mariner]

(MSYS/MinGW, GCC 7.1.0) ... does XhmikosR still update?

Good question But while he doesn't, you might give a try to the archive below.
Nothing special, I just downloaded his latest MSYS1 package and replaced the contents of the mingw directory with nevcairiel's GCC 7.2