x265 HEVC Encoder [Archive] - Page 49

mandarinka

10th June 2015, 00:32

Here is some speed test across different platforms:

With same No. of cores and threads, same frequency, Haswell(-E) is 36% faster (in terms of fps) than Ivy(-E), and 42% faster than SNB(-E)
So, if you are to buy a new CPU for x265, at least get an 4770K, instead of outdated 4930K.

Wow, that's a huge difference. Was it with frequency locked, or with turbo enabled (in that case, Haswell might have been helped by higher boost states reached)?

littlepox

10th June 2015, 02:18

Wow, that's a huge difference. Was it with frequency locked, or with turbo enabled (in that case, Haswell might have been helped by higher boost states reached)?

It was locked @ 4.0GHz and we monitored that using CPU-Z. Therefore none of the participants takes any advantage by turbo boost.

benwaggoner

10th June 2015, 21:41

Here is some speed test across different platforms:

With same No. of cores and threads, same frequency, Haswell(-E) is 36% faster (in terms of fps) than Ivy(-E), and 42% faster than SNB(-E)
So, if you are to buy a new CPU for x265, at least get an 4770K, instead of outdated 4930K.
That's a nice boost!

Which build of x265 was it, and what sort of settings?

littlepox

11th June 2015, 01:58

That's a nice boost!

Which build of x265 was it, and what sort of settings?

We used the v1.7+51, MSVC build, 64bit - highbitdepth ver.

Settings are made as follow(the one we use to encode animes):

--preset slower --crf 15.5 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 25 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1 --aq-strength 1.1 --rd 5 --psy-rd 0.8 --psy-rdoq 4.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --pmode --input-depth 16 --deblock -2:-2 --qg-size 32

pretty much a heavy setting.

Participants include:

Core i7 2700K
Core i7 3770K
Core i7 4790K
Core i7 3930K
Core i7 4930K
Core i7 5820K

Results from the quad-core group are fairly consistent with results from the hex-core group.

burfadel

11th June 2015, 05:04

mandarinka

11th June 2015, 05:59

Are the speed improvements due to AVX2 a result of being better over SSE2/SSE3/SSSE3/SSE4.2? Or is it because there are AVX2 versions of the C code that do not have SSE2/SSE3/SSSE3/SSE4.2 versions? Looking at the latest commits after v1.7+51, the performance gap is probably even wider now.

The SSE* SIMD should have a full coverage, so it is not matter of going from C to AVX2. The AVX2 paths that exist are going to be faster than SSE* on Haswell though, so it does give a speedup.

But Haswell should be faster clock-for-clock even in the code that only has SSE* version and no AVX2 version yet, thanks to microarchitecture improvements. These two things combine together.

littlepox

11th June 2015, 15:29

benwaggoner

12th June 2015, 00:13

We used the v1.7+51, MSVC build, 64bit - highbitdepth ver.

Settings are made as follow(the one we use to encode animes):

--preset slower --crf 15.5 --tu-intra-depth 3 --tu-inter-depth 3 --rdpenalty 2 --me 3 --subme 5 --merange 25 --b-intra --no-rect --no-amp --ref 5 --weightb --keyint 720 --min-keyint 1 --bframes 10 --aq-mode 1 --aq-strength 1.1 --rd 5 --psy-rd 0.8 --psy-rdoq 4.0 --rdoq-level 1 --no-sao --no-open-gop --rc-lookahead 80 --scenecut 40 --max-merge 4 --qcomp 0.80 --no-strong-intra-smoothing --pmode --input-depth 16 --deblock -2:-2 --qg-size 32
That's a particularly tweaked and specific group of settings. I think it's preferable to use a normal --preset. That'll correlate better with real-world use and is more likely to hit optimized paths. Also, it's make comparing to x264 like comparing apples to wombats.

What are those settings optimized for anyway? Anime? Ultrasounds?

littlepox

12th June 2015, 01:48

That's a particularly tweaked and specific group of settings. I think it's preferable to use a normal --preset. That'll correlate better with real-world use and is more likely to hit optimized paths. Also, it's make comparing to x264 like comparing apples to wombats.

What are those settings optimized for anyway? Anime? Ultrasounds?

Anime. See this for more info:
http://forum.doom9.org/showthread.php?p=1717888#post1717888

