[HEVC] x265.EXE: mingw builds

[El Heggunte]

commit 36a8f03e2ac0

Latest changes:

cli: add option to support limit-TU and newer

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

[LigH.de]

x265 2.1+20-c64393b415ad (GCC 5.3.0)
x265 2.1+20-c64393b415ad (GCC 6.2.0)

CLI changes since v2.1+2:

+   --limit-tu <integer>          Enable early exit from TU recursion for inter coded blocks. Default 0

-   --discard-sei                 Discard SEI packets in bitstream. Default disabled
-   --discard-vui                 Discard optional VUI information from the bistream. Default disabled
+   --[no]-vui-timing-info        Discard optional VUI timing information from the bistream. Default enabled
+   --[no]-vui-hrd-info           Discard optional HRD timing information from the bistream. Default enabled

^ The small syntax typo will surely be corrected soon... ([no-]... instead of [no]-...).

The new option --limit-tu sounds interesting to me; I wonder how much speed gain will be possible without a noticable additional loss of quality.
__

P.S.: Don't try --limit-tu >2.

Invalid limit-tu option, limit-TU must be 0, 1 or 2

In a very brief test with a small video, the results were bit-identical, and no certain speed increase. So I guess an advantage requires specific situations.

[vhelp]

can someone please explain the GCC compiled versions that are included in these files and why someone would download a given one?

example, I'm on a dell inspiron laptop, intel i3 processor, win 7 home prem 64bit from 2010

last reported capability of this laptop from x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

and, which one should I download for the windows xp home OS, on a desktop pc, Amd dual core cpu from 2010 or earlier?

[LigH.de]

Regarding my archives:

You will probably prefer the GCC 6.2.0 builds. I added the GCC 5.3.0 builds only for the case someone wants to check compatibility issues the new compiler generation might have introduced due to more aggressive optimizations (but chances are low already that such bugs are still missed).

My Win32 builds may work on Windows XP, but I don't guarantee, I don't have any more installation. At least I compiled with required flags, I guess... For Windows 7 in a 64-bit version, no matter how expensive, you can use the Win64 builds.

In each case, you will probably just use the x265_ml.exe (multi-library EXE with included 8-bit, 10-bit, and 12-bit precision routines). All other files are only for rare cases when someone rather needs the separate DLLs, and maybe one of the single precision EXE's.

I did not optimize my builds for more complex instruction sets as minimum requirement. The assembler routines in x265 will probably be used from SSE2 on (all 64-bit CPUs should support that, including Athlon64), and the C routines minimum may be MMX, I guess. Win32 builds with 10 or 12 bit precision don't have assembler routines, as known for a long time already, so use only 8 bit precision for Win32 (in this case, Win32\x265_main.exe is enough).

[El Heggunte]

commit 0e9fb7dfba5a

[El Heggunte]

x265 v2.1+22-c97805dad914, compiled by Barough@doom9.forum


http://www117.zippyshare.com/v/5kpmu8gP/file.html

[El Heggunte]

commit 0e9e52640546

limitTU: fix energy calculation used in limiting TU recursion

[LigH.de]

New CLI options:

   --[no-]opt-qp-pps             Discard optional HRD timing information from the bistream. Default enabled
   --[no-]opt-ref-list-length-pps  Discard optional HRD timing information from the bistream. Default enabled

GCC 6.2.0 only is sufficient from now on.

x265 2.1+25-0e9e52640546

[El Heggunte]

commit bc911034c2a0

µChangeLog

Store commonly-used RPS in SPS in 2 pass mode.
Add new param --[no]-multi-pass-opt-rps to control it, default disabled.

slicetype: Add bias used in scenecut detection as param option.

test: Add multi-pass-opt-rps test to 2-pass rate control tests

[El Heggunte]

commit d216cb9b3b47

changelog: (aaaaargh!) @ https://bitbucket.org/multicoreware/x265/commits/all

[LigH.de]

Me too:

x265 2.1+36-d216cb9b3b47 (MSYS/MinGW, GCC 6.2.0, 32 + 64 bit, 8+10+12 bit single EXE + DLL and multi-lib EXE)

