[HEVC] x265.EXE: mingw builds

[LigH.de]

You should abandon x26*vfw, and you should abandon the belief that the AVI container is suitable to contain AVC or HEVC video.

If you insist in using VirtualDub as converter application, use it with its "external encoder" feature, this will support any x265.exe to create raw HEVC video, and a multiplexer like MP4Box, L-SMASH, or mkvmerge.

[skylinekiller]

Ligh,

so if I choose to abandon x26*vfw what road do you recommend me travel down? I am not the smartest person when it comes to encoding, but i am a little familiar with the apps and lingo. I know this is opening padora's box, but I am up to getting up to speed on a newer method as I have encoded over 8TBs of movies

[LigH.de]

There are a lot of converting tools. Some are based on ffmpeg, others are based on AviSynth. You can find threads about StaxRip, MeGUI, Hybrid, Handbrake, VidCoder, etc. - But this thread is about MinGW builds of x265, not about tools using them.

[LigH.de]

x265 2.2+22-20217c8af8ac

Scalinglists support for 4:4:4 videos + fixes for ssim-rd and others

[Aludin]

I'm not noticing any quality increases since like 1.8. The speed has gotten slower for what exactly? Picture is the same.

[LigH.de]

This is not the best matching thread for this kind of question. Try the general one or make a new one. And document your parameters in detail.

[LigH.de]

x265 2.2+30-fa52b516f5ff

   --complex-analysis <0..4.0>   Strength of complex analysis, 0 to disable. Default 0.0

Increases the RD-level at points where the bitrate drops due to vbv. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.

A developers' functionality test runs with strength 1.53, FYI.

[LigH.de]

x265 2.2+36-9b975fec584a

--complex-analysis is now --dynamic-rd, and you can now manually control HDR SEI packets

Exchanged v2.2+35 with v2.2+36, it's a "merge with stable"

[LigH.de]

New milestone (stable merge build): x265 v2.3

x265 2.3+2-912dd749bdb5 (mostly identical to v2.2+36)

[LigH.de]

x265 2.3+7-c15f8bce9f4b [Windows][GCC 6.3.0][32+64 bit] 8bit+10bit+12bit

Luma/Chroma(fixed) offsets for HDR/WCG content, and some more Unicode support for filenames in Windows builds. New CLI parameters:

   --capture-csp <string>        Specify color primaries from bt709, p3d65, bt2020 for the capture device. Default bt709
   --[no-]hdr-opt                Add luma and chroma offsets for HDR/WCG content. Default disabled

[LigH.de]

x265 2.3+17-6e348252e902

Now even finer!

  --refine-level <1..10>        Level of analyis refinement indicates amount of info stored/reused in save/load mode, 1:least....10:most. Default 5

^typo (analy»s«is) already reported...

Not available anymore:

   --capture-csp <string>        Specify color primaries from bt709, p3d65, bt2020 for the capture device. Default bt709

[Brazil]

Erm, no build anymore ?

[Selur]

Why should there be?
Looking at the change log:
- multi-level refinement: fix typo and missing space => only useful to codec developers
- regression: include test for refine levels => only useful to codec developers
- multi-level: increase maximum level from 5 to 10 => only useful to codec developers
=> nothing happened that is useful to a normal user (most of last few changes were mainly for codec developers&co)

[Brazil]

OK then, I've just seen there was a new version here: https://www.videohelp.com/software/x265-Encoder

But I prefer all-in-one (8 bits to 12 bits) GCC builds as they are faster, at least on my system.

[LigH.de]

I build new versions only when features change. Not just when a typo got fixed or only the documentation got enhanced (that does not change the code at all, only increases the patch number).

[Marsia Mariner]

x265.exe 2.3+22-db5e22b856f5
(GCC 6.3.0, 64-bit, multilib)

[Marsia Mariner]

x265.exe 2.3+28-08a05ca9fd16
(GCC 6.3.0, x64, multilib)

Fix artifacts issue in multi-pass-opt-distortion with VBV