Anyway, no matter this test is accurate or biased, we do enjoy the benefit of the opts along x265's development. half a year ago it usually took us 50+% more time for an encode than today, so good job x265 team. However, I do hope they can make some break though in the quality, especially @ high bit-rates. We won't spend months testing out our own settings if we are satisfied with built-in tunes and presets.

nandaku2

12th June 2015, 03:07

The SSE* SIMD should have a full coverage, so it is not matter of going from C to AVX2. The AVX2 paths that exist are going to be faster than SSE* on Haswell though, so it does give a speedup.

But Haswell should be faster clock-for-clock even in the code that only has SSE* version and no AVX2 version yet, thanks to microarchitecture improvements. These two things combine together.

Thanks for the test results. You can use --asm=avx or --asm=sse4.2 to restrict x265 to use those instruction sets only. That will help separate out the benefits of AVX2 code and improved Haswell microarchitecture.

mandarinka

12th June 2015, 05:18

Just a side comparison:
For x264-10bit, haswell is 17% faster than ivy, and 24% faster than SNB.

x264 takes care of old CPUs more than x265 since it spent much of its life time without haswell. The performance gap is narrower, even though x264 is heavily optimized for haswell too..

The performance gap is narrower probably because AVX2 has less opportuinities to be useful in H.264 - the format has smaller blocks, smaller transforms, and due to that it can't be SIMDed to wide vector sizes like AVX2's 256bits as much as HEVC, which is more (large) SIMD friendly generally.

That's a particularly tweaked and specific group of settings. I think it's preferable to use a normal --preset. That'll correlate better with real-world use and is more likely to hit optimized paths.
I don't think it is such an serious issue. Most of those parameters are influencing rate-control (except PME I guess), so it won't really change codepaths. What the speed options could do is changing the balance of CPU cycles spent in various regimes (MC, interpolation, DCT, loopfilter, RDO, etc), but that is not that bad IMHO. It is the same problem as is posed by the existence of different presets: which is the proper preset for speed testing - ultrafast, placebo, medium? Whatever is default? Whatever is most usable? At that point, custom settings aren't that much troublesome.

easyfab

12th June 2015, 09:02

A quick test on sintel trailer :

CPU : I3-4000M
X265 1.7+93 --preset fast --crf 23

With AVX2 : x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

encoded 1253 frames in 71.16s (17.61 fps), 611.00 kb/s

With --asm AVX : x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

encoded 1253 frames in 89.66s (13.98 fps), 611.00 kb/s

In this case AVX2 FMA3 LZCNT BMI2 instructions give 26% more speed.

soresu

12th June 2015, 12:45

Should be interesting to see what performance gains Carrizo will see over Kaveri with AVX2 in Excavator. Unless of course there are already equivalent gains from XOP instructions in x265?

13th June 2015, 23:38

Some time ago I wrote bad words about new GCC 5.1 & 6.0 -- x265 is very slow when it is build with new versions of GCC.

After investigation it is all right with new GCC, there are bugs in x265 sources. I've created issue #143
https://bitbucket.org/multicoreware/x265/issue/143/x265-is-slow-when-it-is-build-with-gcc-51

So I take back all the bad things I have written about a new versions of GCC.

aegisofrime

14th June 2015, 09:30

14th June 2015, 14:41

Out of curiosity, what's the speed when your fixes are applied?

10-bit encoding speed on i5 3450S, input file 1920x800 23.976 fps, common options: "--crf 17.5 --rdoq-level 1 --psy-rd 0.4 --deblock -1 --keyint 288 --colormatrix bt709".
Builds:
x265-492 -- my normal 10-bit build with -march=corei7-avx option,
x265-510 -- 10-bit GCC 5.1 build with -march=corei7-avx option + patch,
x265-510old -- 10-bit GCC 5.1 build with -march=corei7-avx option (without patch),
x265-snow -- 10-bit snowfag build.

Raw numbers -- encoding time in seconds:

-----------|- fast -|- medium |-- slow -|- slower | veryslow| placebo
x265-492 --| 94,72s | 135,76s | 161,78s | 164,33s | 161,66s | 165,89s
x265-510 --| 94,29s | 134,78s | 161,23s | 163,86s | 161,26s | 164,77s
x265-510old| 100,68s| 145,78s | 167,31s | 180,14s | 173,28s | 174,19s
x265-snow -| 95,31s | 137,06s | 162,65s | 165,77s | 163,56s | 166,64s

Percentage comparison (x265-492 encoding time == 100.0%):

