[HEVC] x265.EXE: mingw builds

[LigH.de]

Huuuge THX

[LigH.de]

Trying to switch from MSYS (XhmikosR) to MSYS2 (MABS); it's not so simple, using separate runs in MinGW32 and MinGW64 as workaround for now to avoid patching the cross compilation toolchain file.

x265 2.5+27-0e168bdeb48b (GCC 7.2.0)

[LigH.de]

x265 2.5+31-df2de6ea407d

Support for more monochrome video source formats; plus a few fixed nits.

[Marsia Mariner]

x265.exe 2.5+37-aa9649a2aa8c

µchangelog:

api: 'x265_get_slicetype_poc_and_scenecut' to fetch slicetype, poc and scenecut information

api: 'x265_get_ref_frame_list' to get forward and backward refrence list

Implementation of low-pass subband dct approximation.

doc/test: Add lowpass test, remove/add experimental labels to some features.

Add vbv-end to denote VBV emptiness after inserting all the frames into it.

[LigH.de]

x265 2.5+47-6a882a9300c2

Speed-ups, API changes, more internal analysis features, new CLI parameters:

   --vbv-end <float>             Final VBV buffer emptiness (fraction of bufsize or in kbits). Default 0 (disabled)
   --vbv-end-fr-adj <float>      Frame from which qp has to be adjusted to achieve final decode buffer emptiness. Default 0
   --lowpass-dct                 Use low-pass subband dct approximation. Default disabled
   --refine-mv-type <string>     Reuse MV information received through API call. Supported option is avc. Default disabled - 0

Docs: refine-mv-type, vbv-end

[Marsia Mariner]

x265.exe 2.5+54-6ac1b12bcde9

Encoder: avoid blocking in getEncodedPicture() for zero latency when multiple slices are enabled
Improved performance by 10 - 15 fps depending upon preset and number of slices.

[LigH.de]

^ please note that this is a real-time encode scenario, not a high-quality one.

[LigH.de]

x265 2.5+55-dd9772385d15

Add CLI option to enable or disable picture copy to internal frame buffer

   --[no-]copy-pic               Copy buffers of input picture in frame. Default enabled

Allow encoder to copy input x265 pictures to internal frame buffers. When disabled, x265 will not make an internal copy of the input picture and will work with the application's buffers. While this allows for deeper integration, it is the responsbility of the application to (a) ensure that the allocated picture has extra space for padding that will be done by the library, and (b) the buffers aren't recycled until the library has completed encoding this frame (which can be figured out by tracking NALs output by x265)

I can imagine that when x265 is linked inside an application or as DLL; but how is that supposed to work for x265 as a separate CLI application? I doubt it would have access to memory pointers of a calling application.
__

P.S.:

As far as I hope to understand, it may not be helpful to the pure x265 CLI encoder, but possibly to other applications derived from this structure, configuring itself internally with a CLI parameter string as well.

[LigH.de]

x265 2.5+65-a7c2f80c18af

Disable opt-qp-pps and opt-ref-list-length-pps by default; use AVC CU analysis data in anlysis-reuselevel 7 and 8; update an outdated help message for --bframes

[LigH.de]

Should have waited one more day...

x265 2.5+66-dae558b40d99

merge with stable + fixed compiler warning (parentheses)

Milestone v2.6 is in sight!

[Marsia Mariner]

x265.exe 2.6+2-32e6f04b8713

What's New:

x265 version 2.6 is now out! The key new improvements include support for segmented encoding, and introducing the ability of x265 to reuse and refine analysis from previously done HEVC and AVC encodes. The tarball of this release can be downloaded from the downloads page.

Release date - 29th November, 2017.
============================

New features
------------------
1) x265 can now refine analysis from a previous HEVC encode (using options --refine-inter, and --refine-intra), or a previous AVC encode (using option --refine-mv-type). The previous encode’s information can be packaged using the x265_analysis_data_t data field available in the x265_picture object.
2) Basic support for segmented (or chunked) encoding added with --vbv-end that can specify the status of CPB at the end of a segment. String this together with --vbv-init to encode a title as chunks while maintaining VBV compliance!
3) --force-flush can be used to trigger a premature flush of the encoder. This option is beneficial when input is known to be bursty, and may be at a rate slower than the encoder.
4) Experimental feature --lowpass-dct that uses truncated DCT for transformation.

