Re: [x265] MinGW, GCC: Shadow declaration of type 'byte' in rpuParser, x265 CLI

May be fixed already by the not yet approved patch by Aruna, sorry... to be checked when it's available. -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.de ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.or

Re: [x265] [PATCH 1 of 2] zone: add support to parse zone files

Am 20.12.2018, 12:03 Uhr, schrieb : # HG changeset patch # User Bhavna Hariharan # Date 1544769275 -19800 # Fri Dec 14 12:04:35 2018 +0530 # Node ID 592b83c9068d7f402c85394fcf113b767b58f08d # Parent 1f44f1f1623d677c80469e713ed642f6673af91d zone: add support to parse zone files GCC 7.4.

[x265] MSYS2/MinGW: RC version string syntax error

ninja log: + [8/91] Building RC object CMakeFiles/cli.dir/x265.rc.obj FAILED: CMakeFiles/cli.dir/x265.rc.obj H:\development\media-autobuild_suite-master\msys64\mingw32\bin\windres.exe -O coff -IH:/development/media-autobuild_suite-master/build/x265-hg/source -IH:/development/media-autobuild_s

Re: [x265] MSYS2/MinGW: RC version string syntax error

A patch suggested by wiiaboo, maintainer of media-autobuild_suite: https://0x0.st/s5C6.txt + diff -r 8f1c154aae5e source/CMakeLists.txt --- a/source/CMakeLists.txt Sat Dec 29 07:21:21 2018 +0100 +++ b/source/CMakeLists.txt Tue Jan 01 15:15:23 2019 + @@ -578,7 +578,7 @@ # c

[x265] Another issue with MSYS2/MinGW windres: Output not writeable

Since you published the recent patches (e.g. to fix the version numbers), there was a report in the MABS project that windres failed again (here MinGW64): x265.rc:2: fatal error: when writing output to : Broken pipe I tried that too, my error message is different but similar (here MinGW32)

Re: [x265] Another issue with MSYS2/MinGW windres: Output not writeable

Am 03.01.2019, 20:42 Uhr, schrieb Mateusz : W dniu 03.01.2019 o 18:45, Mario Rohkrämer pisze: Since you published the recent patches (e.g. to fix the version numbers), there was a report in the MABS project that windres failed again (here MinGW64): x265.rc:2: fatal error: when writing

Re: [x265] bool should *not* be in a header file

Am 05.03.2019, 22:39 Uhr, schrieb Vittorio Giovara : Any C program including x265.h will fail to build because of this line x265_zone *x265_zone_alloc(int zoneCount, bool isZoneFile); Is it Groundhog Day again? That's not the first bool being complained. -- Fun and success! Mario *LigH*

Re: [x265] Some compiler warnings under Linux

Forgot to mention: This was v3.1.1+1 Am 13.07.2019, 16:41 Uhr, schrieb Mario *LigH* Rohkrämer : Ubuntu 18.04 LTS + GCC 9.0 /home/ligh/x265/source/encoder/ratecontrol.cpp: In member function ‘int x265::RateControl::writeRateControlFrameStats(x265::Frame*, x265::RateControlEntry*)’: /home/

Re: [x265] Linking multilib binary fails in MSYS2/MinGW

Am 10.01.2020, 15:21 Uhr, schrieb Mario *LigH* Rohkrämer : Is this a regression? Or did parameters in a build script have to change recently and I didn't notice (still using build scripts which worked a month ago)? Sorry, this topic seems to be specific, probably related to the availabil

Re: [x265] Issue #545: cmake error: list GET given empty list (multicoreware/x265)

Am 01.05.2020, 19:56 Uhr, schrieb Nikolas 'Nick' Raiser : CMake Error at CMakeLists.txt:623 (list): list GET given empty list CMake Error at CMakeLists.txt:624 (list): list GET given empty list Can you attach the CMakeLists.txt file to your issue? There might be several, not sure, ta

Re: [x265] [PATCH] presets: Updating presets to improve coding efficiency and speed

I don't know how to apply a patch manually, using TortoiseHg; but I will try and see... last chance to have it from me before Christmas is now. Am 22.12.2015, 19:51 Uhr, schrieb Tom Vaughan : It is essentially ready to go. You could apply it to your build if you wanted, notifying your us

Re: [x265] [PATCH] presets: Updating presets to improve coding efficiency and speed