-----------|- fast | medium|- slow | slower|veryslow| placebo
x265-492 --| 100,0%| 100,0%| 100,0%| 100,0%| 100,0% | 100,0%
x265-510 --| 99,5% | 99,3% | 99,7% | 99,7% | 99,8% -| 99,3%
x265-510old| 106,3%| 107,4%| 103,4%| 109,6%| 107,2% | 105,0%
x265-snow -| 100,6%| 101,0%| 100,5%| 100,9%| 101,2% | 100,5%

Result file and batch used to this test is attached.

x265-492 & x265-510 you can download from www.msystem.waw.pl/x265/
x265-snow you can download from http://builds.x265.eu/

benwaggoner

14th June 2015, 21:36

Say, has anyone built a x265 into a DirectShow or QuickTime codec? Sometimes it sure would be nice to be able to export directly from my favorite GUI video software instead of having to render out an intermediate which I then decode with ffmpeg and pipe into x265.exe. An uncompressed 10-bit intermediate file for a full-length UHD feature is >>1 TB. And can take hours to write out in After Effects or other pro video tools.

I suppose this is part of the broader challenge of getting encoders from ffmpeg or etcetera into Windows/Mac codecs/plugins instead of standalone apps. I still remember my bitterness when I discovered ffdshow was playback only. We've had extensible media file writer APIs for a couple of decades now, but somehow they never seem to intersect with the open source codec world.

Or am I missing some incredibly powerful and widely used thing on SourceForge that everyone else knows about? Alternatively, a new secret thing I can know about :)?

LigH

14th June 2015, 22:00

LigH

15th June 2015, 09:17

Current builds appear to be really a lot bigger, especially 16bpp binaries (EXE: 3.3 => 4.6 MB; DLL: 2.9 => 4.1 MB; each about +1.2 MB). Furthermore, the "full help" output shrunk to 70% of its previous amount.