[Marsia Mariner]

{{
deleted Deleted DELETED
}}

[LigH.de]

CLI: informs if '--ssim-rd' is used;
Add dynamic rate-control reconfiguration (API only);
Improved sao implementation by limiting sao types:

   --[no-]limit-sao              Limit Sample Adaptive Offset types. Default disabled

x265 2.3+32-1ed218717877

x265 2.3+28-08a05ca9fd16 (belated)

[Marsia Mariner]

x265.exe 2.3+40-2c6e6c9c3da7

Merge with default, prep for 2.4

http://www.mediafire.com/file/iymx3l6rjmyttv4/x265_2.3+40-2c6e6c9c3da7.7z

[LigH.de]

I tried to enable Dynamic HDR10 routines for compilation with GCC 6.3.0, but C++11 compatibility is missing in the current CMake scripts. Release postponed...

[Marsia Mariner]

^ The HDR10+ stuff seems to be very-useless for the time being...
And as LigH pointed out, it was not implemented correctly.
It's disabled by default in the main CMakeLists.txt.

For the "normal" users of x265, the new 10-bit and 12-bit lambda2 table is more relevant than the (non-existent) HDR10+ support.

[Marsia Mariner]

x265.exe 2.4+2-5bc5e73760cd

Release Notes for Version 2.4
======================

Release date - 22nd April, 2017.

Encoder enhancements
----------------------------------
1. HDR10+ supported. Dynamic metadata may be either supplied as a bitstream via the userSEI field of x265_picture, or as a json file that can be parsed by x265 and inserted into the bitstream; use --dhdr10-info to specify json file name, and --dhdr10-opt to enable optimization of inserting tone-map information only at IDR frames, or when the tone map information changes.
2. Lambda tables for 8, 10, and 12-bit encoding revised, resulting in significant enhancement to subjective visual quality.
3. Enhanced HDR10 encoding with HDR-specific QP optimizations for chroma, and luma planes of WCG content enabled; use --hdr-opt to activate.
4. Ability to accept analysis information from other previous encodes (that may or may not be x265), and selectively reuse and refine analysis for encoding subsequent passes enabled with the --refine-level option.
5. Slow and veryslow presets receive a 20% speed boost at iso-quality by enabling the --limit-tu option.
6. The bitrate target for x265 can now be dynamically reconfigured via the reconfigure API.
7. Performance optimized SAO algorithm introduced via the --limit-sao option; seeing 10% speed benefits at faster presets.

API changes
-------------------
1. x265_reconfigure API now also accepts rate-control parameters for dynamic reconfiguration.
2. Several additions to data fields in x265_analysis to support --refine-level: see x265.h for more details.

Bug fixes
--------------
1. Avoid negative offsets in x265 lambda2 table with SAO enabled.
2. Fix mingw32 build error.
3. Seek now enabled for pipe input, in addition to file-based input
4. Fix issue of statically linking core-utils not working in linux.
5. Fix visual artifacts with --multi-pass-opt-distortion with VBV.
6. Fix bufferFill stats reported in csv.

[LigH.de]

The long awaited:

x265 2.4+6-fd01abfc7898 (merge with stable) contains an additional multi-lib EXE with Dynamic HDR10 enabled.

[Marsia Mariner]

x265.exe 2.4+9-7ecd263f6d43

(GCC 7.1.0, Dynamic HDR10, multilib, x64)

[Marsia Mariner]

x265.exe 2.4+14-bc0e9bd7c08f

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

[Marsia Mariner]

x265.exe 2.4+22-c102c809fc4f

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

[LigH.de]

x265 2.4+22-c102c809fc4f

adds CTUInfo API (seems to be a debug feature, quite time consuming) and an AVX2 framework of integral functions to speed up SEA motion search.

[Marsia Mariner]

adds CTUInfo API (seems to be a debug feature, quite time consuming) and an AVX2 framework of integral functions to speed up SEA motion search.

Straight from the x265 devs themselves:

[LigH.de]

Netscape Navigator?!