Well, I tried and it failed (10/10 rejects). So I have to rely on you. Am 23.12.2015, 06:08 Uhr, schrieb Mario Rohkrämer : I don't know how to apply a patch manually, using TortoiseHg; but I will try and see... last chance to have it from me before Christmas is now. Am 22.12.2015,

[x265] Old issue? Zones in n-pass VBR may not be reliable

I was just surprised by a reply on a post in the doom9 video forum I already forgot due to no reply so far, from July 2015. I had a report in the German doom9/Gleitz forum that a user could not see any impact by zones on the final bitrate in the 2nd pass, only in 1st pass and 1-pass modes.

Re: [x265] Birthday off today

Am 21.06.2016, 06:38 Uhr, schrieb Aarthi Priya Thirumalai : Hi all, I will be taking the day off on the occasion of my birthday. HB2U :) - Luck and health to you. May you receive the required recreation and power to continue afterwards. -- Fun and success! Mario *LigH* Rohkrämer mailt

Re: [x265] Ghosting/artifacts even with low CRF

Just a nit: "--crf 0" is not meant to be "lossless", the quantization might still vary; "--qp 0" is certainly lossless, as documented in "x264 --fullhelp". But you should consider your file "quasi-lossless", with no noticeable difference. Am 15.07.2016, 20:25 Uhr, schrieb Rômulo Silva :

Re: [x265] Compression gains...results update

Remember, x265 optimizes for psycho-visually convenient results per default, which may look better to many, but may have worse PSNR and SSIM values. If you want to compare SSIM values with another encoder, use "--tune ssim"; if you want to compare PSNR results with another encoder, use "-

Re: [x265] hevc_vaapi, jerky encode

Am 21.10.2016, 16:35 Uhr, schrieb Mani Vannan M. : Hi Not sure if this is the place to post regarding an issue with hevc_vaapi, but since i have absolutely no other headway anywhere and this is driving me crazy, posting it here. There is a abnormal behavior when encoding using hevc_vaapi, and

[x265] Please try to visualize motion search methods

Only you, as the developers, will know which geometrical shapes the different motion search methods will use, only you can give us a visual impression how many samples in which direction and which distance will be considered for each method. I tried for a long time to find diagrams in the w

Re: [x265] [PATCH] SSIM based RDO for mode selection