x265 1.7+166-32590b25678b (https://www.mediafire.com/download/4q9c5w6eokv9u97/x265_1.7+166-32590b25678b.7z)

P.S.: Compressed with 7-zip 15.05 beta; please check if you can unpack even with slightly older versions (but min. 9.20 beta).

benwaggoner

15th June 2015, 20:02

Since the encoder is available as DLL, it would probably be possible to write "bridges" using it. But I doubt that the API is already final. Furthermore, I don't remember any free software using DirectShow based encoders; not enough hens laying not enough eggs?
The API has actually been pretty stable for a while, and the Windows .dll is successfully being used with commercial and open-source apps.

Its a mystery why open source stuff doesn't make it to DirectShow. It seems there's more clamoring for VfW plugins, which is a terrible API that was deprecated, sheesh 16 years ago? Back when DirectShow was introduced as ActiveMovie. There's already a DirectShow .mp4 writer and AAC encoder, so all it needs is a DST wrapper for x265.dll.

Well, anyway, if someone wants me to owe them a Big Favor, a good sustainable solution for this would certainly earn that.

nevcairiel

15th June 2015, 20:47

What apps do actually exist that can use DShow encoders and muxers?
Its probably not too impossible to write a simple wrapper around the encoder, even if it just gives you a textbox where you can put it in the CLI option syntax. =p

LigH

15th June 2015, 22:52

Apart from GraphStudio? ... Possibly expensive commercial video editors I can't afford, if at all; but it is hard to search for it, I was not yet lucky.

As I already mentioned, I never heard of any freeware supporting it. Wikipedia's chapter about End-user tools (https://en.wikipedia.org/wiki/DirectShow#End-user_tools) is ... brief.

I wonder if it is at all the purpose of DS encoders to be freely usable as plugins; I would be afraid that applications supporting DS encoders may need to provide their own configuration dialogs for a few specifically known encoders.

There is a bold offer by visioforge, a collection of DS encoders/muxers, as trial version, partially containing freeware.
__

P.S.: Ancient NLE found which appears to support DS encoders, according to screenshots: in-sync Speed Razor (2001, abandoned).
__

P.P.S.: There is a "Multipurpose DirectShow Encoder" which executes an LGPL ffmpeg inside a DirectShow filter graph. Connect it to your preferred source filters and render. If you are able to use a current ffmpeg build, you may abuse it to encode with libx265. But it appears to be a bridge to a pipe. A solution which "takes us all around the houses".
__

One more: BluffTitler seems to be a 3D text titling software supporting DS encoders.
__

Canopus ProCoder 2 (http://forum.doom9.org/showthread.php?t=74379) must have supported any DirectShow encoder filter... so there is a chance that current GrassValley software may still do.

LigH

18th June 2015, 08:34

Because "merge with stable":

x265 1.7+180-d6c32960b5df (https://www.mediafire.com/download/i81278eq2e7tveu/x265_1.7+180-d6c32960b5df.7z)

foxyshadis

18th June 2015, 10:41

Save/load analysis is fixed in hg! (Old saves can even be reused.) This will save me so much time, I can restart my quest for the perfect options.

Atak_Snajpera

21st June 2015, 16:22

Quick question regarding reusing stat file in second pass with different target bitrate.
Let's say I have generated stat file in first pass with target bitrate of 1024. What will happen if in second pass I reuse this stat file but I change target bitrate. Instead of 1024 I use 2048 or 512. Will this be a big problem for x265/x264 encoder?

LigH

22nd June 2015, 12:11

Weekly (with a just even fixed typo in the XP compatible X265 Name Space refactoring):

x265 1.7+207-83a7d8244424 (https://www.mediafire.com/download/uaalnuesnx0gulu/x265_1.7+207-83a7d8244424.7z)

Atak_Snajpera

22nd June 2015, 21:31

Weekly (with a just even fixed typo in the XP compatible X265 Name Space refactoring):

x265 1.7+207-83a7d8244424 (https://www.mediafire.com/download/uaalnuesnx0gulu/x265_1.7+207-83a7d8244424.7z)

x265 sometimes creates corrupted stat file
Two examples
http://pastebin.com/KBeCMgyi
http://pastebin.com/8UKx43Lc

http://i.cubeupload.com/Dp2PuQ.png

23rd June 2015, 13:42

x265 sometimes creates corrupted stat file

You have CPU with lots of threads and the corruption is at the end of stat file. It looks like there is needed thread synchronization at the end of encoding with stat file write.

ShamisOMally

23rd June 2015, 14:32

burfadel

23rd June 2015, 15:02

So entirely depressing. Spend 60 hours doing a 10bit X265 PSNR encode for a movie at CRF 18, file size came out at 980MB. Quality was so-so for static area's, but high motion area's it was amazingly terrible causing severe banding/corruption/macroblocking

Then did a 10-bit x264 PSNR encode at CRF 18, file size came out at 2GB and it looked literally the same as source, even high motion area's were perfectly clear.

Wish I saved the 10-bit x265 export but I was entirely unimpressed at the time length vs quality I got. According to everything I read the last 2 days on this issue comes to the conclusion that 10-bit x265 is bad/unstable ATM? Does anybody have similar results?

Isn't PSNR mode designed not for actual practical encoding? How about trying standard settings (non-PSNR) at CRF 18 and see if the same result occurs? Even if this is a clip that contains both static and high motion scenes. With that clip, try also with x265 (non PSNR) at CRF 18.

All you did by disabling PSNR in x265 is to disable adaptive quant, psy-rd, and cutree.

Try default settings in x265, but in addition:
--qg-size 16
--psy-rd 0.8
--weightb
--subme 3
--b-intra
--aq-mode 2
--ref 5
--bframes 6

You could even try a lower CRF, like 17.

For example.

Ajvar

23rd June 2015, 15:14

Did anyone compare x265 encode performance on Linux vs Windows? Linux Mint on Ubuntu for instance?

LigH

23rd June 2015, 15:28

It shouldn't hurt to let encoders report PSNR or SSIM values. Just don't tune for metrics if you don't intend to encode for benchmarking metrics; for visually pleasing results, use defaults or content related tunings.

Furthermore, if your source is interlaced, and you don't configure the encoder to focus on fields rather than frames, a bad quality even with CRF 18 is not surprising. With progressive sources, CRF 18 should certainly not return displeasing results, neither with x264 nor with x265.

Ely

23rd June 2015, 15:56

Could somebody explain how --vbv-bufsize and --vbv-maxrate work ? I understand they're to limit the maximum bitrate and simulate a "fake bandwidth cap", but why are there 2 options for that ? Why not just one option to specify the maximum bitrate ?

Let's say I want a max bitrate of 5000kbps, should I set this value to both options ?

Boulder

23rd June 2015, 16:23

@ShamisOMally, burfadel: I redid my comparisons of x265 against x264 and there's no change what comes to x265 smoothing all the detail from certain frames. They probably have not concentrated on that at this point.

LigH

23rd June 2015, 18:33

@ Ely:

This topic is too complex to fit in a thread specifically about the x265 encoder. It is not even specific to any codec, it was already interesting in times of (S)VCD and DVD. And to no surprise, it has been discussed many times already in the last decade.

Imagine the decoding buffer like an open rain barrel with a rusty faucet. The faucet has a maximum output; if there is too heavy rain, the barrel will overflow because it fills faster (video bitrate) than it gets emptied (decoding speed). But if there is only little rain, the barrel will run dry because it also has a minimum output, you can't close it as tight as you like. The bigger the barrel, the longer you can stand a dry phase before the barrel is empty.

You need to know both the capacity of the decoding buffer and the maximum fill rate (which is limited by the bitrate the source media can be read with) to produce video streams which will neither fill the buffer too fast (and make it "overflow") nor fill the buffer too slowly for a long time (and make it "run dry").

The Profile@Level limits are related to playback devices with different limits for video buffer sizes and meda reading speeds. But to support a specific device perfectly, it may be an advantage to know both VBV limits as exactly as possible, to allow the encoder to use them for optimal bitrate adaption.

By the way, the source medium may also be a network broadcast with a limited bandwidth, a.k.a. "video stream".

23rd June 2015, 18:36

Let's say I want a max bitrate of 5000kbps, should I set this value to both options ?

Yes, you can set for n kbps:
--vbv-bufsize n --vbv-maxrate n
or (even better)
--vbv-bufsize 2*n --vbv-maxrate n

In first case you will have no less than 1 second buffer, in second case -- 2 seconds.

Why do you want a max bitrate of 5000kbps? (maybe --bitrate 5000 is enough?)

Ely

23rd June 2015, 19:11

Thank you both for answering. I'm encoding videos which have a fairly low complexity overall, but sometimes they have incredibly complex short scenes which make the bitrate momentarily go sky high (using crf). I'd like to limit that effect, and I thought using vbv-maxrate might be the solution. But maybe 2-pass ABR is better ?

@Ma I'm pretty sure I meant 5000 kbps, aka 5mbps. 5000 b/s would be really low wouldn't it ?

23rd June 2015, 19:32

I'm encoding videos which have a fairly low complexity overall, but sometimes they have incredibly complex short scenes which make the bitrate momentarily go sky high (using crf). I'd like to limit that effect, and I thought using vbv-maxrate might be the solution.

Yes, vbv-maxrate + small vbv-bufsize "helps" -- it will be visible quality loss. Big vbv-bufsize can to push through short complex scene without quality loss. So for you it is OK --vbv-bufsize 5000 --vbv-maxrate 5000.

Ajvar

23rd June 2015, 19:56

x265 team set vbv-buff size to twice size the vbv-maxrate. When I set equal size (1x) I saw visible degradation in quality on costly scenes.

23rd June 2015, 23:28

x265 sometimes creates corrupted stat file

I think that the fix is quite simple. I attached diff file. Order of frames written to stat file is not important, we must make only one write at a time.

You can apply this diff to ver. 1.7+220 or try my test build
www.msystem.waw.pl/x265/test-Atak.7z

I encoded one short file with 2pass mode without any problems.

foxyshadis

24th June 2015, 00:30

Unless you know the bufsize, you should never touch maxrate, otherwise you're just feeling around in the dark to get some effect. Buffer size is a hard number, while maxrate (maximum decoding rate, not the maximum streaming rate) is a little softer -- some chips might be a little better with CABAC, others with MC, some might have more threads for better wavefront support, so the character of the stream affects it and the stated maximum decoding rate tends to be rather conservative -- but it's still something you should measure on an actual hardware target before you go setting it willy-nilly.

nandaku2

24th June 2015, 08:46

I think that the fix is quite simple. I attached diff file. Order of frames written to stat file is not important, we must make only one write at a time.

You can apply this diff to ver. 1.7+220 or try my test build
www.msystem.waw.pl/x265/test-Atak.7z

I encoded one short file with 2pass mode without any problems.

Thank you. We're looking at this issue as well as at your proposed patch. In the meantime, I would highly encourage you to sign our CLA at Downloads (https://bitbucket.org/multicoreware/x265/downloads), and send us your patch through the mailing list (read Contribute (https://bitbucket.org/multicoreware/x265/wiki/Contribute))

24th June 2015, 10:35

Thank you. We're looking at this issue as well as at your proposed patch.

I'm not sure if this patch is necessary. The fprintf function from present-day compilers should be atomic
http://stackoverflow.com/questions/22539282/is-msvcrts-implementation-of-fprintf-thread-safe

Atak_Snajpera uses x265 build with ancient compiler and this may be the reason.

Atak_Snajpera

24th June 2015, 13:56

I'm not sure if this patch is necessary. The fprintf function from present-day compilers should be atomic
http://stackoverflow.com/questions/22539282/is-msvcrts-implementation-of-fprintf-thread-safe

Atak_Snajpera uses x265 build with ancient compiler and this may be the reason.

I can confirm that builds from http://chromashift.org/x265_builds/ work fine. So it looks like that GCC 4.8.2 is a problem like MA already mentioned.

I think that the fix is quite simple. I attached diff file. Order of frames written to stat file is not important, we must make only one write at a time.

You can apply this diff to ver. 1.7+220 or try my test build
www.msystem.waw.pl/x265/test-Atak.7z

I encoded one short file with 2pass mode without any problems.

This patched build works fine as well.

24th June 2015, 17:33

I can confirm that builds from http://chromashift.org/x265_builds/ work fine. So it looks like that GCC 4.8.2 is a problem like MA already mentioned.

I found some historic words about MinGW
https://en.wikipedia.org/wiki/MinGW#Programming_language_support
and it looks like there was problem with printf function and posix threading (which MinGW-w64 resolved). So maybe LigH uses GCC 4.8.2 with posix threading and old MinGW headers/crt.

I believe in what is written in Wikipedia but we should double check this. Could you test clean (without any patches) builds of x265 made by GCC with actual MinGW-w64 headers/crt? There are two builds: with posix threading and with win32 threading. The win32 threading version should work, but I'm not so sure about posix threading version.
www.msystem.waw.pl/x265/test2-Atak.7z

Atak_Snajpera

24th June 2015, 18:20

I found some historic words about MinGW
https://en.wikipedia.org/wiki/MinGW#Programming_language_support
and it looks like there was problem with printf function and posix threading (which MinGW-w64 resolved). So maybe LigH uses GCC 4.8.2 with posix threading and old MinGW headers/crt.

I believe in what is written in Wikipedia but we should double check this. Could you test clean (without any patches) builds of x265 made by GCC with actual MinGW-w64 headers/crt? There are two builds: with posix threading and with win32 threading. The win32 threading version should work, but I'm not so sure about posix threading version.
www.msystem.waw.pl/x265/test2-Atak.7z

I will surprise you ;) None of them work.

LigH

24th June 2015, 18:45

My current build environment is the MSYS / MinGW-Win32 with GCC 4.8.2 which was once released by XhmikosR, possibly years ago?

I guess I should try to abandon this era and use a current MSYS / MinGW-Win64 with GCC 4.9.2 (http://xhmikosr.1f0.de/tools/msys/) instead in the future. Speed advantages have been documented already. If there are now even reliability issues, it appears convincing.
__

Now I wonder if the linking issues (https://mailman.videolan.org/pipermail/x265-devel/2015-June/008672.html) of "multilib" builds are also caused by this old environment, or if people with a modern build environment can't link libx265_main10.a to x265.exe either.

24th June 2015, 21:36

I will surprise you ;) None of them work.

Thanks for testing. It is time to dig deeper...

24th June 2015, 21:48

If there are now even reliability issues, it appears convincing.

I don't know what's going on, but it is not your GCC fault.

Now I wonder if the linking issues of "multilib" builds are also caused by this old environment, or if people with a modern build environment can't link libx265_main10.a to x265.exe either.

Now I use GCC from site www.drangon.org/mingw/ (GCC 5.1 from http://mingw-w64.org/ is not fully compiled -- they made 6 of 8 versions and stop). There is no problem with strtok_r with current GCC/MinGW-w64, but I have another problem with linking. I must add -DSTATIC_LINK_CRT=ON to cmake command and when I add additionally -DEXTRA_LIB=x265_main10.a -DEXTRA_LINK_FLAGS=-L. the file CMakeFiles\cli.dir\linklibs.rsp is wrong:
libx265.a -Wl,-Bstatic -lx265_main10 -Wl,-Bdynamic -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32