More advanced options:

   --[no-]opt-qp-pps             Discard optional HRD timing information from the bistream. Default enabled
   --[no-]opt-ref-list-length-pps  Discard optional HRD timing information from the bistream. Default enabled
   --[no-]multi-pass-opt-rps     Enable storing commonly RPS in SPS in multi pass mode. Default disabled

[El Heggunte]

commit b08109b3701e

[El Heggunte]

commit 4c1652f3884f

[Marsia Mariner]

commit 67e980e22c43

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

[Marsia Mariner]

commit a895b6344a82

limitTU : modify condition for limitTU 1 and 2

limitTU : use spatial and temporal CUs' TU depth to limit recursion

limitTU : use neighbouring CUs' TU depth to limit 1st subTU's depth

tests: update command lines to cover limitTU 3 and 4

[LigH.de]

x265 2.1+59-a895b6344a82

CLI changes:

(new)
   --scenecut-bias <0..100.0>    Bias for scenecut detection. Default 5.00

(changed descr.)
   --[no-]vui-timing-info        Emit VUI timing information in the bistream. Default enabled
   --[no-]vui-hrd-info           Emit VUI HRD information in the bistream. Default enabled
   --[no-]opt-qp-pps             Dynamically optimize QP in PPS (instead of default 26) based on QPs in previous GOP. Default enabled
   --[no-]opt-ref-list-length-pps  Dynamically set L0 and L1 ref list length in PPS (instead of default 0) based on values in last GOP. Default enabled

[Marsia Mariner]

commit df25adaa30f6

fix logic timing bug

NOTICE: from this day on, no more 32-bit builds of x265.exe from me, sorry.

For CPU-hungry tasks like HEVC compression, 64-bits is the way to go.

[Marsia Mariner]

commit 5d95fbd53ca3

doc: Improve rst doc and help doc about param multi-pass-opt-rps

Fix source width and height in info

[Marsia Mariner]

commit 5ae077d7053d

SEA motion search Implementation 0_o

https://bitbucket.org/multicoreware/x265/commits/5ae077d7053d76a036d50fd426996cc2e2d3c565

[Marsia Mariner]

commit e44b7b50f24c

"Fix memory leak in fpelMvCosts"

[Marsia Mariner]

commit b2d360143d96

Warn no support of pme and pmode in SEA motion search

regression: add pme option in regression commandlines

[Marsia Mariner]

commit c97c64ab8b8e

µchangelog

csv: modify csv api

SEA motion search: Copy integral planes for ANALYSIS LOAD

rc: frameSizePlanned is calculated from the predictors for vbv case

[LigH.de]

x265 2.1+69-c97c64ab8b8e

As mentioned above: SEA motion search implemented, several fixes and optimizations in addition.

[Marsia Mariner]

commit 78e1e1354a25

fix analysis save/load bug in limitTU

[LigH.de]

x265 2.1+70-78e1e1354a25 – "merge with stable" build; prepare for v2.2 "soon™"!

[Marsia Mariner]

commit e8152da7aa0e

Set up separate threadpool for lookahead

The user can allocate specific number of threads for lookahead by specifying --lookahead-threads <val>,
creating a separate lookahead pool for these threads. This will improve performance when lookahead
becomes a bottle neck. The threads for lookahead must be ideally less than half the total number
of available worker threads.

Aarthi Thirumalai

[vhelp]

And just for the record.., there is a slight fps increase in encoding speed. I was sure I saw at most 3 fps, using --preset fast. I assume speed is effective in certain presets, and fps rate will vary per user encoding criteria. In comparing against 2.1.63, I believe the speed had increase starting with 2.1.70 and on..

Also, as I commented in another thread, the quality (image detail) has improved.

[LigH.de]

New "merge with stable milestone" build:

x265 2.2+2-998d4520d1cf

[LigH.de]

x265 2.2+15-a18ab7656c30

Speedups in multipass encoding (reusing of more 1st-pass data); SSIM based RDO for mode selection; and some bugfixes.

[skylinekiller]

Good day,
I have been using x264VFW for years with VD, but now i would like to give x265VFW a shot. I downloaded x265vfw_x64_v120_x265b80_20160129.exe and installed it on win 10, just like my x264VFW file, but when i go to the compression window, I do not see the x265VFW codec. Will your file resolve this issue? How can I get a x265VFW to show up in my "video Compression" window in VD