Am 28.12.2016, 16:11 Uhr, schrieb : diff -r af10eaeb36cd -r 146036b4049c source/x265cli.h --- a/source/x265cli.h Wed Dec 28 10:17:08 2016 +0530 +++ b/source/x265cli.h Wed Dec 28 19:12:02 2016 +0530 @@ -256,6 +256,8 @@ { "analyze-src-pics", no_argument, NULL, 0 }, { "no-analyze-src-pi

Re: [x265] Problems compiling the HEVC cpp code

Hi. Which compiler are you using, exactly? Brand, version? Compiling the sources will require compatibility to a specific C++ language level, usually specified by a year number, e.g. C++98. Am 22.04.2017, 19:12 Uhr, schrieb olsi teta : Hello, Good Afternoon, I am running into some troub

[x265] x265 with Dynamic HDR10 support: Missing line break in full help

https://github.com/jb-alvarado/media-autobuild_suite can build x265 with DHDR10 support using GCC 6.3.0 by patching "-std=gnu++11" into source/CMakeLists.txt (using sed, not the cmake-hdr10.patch by Ma0 from April 20). I noticed a missing line break here in the full help output, in front of

Re: [x265] [PATCH] cmake: set '-std=gnu++11' for GCC if ENABLE_DYNAMIC_HDR10 is on

Am 20.04.2017, 23:04 Uhr, schrieb Mateusz Brzostek : Current code for HDR10 needs gnu++11 for GCC at least. This patch sets '-std=gnu++11' for GCC only if ENABLE_DYNAMIC_HDR10 is set. Please review. A pity this patch did not make it into milestone 2.4 yet... -- Fun and success! Mario *L

Re: [x265] Problems compiling the HEVC cpp code

but i have been busy. The compiler that I am using is a riscv 64 architecture in which corresponds the GCC 6.1.0 but receives commits on frequent bases. Do you know perhaps what kind of compiler the HEVC actually needs? Regards, Olsi Teta ____ From: x265-devel on

Re: [x265] CMake output skipped while building sub-target dynamicHDR10

It's fixed now. Not sure which patch is responsible, but it's working. Am 18.05.2017, 16:35 Uhr, schrieb Mario *LigH* Rohkrämer : Plus: There is also no bold pink line "Scanning dependencies of target dynamicHDR10", like it is reported for targets "encoder" and "common". -- Fun and su

Re: [x265] x265 encoder

Not quite a question for this mailing list ... But x264 is an encoder only as well. You can find decoders for most usual formats in the libav libraries (libavformats for container formats + libavcodec for content formats), being part of the ffmpeg or the libav project. Am 21.10.2017, 17:2

Re: [x265] [PATCH] Add CLI option to enable or disable picture copy to internal frame buffer

Am 15.11.2017, 17:15 Uhr, schrieb Pradeep Ramachandran : On Wed, Nov 15, 2017 at 6:52 PM, Mario *LigH* Rohkrämer wrote: Am 14.11.2017, 11:11 Uhr, schrieb : +.. option:: --copy-pic, --no-copy-pic + + Allow encoder to copy input x265 pictures to internal frame buffers. When disabled,

Re: [x265] [PATCH] cli: add new option '--fullhelp'

Probably simply as convenient and x264-compatible shortcut of "--log-level full --help". Am 03.12.2017, 22:01 Uhr, schrieb Ashok Kumar Mishra : We have similar command line --help. Can you help me understand the purpose of introducing new command line --fullhelp. On Thu, Nov 30, 2017 a

Re: [x265] [PATCH] CMake: blacklist mingw implicit link libraries

Am 23.01.2018, 13:02 Uhr, schrieb Ricardo Constantino : On 16 January 2018 at 17:41, Ricardo Constantino wrote: # HG changeset patch # User Ricardo Constantino # Date 1516124393 0 # Tue Jan 16 17:39:53 2018 + # Node ID 5dbc1653fba42507f44fac6034aa3598fb2816cd # Parent 3712d13c09b

[x265] v2.6+37 (MinGW): HEVC encoder version & build info = (null)

I just built x265 2.6+37-1949157705ce in MSYS2/MinGW with GCC 7.3.0. Printing a full help page reports at first: x265 [info]: HEVC encoder version (null) x265 [info]: build info (null) A previous version reported e.g.: x265 [info]: HEVC encoder version 2.6+27-2f3c4158cf35 x265 [info]: build

Re: [x265] v2.6+37 (MinGW): HEVC encoder version & build info = (null)

ywhere near the version code. It's unrelated. On 1 February 2018 at 21:03, Mario Rohkrämer wrote: I just built x265 2.6+37-1949157705ce in MSYS2/MinGW with GCC 7.3.0. Printing a full help page reports at first: x265 [info]: HEVC encoder version (null) x265 [info]: build info (null) A previ

Re: [x265] v2.6+37 (MinGW): HEVC encoder version & build info = (null)

ommits since a version" in branches with multiple merges into it. Am 01.02.2018, 22:07 Uhr, schrieb Ricardo Constantino : The patch didn't touch anywhere near the version code. It's unrelated. On 1 February 2018 at 21:03, Mario Rohkrämer wrote: I just built x265 2.6+3

Re: [x265] v2.6+37 (MinGW): HEVC encoder version & build info = (null)

believe due to using git instead of hg?), but I believe the result was different, at least the GCC version and bitness were still reported, not (null). Am 01.02.2018, 23:02 Uhr, schrieb Mateusz : W dniu 01.02.2018 o 22:13, Mario Rohkrämer pisze: Hmm. Then ... - hg fails determining the

[x265] Report of possible issues with L-SMASH multiplexer, v2.7+14/+17

There is a report in the doom9 forum that multiplexing HEVC with L-SMASH's muxer.exe fails since v2.7+14 to v2.7+17; there was a SEI clean-up in between. https://forum.doom9.org/showthread.php?p=1837506#post1837506 -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.de __

Re: [x265] [PATCH] introduce new CLI single-sei to write all SEI messages in one single NAL

Am 02.04.2018, 14:49 Uhr, schrieb : +When HRD SEI is enabled the HM decoder will through a warning. *throw -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.de ___ x265-devel mailing list x265-devel@videolan.org https://mailman.vide

Re: [x265] [PATCH 000 of 307 ] AVX-512 implementataion in x265: breaks 32-bit compilation