Encoder enhancements
--------------------------------
1) Slice-parallel mode gets a significant boost in performance, particularly in low-latency mode.
2) x265 now officially supported on VS2017.
3) x265 now supports all depths from mono0 to mono16 for Y4M format.

API changes
-----------------
1) Options that modified PPS dynamically (--opt-qp-pps and --opt-ref-list-length-pps) are now disabled by default to enable users to save bits by not sending headers. If these options are enabled, headers have to be repeated for every GOP.
2) Rate-control and analysis parameters can dynamically be reconfigured simultaneously via the x265_encoder_reconfig API.
3) New API functions to extract intermediate information such as slice-type, scenecut information, reference frames, etc. are now available. This information may be beneficial to integrating applications that are attempting to perform content-adaptive encoding. Refer to documentation on x265_get_slicetype_poc_and_scenecut, and x265_get_ref_frame_list for more details and suggested usage.
4) A new API to pass supplemental CTU information to x265 to influence analysis decisions has been added. Refer to documentation on x265_encoder_ctu_info for more details.

Bug fixes
-------------
1) Bug fixes when --slices is used with VBV settings.
2) Minor memory leak fixed for HDR10+ builds, and default x265 when pools option is specified.
3) HDR10+ bug fix to remove dependence on poc counter to select meta-data information.

[LigH.de]

x265 2.6+2-32e6f04b8713

[ador250]

do u guys have any tutorial about how to compile x265 with visual studio ?
I installed THIS but don't know what to do next.

[Marsia Mariner]

To whom this may interest...
latest x265 version is 2.6+5 — no substantial difference from the 2.6+2 release, but now x265 requires nasm instead of yasm to be compiled "properly".
Reason for the change: nasm supports AVX-512, whereas yasm does not.
Problem: nasm is much slower than yasm.
It would be interesting if the x265 devs themselves patched nasm to make it fast. OR, perhaps, they could add AVX-512 support to yasm...

Anyway: according to what I found through Google, people have been complaining about nasm's slowness since ages ago

[LigH.de]

I do remember that yasm increased its speed from 1.2 to 1.3 by expanding internal buffers. I doubt that speeding up nasm would be just as simple.

But I also remember that the developers already explained in the doom9 forum that enhancing yasm for AVX-512 support would not be worth the efforts of contributors, they said that the support of AVX-512 requires quite a lot of different processing of instructions, compared to previous instruction sets. So yasm is abandoned. And speeding up nasm would mainly be the task of nasm developers (who may enjoy contributions, but I would assume it is surely not another task for Multicoreware, they have their own schedule).

Don't cry about 5 minutes per week or two. How often do you really need a fresh build?

[Marsia Mariner]

Don't cry about 5 minutes per week or two. How often do you really need a fresh build?

Not a direct answer to your question, but...

With yasm, a multilib 64-bit build of x265.exe takes around 15 minutes (that is to say, about 5 minutes per "section" — 8-bits + 10-bits + 12-bits) on my Q8400.

With nasm, I still haven't found the patience to measure it — probably the E.T.A. will be somewhere between 12 minutes x 3 = 36 minutes and 20 minutes x 3 = 1 hour...
but I admit that this is just a wild guess.

[LigH.de]

So bad? ... Hmm, I have only an AMD Phenom-II available. Not sure if it runs multi-threaded. But you are right: The 32-bit build takes 14 min, the 64-bit build takes 36 min. Quite a difference. But well ... I can do other things in the meantime, it's semi-automatic. The only issue under Windows is that terminating processes stays in critical sections for a while, the longer the more cores you have. And make tools as well as GNU compilers seem to spawn and terminate processes a lot.
_

@ador250:

No experience here, but according to https://bitbucket.org/multicoreware/x265/wiki/Home it should not be too hard...

Windows (Visual Studio) Instructions

$ hg clone https://bitbucket.org/multicoreware/x265

Then run make-solutions.bat in the build\ folder that corresponds to your favorite compiler, configure your build options, click 'configure', click 'generate', then close cmake-gui. You will be rewarded with an x265.sln file. Also see cmake documentation.

[Marsia Mariner]

So bad? ... Hmm, I have only an AMD Phenom-II available. Not sure if it runs multi-threaded. But you are right: The 32-bit build takes 14 min, the 64-bit build takes 36 min. Quite a difference. But well ... I can do other things in the meantime, it's semi-automatic. The only issue under Windows is that terminating processes stays in critical sections for a while, the longer the more cores you have. And make tools as well as GNU compilers seem to spawn and terminate processes a lot.

Okay, I disrespected my lack of patience and let the new asm code do its new "magic"... my Q8400 needed 40 minutes to compile the new x64 multilib x265.exe. If I had followed qyot27's advice and entered "make --jobs=4", probably the 40 minutes would be reduced to 36... But if I had to use a Pentium 4 (like in 2013), certainly the 40 minutes would become 2 hours

</END OF COMPLAINT>

[Marsia Mariner]

x265.exe 2.6+8-fc0570b8d8f9
(GCC 7.2.0, nasm 2.13.02)

[LigH.de]

x265 2.6+14-f09f3b4a2115

New options:

   --fullhelp                    Show all options and exit
   --gop-lookahead <integer>     Extends gop boundary if a scenecut is found within this from keyint boundary. Default 0

[LigH.de]

x265 2.6+24-69cfe46e8a3b – merge with stable

Several fixes e.g. in analysis and VBV handling; added support for RADL pictures; renamed options:

   --radl <integer>              Number of RADL pictures allowed in front of IDR. Default 0

(  --analysis-reuse-mode <string|int>  removed )
   --analysis-save <filename>    Dump analysis info into the specified file. Default Disabled
   --analysis-load <filename>    Load analysis buffers from the file specified. Default Disabled

[LigH.de]

x265_2.6+31-3712d13c09bf

• important stability fix when using very verbose parameters like zones and additional files (could exceed a too small internal buffer)
• input: change from ifstream to stdio stream
• change date to 2018 in output file header

[Marsia Mariner]

x265.exe 2.6+37-1949157705ce

[LigH.de]

Mine delay a bit. There are broken binutils in the latest update with GCC 7.3.0, leaving "(null)" in the build ID strings.

[LigH.de]

After re-installing MABS completely, which updated only to binutils-2.29, version strings are back. Other important changes:

32-bit builds made with GCC can open large files too; MinGW compiles exclude some superfluous libraries; fixes in special conditions with BREF frames, rate control with both weightp and cutree, and unnecessary luma calculations in CSV output

x265 2.6+37-1949157705ce (MSYS2/MinGW, GCC 7.3.0)

[LigH.de]

MSYS2 released binutils-2.30-2; static binaries should work again.

[LigH.de]

x265 2.6+39-01b685d6fa33

CMake: fix generation of version info from .hg_archival.txt; fix output to pipe on Windows (enable binary mode)

[LigH.de]

New upload: x265 2.7+1-2aa737a99f51

limitTU: Save intra CU's TU depth when analysis save/load is enabled; dHDR10 parsing fixes; ipfilter kernels split into several separate source files; v2.7 milestone

[Marsia Mariner]

x265.exe 2.7+8-613d9f443769

remove maxCTU size restriction in scaled save/load encodes

analysis: Introduce refine-intra level 4

use MV from analysis-save encode as MVP in load mode for refine-inter levels

Add max-ausize-factor option to control the maximum AU size defined in specification

Add reorderedPts to x265_picture to signal the reordered pts value of each picture in encode order.
Also shared the reordered pts value when analysis load is done by disabling lookahead.

[LigH.de]

#metoo

x265 2.7+8-613d9f443769