Am 07.04.2018, 04:29 Uhr, schrieb : This series of patches enables AVX-512 in x265. USe CLI option --asm avx512 to enable AVX-512 kernels. ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel Compili

Re: [x265] [PATCH] Add VMAF suppport to report per frame and aggregate VMAF score

Am 12.04.2018, 13:13 Uhr, schrieb : +.. Note:: + +When setting ENABLE_LIBVMAF cmake option to ON, it is recommended to +also set ENABLE_SHARED to OFF to prevent build problems. +We only need the static library from these builds. + +Binaries build with windows will not have VMAF s

Re: [x265] [PATCH] Add VMAF suppport to report per frame and aggregate VMAF score

hosted on Norfolk Island -Original Message- From: Mario *LigH* Rohkrämer Sent: Monday, April 23, 2018 7:55 AM To: Development for x265 Subject: Re: [x265] [PATCH] Add VMAF suppport to report per frame and aggregate VMAF score Mario Rohkrämer schrieb am 12.04.2018 um 18:25: Am 12.04.2018,

[x265] More CMake warnings of old-style policies

With CMake 3.11, there are now already two deprecated old-style policies being warned: + -- cmake version 3.11.1 CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy): The OLD behavior for policy CMP0025 will be removed from a future version of CMake. The cmake-policies(7) ma

Re: [x265] Passing multiple images to x265 CLI

The current x265 CLI expects exactly one input file name. There is no logic coded to handle a sequence of input files to be processed. You will have to execute the encoder for one input file, wait for it to finish, and then start a new instance if there is more input to be encoded to a sepa

Re: [x265] zones file

Hi Alex. The use of is a syntax element that encloses descriptive names of variables. You must omit them if you actually use values. The "b" option uses a float value as multiplier of a bitrate calculated by the bitrate control, not an explicit bitrate value in kbps. So your example may

Re: [x265] v1.7+282: Multilib EXE doesn't link

Am 03.07.2015, 21:12 Uhr, schrieb Steve Borho : On 07/03, Mario *LigH* Rohkr??mer wrote: Both 8bit/libx265_main12.a and 8bit/libx265_main10.a do exist. Still, linking to an EXE fails in an MSYS/MinGW environment, with either GCC 4.8.2 or GCC 4.9.2: + [100%] Linking CXX executable x265.e

[x265] Suggested patch to fix multithreaded writing of 2-pass stats in Win32 target

People discussed an additional lock on a stats file output to avoid corruption with many threads: http://forum.doom9.org/showthread.php?p=1731547#post1731547 -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.de ___ x265-devel mailing li

Re: [x265] Suggested patch to fix multithreaded writing of 2-pass stats in Win32 target

To clarify: It is supposed to fix a flaw in MinGW using non-atomic legacy MSVCRT output routines. Am 25.07.2015, 20:17 Uhr, schrieb Mario Rohkrämer : People discussed an additional lock on a stats file output to avoid corruption with many threads: http://forum.doom9.org/showthread.php?p

[x265] x265 docs: CSS fails completely in Opera 12, HTTPS is too secure ; -)

For a little while now, Opera 12 is not anymore able to render the x265 documentation correctly. http://x265.readthedocs.org/en/default/ The sytlesheet is completely ignored, the page displayed like pure HTML without any styles. I found that the reason is the stylesheets being loaded via H

Re: [x265] [PATCH] input: read yuv input from stdin if filename is passed as "-"

Am 25.10.2013, 18:37 Uhr, schrieb Steve Borho : I don't really care to do auto-detection of the stream type, and right now - always means YUV. Would it be acceptable if -.y4m is used to indicate Y4M on stdin? Probably not; the typical use, a "quasi standard", is to have exactly the hyphen

Re: [x265] [PATCH] input: read yuv input from stdin if filename is passed as "-"

In x264 style you could have a setting that sets the used 'demuxer' (akin to --demuxer in x264). Some builds of x264 could include libav splitters, supporting a range of input formats directly; x265 is far from that, yet. Naturally the name of the setting could be changed if there are better

Re: [x265] Possible architecture specific bug in ~v0.5+439: 32-bit builds crash

Am 22.11.2013, 17:37 Uhr, schrieb Steve Borho : On Nov 22, 2013, at 6:37 AM, Mario *LigH* Rohkrämer wrote: Am 21.11.2013, 22:55 Uhr, schrieb Steve Borho : On Thu, Nov 21, 2013 at 2:52 AM, Mario *LigH* Rohkrämer wrote: Builds of x265 0.5+439-108ddc9e5c6b for 32 bit (both MSYS and VC12

[x265] F.R.: Report number of frame threads in [info] block

Feature Request: Since the number of concurrently encoded frames is per default derived from the available CPU cores, I miss the actual number in the x265 [info] output. It will be useful to know which number has been calculated if it was not enforced by a value different to 0 for parameter

Re: [x265] F.R.: Report number of frame threads in [info] block

possibly not yet "optimal". On Sat, Nov 23, 2013 at 6:48 AM, Mario Rohkrämer wrote: Feature Request: Since the number of concurrently encoded frames is per default derived from the available CPU cores, I miss the actual number in the x265 [info] output. It will be useful to

[x265] Issue #26: v0.7: Severe quantizer difference between {...faster} and {fast...} presets (multicoreware/x265)

New issue 26: v0.7: Severe quantizer difference between {...faster} and {fast...} presets https://bitbucket.org/multicoreware/x265/issue/26/v07-severe-quantizer-difference-between Mario Rohkrämer: With default options (CRF 28), all presets {'faster' *and faster*} produce a much lar

Re: [x265] Adding 64 bit building in MSYS to x265/build in repository ?

Am 14.02.2014, 18:59 Uhr, schrieb Steve Borho : I've been making 64bit MinGW builds of x265 since the beginning without any toolchain scripts like that. You just need a 64bit MSYS and a 64bit MinGW compiler and use the current build/msys folder as-is. Now I wonder how to "correctly" set up an

Re: [x265] Unclear VUI options

If the video complies to broadcasting standards like ITU-R BT.601/709, then it should have a limited luminance and chrominance range in YUV color space. Full range video should only exist if it was generated artifically (e.g. by a 3D renderer or heavy filtering). My remark is rather directe

Re: [x265] Unclear VUI options

Am 22.02.2014, 00:07 Uhr, schrieb dave : by the way, there are other options where bt709 is possible, can that be used to determine range? I don't ecpect this to be easily "detectable"; instead I would rather assume that TV scale is in general more probable. Even movies which in general c

Re: [x265] Unable to encode huge frame sizes

Am 16.03.2014, 06:18 Uhr, schrieb JMK : Details in the "unofficial" x265.exe thread at Videohelp: http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2308898&viewfull=1#post2308898 Confirming: x265 8KTest.y4m --y4m --preset veryfast --crf 20 -o 8KTest_Y4M.hevc x265 [

[x265] Preset superfast undocumented in help output and PDF page 3

There is a preset "superfast" which is missing in the help output of x265 and in the verbose explanation of command line options in the Evaulator's Guide on page 3. But it appears in the table of quality presets on page 9 and is available while encoding. -- Fun and success! Mario *LigH* Ro

Re: [x265] [PATCH] restore WINXP_SUPPORT build option, workaround for CONDITION_VARIABLE on XP

I'd be interested to hear if others see similar results. Will try when the patch is committed, I have to little experience in manually applying patches... AMD Phenom-II X4 or X6 with Win7 64b, and Athlon X2 with WinXP, are available. -- Fun and success! Mario *LigH* Rohkrämer mailto:con

Re: [x265] [PATCH] restore WINXP_SUPPORT build option, workaround for CONDITION_VARIABLE on XP

According to my tests on an AMD Phenom II X6 1045T, speedup is marginal but probable in the average. -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.deCommand, Date/Time, Elapsed Time, FPS, Bitrate, Y PSNR, U PSNR, V PSNR, Global PSNR, SSIM, SSIM (dB), Version --frames 240 --fp

Re: [x265] [PATCH] restore WINXP_SUPPORT build option, workaround for CONDITION_VARIABLE on XP

Am 30.03.2014, 03:18 Uhr, schrieb Steve Borho : Thanks for testing. Since the gravity seems to lean towards XP, I'll leave that as the default for MinGW builds But this seems to break compiling when WINXP_SUPPORT is not enabled (which would be not useful for x86_64 Win64 cross compiles, but

[x265] x265 0.8+247 (new XP compat.) crashes in single thread mode

I tested a bit in a VirtualBox and found that v0.8+149 (last XP compatible build before introducing the new threading model) works on an Unicore CPU in Windows XP SP3, but 0.8+247 (one 32 bit build which compiles in MSYS with WINXP_SUPPORT enabled again) reports disabled parallelism and using

Re: [x265] ASM crash in r6682 on E5200: Probably SSE4 vs. SSSE3 instructions

Am 11.04.2014, 10:41 Uhr, schrieb chen : Thank you! For simplest way, capture windows crash window (show crash address) and his exe file, we can find more information in it. D3C0D3R just replied in http://forum.doom9.org/showthread.php?p=1677250#post1677250 + SIGSEGV ... in in x265_

[x265] Possible bug: Chrominance planes shifted when saturation is low

Here is a report about encoded material with very low brightness and saturation, especially at the edges, and the chrominance is shifted away from the luminance, to the right. http://forum.doom9.org/showthread.php?p=1679520#post1679520 I hope the reporter will be able to upload a sample to i

Re: [x265] Possible bug: Chrominance planes shifted when saturation is low

http://forum.doom9.org/showthread.php?p=1679520#post1679520 Reading the initial post, it does sound like the YUV resolution was not quite what he thought it was. The chroma would slide off faster than the luma. He probably used a file which was in fact a Y4M with header, as if it was a raw

[x265] A few warnings from GCC 4.8.2

level.cpp + h:/MSYS/home/LigH/x265/source/encoder/level.cpp: In function 'void x265::determineLevel(const x265_param&, x265::Profile::Name&, x265::Level::Name&, x265::Level::Tier&)': h:/MSYS/home/LigH/x265/source/encoder/level.cpp:143:24: warning: array subscript is above array bounds [-

[x265] Many more warnings by GCC 4.8.2

No panic; I know that many reasons for warnings are less than serious. Just reporting. __ h:/MSYS/home/LigH/x265/source/Lib/TLibCommon/TComWeightPrediction.cpp: In member function 'void x265::TComWeightPrediction::getWpScaling(x265::TComDataCU*, int, int, x265::WeightParam*&, x265::Weig

Re: [x265] patch for faster intra

Am 02.08.2014, 06:50 Uhr, schrieb Steve Borho : ... But I imagine most presets that use this RDO version of intra will not want a fast scan. But maybe it is useful for a "turbo mode". -- Fun and success! Mario *LigH* Rohkrämer mailto:cont...@ligh.de

Re: [x265] Recent Frames/second benchmarks per platform and per clip?

Hi Raul. I am curious about the development of speed and efficiency too. But their use for me is rather marginal, without any AVX capable CPU. Especially recently, there was a lot of speed optimization mainly for AVX2. Way beyond AMD Phenom-II. I can only hope that it doesn't get slower f

Re: [x265] Recent Frames/second benchmarks per platform and per clip?

e architectures, but it should not be negative for people running on older platforms. Tom -Original Message- From: x265-devel [mailto:x265-devel-boun...@videolan.org] On Behalf Of Mario Rohkrämer Sent: Friday, September 26, 2014 12:44 PM To: Development for x265 Subject: Re: [x265

[x265] Regarding new thread pooling: Low CPU utilization on Dual Xeon

There have been several reports already that the current x265 binaries are not very efficient since a new thread pooling was introduced. One of the members of the German speaking doom9/Gleitz video board - 'Massaguana' - reported a very low utilization, ~25-30% overall, on a dual socket boa

Re: [x265] [PATCH 6 of 6] asm: upgrade runtime warning to explicit compile error

Am 06.03.2015, 18:07 Uhr, schrieb Steve Borho : # HG changeset patch # User Steve Borho # Date 1425661623 21600 # Fri Mar 06 11:07:03 2015 -0600 # Node ID 3eef0fe70475e17f5a671bf0dd522f89fb957b71 # Parent a07ea06f3ee8a5d1edb2edc584934d38f26583d8 asm: upgrade runtime warning to explicit co

[x265] Win32 HBD build with disabled assembly: linking EXE fails, missing x265_stack_align

Tried to build x256 1.5+186-043c2418864b with GCC 4.8.2 in MSYS using the following commands: cmake -G "MSYS Makefiles" -DWINXP_SUPPORT:BOOL=TRUE -DHIGH_BIT_DEPTH:BOOL=TRUE -DENABLE_ASSEMBLY:BOOL=FALSE ../../source The result was that only libx265.a and libx265.dll were created, but linki