[HEVC] x265.EXE: mingw builds

[DarrellS]

No!

> x265.exe!004a9bb2()
[Frames below may be incorrect and/or missing, no symbols loaded for x265.exe]
msvcrt.dll!77c2c3ce()
msvcrt.dll!77c2c3e7()
msvcrt.dll!77c2c42e()
x265.exe!004ae16a()
x265.exe!0072ef8e()
x265.exe!00459480()
msvcrt.dll!77c2c3ce()
x265.exe!00412352()
ntdll.dll!7c91003d()
msvcrt.dll!77c2c3c9()
msvcrt.dll!77c2c3ce()
x265.exe!006b6b36()
ntdll.dll!7c91003d()
msvcrt.dll!77c2c2de()
msvcrt.dll!77c2c2e3()
x265.exe!0040ad78()
x265.exe!0070327d()
x265.exe!00405f6f()
x265.exe!00406873()
x265.exe!0040410a()
x265.exe!00730896()
kernel32.dll!7c80e63b()
kernel32.dll!7c80e6bb()
ntdll.dll!7c917de9()
ntdll.dll!7c91a17b()
ntdll.dll!7c919ca7()
ntdll.dll!7c919dcd()
ntdll.dll!7c919d8a()
kernel32.dll!7c809e05()
msvcrt.dll!77c39f8e()
x265.exe!006bc6d3()
x265.exe!006b6ad8()
x265.exe!006b6b36()
x265.exe!006b56ff()
x265.exe!00401402()
x265.exe!00401402()
ntdll.dll!7c90d89c()
kernel32.dll!7c80a4cb()
kernel32.dll!7c817067()
x265.exe!00750074()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()

[DarrellS]

According to bitbucket, they fixed bug in WinXP mode and added visual leak detector yesterday.

https://bitbucket.org/multicoreware/x265/commits/9f38435eee26dfc31d7fbd81ca5357f4a5b4d5b8

[tnti]

No!

> x265.exe!004a9bb2()
[Frames below may be incorrect and/or missing, no symbols loaded for x265.exe]
msvcrt.dll!77c2c3ce()
msvcrt.dll!77c2c3e7()
msvcrt.dll!77c2c42e()
x265.exe!004ae16a()
x265.exe!0072ef8e()
x265.exe!00459480()
msvcrt.dll!77c2c3ce()
x265.exe!00412352()
ntdll.dll!7c91003d()
msvcrt.dll!77c2c3c9()
msvcrt.dll!77c2c3ce()
x265.exe!006b6b36()
ntdll.dll!7c91003d()
msvcrt.dll!77c2c2de()
msvcrt.dll!77c2c2e3()
x265.exe!0040ad78()
x265.exe!0070327d()
x265.exe!00405f6f()
x265.exe!00406873()
x265.exe!0040410a()
x265.exe!00730896()
kernel32.dll!7c80e63b()
kernel32.dll!7c80e6bb()
ntdll.dll!7c917de9()
ntdll.dll!7c91a17b()
ntdll.dll!7c919ca7()
ntdll.dll!7c919dcd()
ntdll.dll!7c919d8a()
kernel32.dll!7c809e05()
msvcrt.dll!77c39f8e()
x265.exe!006bc6d3()
x265.exe!006b6ad8()
x265.exe!006b6b36()
x265.exe!006b56ff()
x265.exe!00401402()
x265.exe!00401402()
ntdll.dll!7c90d89c()
kernel32.dll!7c80a4cb()
kernel32.dll!7c817067()
x265.exe!00750074()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()
x265.exe!00630063()

reinstall operating system then install Microsoft visual c++ runtime library

[DarrellS]

I reinstalled OS last week. I don't think I want to do it again this week. I'll just wait until they get it working in XP mode. Maybe I have a small HDD laying around somewhere I can load a fresh copy just for encoding x265.

[El Heggunte]

........

reinstall operating system then install Microsoft visual c++ runtime library

You are kidding alright.

[tnti]

I reinstalled OS last week. I don't think I want to do it again this week. I'll just wait until they get it working in XP mode. Maybe I have a small HDD laying around somewhere I can load a fresh copy just for encoding x265.

http://www.mediafire.com/download/32nt338f89899tf/x265.7z
Can use？


Administrator@WIN7-20130701TT ~
$ cd E:/x265/source/build

Administrator@WIN7-20130701TT /e/x265/source/build
$ cmake -G "Visual Studio 11" -D_WIN32_WINNT=_WIN32_WINNT_WINXP ..
-- Building for: Visual Studio 11
-- The C compiler identification is MSVC 17.0.60610.1
-- The CXX compiler identification is MSVC 17.0.60610.1
-- Check for working C compiler using: Visual Studio 11
-- Check for working C compiler using: Visual Studio 11 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 11
-- Check for working CXX compiler using: Visual Studio 11 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found yasm: E:/MSYS/bin/yasm.exe (found version "1.2.0")
-- Found Yasm 1.2.0 to build assembly primitives
-- Found VLD: C:/Program Files (x86)/Visual Leak Detector (found version "2.3.0"
)
-- x265 version 0.3+500-8cbc34f927b6
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:

_WIN32_WINNT


-- Build files have been written to: E:/x265/source/build

Administrator@WIN7-20130701TT /e/x265/source/build
$

[El Heggunte]

........

http://www.mediafire.com/download/32nt338f89899tf/x265.7z
Can use?

NOPE.

Reason: The compiler itself must be set up for supporting Windows XP

The "XP-friendly" cMake files are necessary, BUT are not sufficient.

[tnti]

........

http://www.mediafire.com/download/32nt338f89899tf/x265.7z
Can use?

NOPE.

Reason: The compiler itself must be set up for supporting Windows XP

The "XP-friendly" cMake files are necessary, BUT are not sufficient.

http://www.mediafire.com/download/lrt8hscymi5ya18/x265.7z
Can use？
vs11 WINXP=turn on

[El Heggunte]

We'd better "do nothing" until Tom chimes in again.

[tnti]

We'd better "do nothing" until Tom chimes in again.

Steve's mailbox can offer to me?

[El Heggunte]

We'd better "do nothing" until Tom chimes in again.

Steve's mailbox can offer to me?

*
tnti

.....................

http://mailman.videolan.org/listinfo/x265-devel

smtp://steve_àtt_borho_dótt_org

[tnti]

We'd better "do nothing" until Tom chimes in again.

Steve's mailbox can offer to me?

*
tnti

.....................

http://mailman.videolan.org/listinfo/x265-devel

smtp://steve_àtt_borho_dótt_org

Dear,
I'm already successfully downloaded and tested the testing stream, then i found that shows some black blocks when we try to decode your's streaming by using strongene decoder. and also we got broken pictures when we decoding DIVX streaming by using HM12 decoder.
i believe that problem not caused by us, you can test it with a new version HM12.0. we got the same result when we decoding yours streaming by using HM12 and Strongene decoder. For Divx Streaming we got crashed when we decoding by HM decoder.
According to my guess, this is due to DIVX and x265 only compatible with an old version HM decoder (such as HM11).the latest version HM wpp syntax has been modified,so that we can't decode it prefect. For our Strongene decoder, we can only guarantee that compatible streaming which encoding by the newest version encoder except encoding by any version of Strongene Encoder.
i hope you can contact the x265 devoloper to confirm our statement to them, and also recommend them to upgrade their encoder as soon as possible.
Thanks a lot.

Sincerely.

please help me to tell Steve

[El Heggunte]

Commit c881d82 is out,
please goto post #1 again =^.^=

[El Heggunte]

@ tnti: Sorry, but I think you really should improve very-much your English before posting to English-speaking forums again.

Anyway, I think your post to the x265 mailing list was "sufficiently-clear" , so to speak.

Last but not least, you should URGENTLY learn when to quote and how to quote

[tnti]

my english is not good...I used translator for translating these....

[El Heggunte]

For the record:

Vid01 has reported the following problem to the x265 mailing list:

Just came back after a few days of vacation and tried to build the latest and greatest x265 on my MinGW GCC 4.7.1-TDM setup. It builds fine, but I am getting this at the final step during link:

encoder/libencoder.a(framefilter.cpp.obj):framefilter.cpp: (.text+0x75d) : undefined reference to `__sync_val_compare_and_swap_4'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [x265.exe] Error 1
make[1]: *** [CMakeFiles/x265.dir/all] Error 2
make: *** [all] Error 2

After some quick investigation on the internet, it looks like one solution to the problem is to add -march=i486 to the compiler flags. This enables a successful link and the executable runs correctly as far as I can see. Other (better) solutions might exist and personally I'd be happy to not have to specify -march switches for the build if possible.

However, the reported problem didn't happen when I compiled the latest commit through GCC 4.8.1

But wait, there is more:

Your build of revision c881d82f9d85 you posted on videohelp crashes for me on my encode standard benchmark/test: It displays the header information, then shows something along the lines of
0 frames: 0.00 fps, 0.02 kb/s
and then crashes. The GCC 4.7.1 build I generate using the -march=i486 switch seems to run OK and generates an encoded stream. I have no idea why the 4.8.1 build bombs. Are you checking the XP compatibility checkbox in the cmake options by any chance? If so, can you try building without it? It should be unnecessary if you are building with GCC anyway.

[DarrellS]

I assume that we won't have a working encoder for XP until September then (hopefully)?

[Vid01]

I was not planning to make any builds public since plenty of users are posting them here already, but the latest instabilities noted, together with the Windows XP issues, together with the fact that the project is in constant development anyway and no nightly builds services exist yet, have made me change my mind a bit. I invite anyone interested in x265 testing to have a go at this build below, based on revision 0.3+504-c881d82f9d85. It is the same revision as El Heggunte's latest, although as already mentioned, for some reason I cannot run El Heggunte's binary on my system, which is Windows 7 32-bit Enterprise.

x265.exe revision 0.3+504-c881d82f9d85-Vid01

The file has undergone a 46-engine scan for viruses through virustotal.com (security report is at http://www.virustotal.com/en/file/449a6820a8831abde61cfcb23b88721d979dd9a3803fc37aa2b9...is/1377423592/ ) prior to being uploaded.

In my tests, this binary shows a slight but measurable performance increase compared to what we've seen so far. On my standard benchmark test, this build scores approximately 1.74 fps against 1.57 of the other builds uploaded so far. I'd be interested to know if this is repeatable on other systems too.

One last thing: I believe that someone (we or the Multicoreware people) should create and/or make public a standard test sequence, based on which we can have hard evidence of performance changes. For what is worth, I am using a 2GB yuv file, of which the first 100 frames are encoded using this command:
x265 --input stream.yuv --width 720 --height 480 --rate 24 -o stream.h265 --rect --max-merge 1 --hash 1 --wpp --tu-intra-depth 1 --tu-inter-depth 2 --no-tskip -f 100
Further tests can be run using different switches of course, but the bare minimum is this and this is what I use in order to check speed improvements. I understand others have different switch sets and test files, but maybe agreeing on a standard to be used by all might make testing much more hassle-free.

[El Heggunte]

@ Vid01: many thanks for being back,

and for sharing you .EXE too, of course.

For the time being, I don't have much more to say, so
I will just add some quotes from the Doom9 x265 thread <= clicky

LigH

I played a bit more with options and got some buggy results, green and pink squares popping up now and then; I believe it is related to shortcut options?

x265.exe sintel_trailer_1080.y4m -o sintel_trailer_1080.hevc -q 20 -b 3 --weightp --weightbp --early-skip --fast-cbf

filler56789

-b N => currently this setting is problematic for the Lentoid DirectShow decoder; add to that the Wavefront Parallel Processing (which now is enabled by default), and the problems may get even worse.


LigH

It was played with GPAC 0.5.1 Nightlies' Osmo4. I doubt this one uses DS filters?

filler56789

So you can conclude the OpenHEVC decoder is not that good either

x265_Project

If you have an encoded bitstream that can't be decoded perfectly by a particular decoder, and you are wondering whether the encoded stream is compliant with the HEVC specifications or not, I suggest that you use the HM reference decoder to decode to YUV, then use YUVplayer to examine the decoded frames. This will answer your question (is it the encoder, or the decoder that is not working properly?) Of course, uncompressed YUV video requires a lot of storage space, so be sure that you limit the number of frames you are decoding.

Tom

[vhelp]

hi all.

I invite anyone interested in x265 testing to have a go at this build below, based on revision 0.3+504-c881d82f9d85. It is the same revision as El Heggunte's latest, although as already mentioned, for some reason I cannot run El Heggunte's binary on my system, which is Windows 7 32-bit Enterprise.

i did some quick testing with x265_0.3+504-c881d82f9d85-Vid01 and found that it works fine under my current specs:
* desktop pc, windows xp home sp2, amd dual core 3600+, 2gig ram, built-in graphics card, ds hevcdecfltr.dll v2.0.1.6 for preview/playback

just to report back that the above build works fine on my system specs except to note the same mem leak. also, there is no real-time progress report under dos console when piping through front-end tools, or maybe its my gui. something may have changed in the way the output is interpreted for the c881d82 build. these are my current results so far:

specs: (amd dual core 3600+ 2g ram win xp sp2) (122 frames, 720x480 24fps)

--frames 122 --q 20 --keyint 24 --rect --max-merge 1 --hash 1 --no-wpp --no-rdo --no-rdoq --tu-intra-depth 1 --tu-inter-depth 2 --no-tskip --input "_video.y4m" -o "video.hm10"
--frames 122 --q 20 --keyint 24 --rect --max-merge 1 --hash 1    --wpp --no-rdo --no-rdoq --tu-intra-depth 1 --tu-inter-depth 2 --no-tskip --input "_video.y4m" -o "video.hm10"
--frames 122 --q 20 --keyint 24 --rect --max-merge 1 --hash 1    --wpp --no-rdo --no-rdoq --tu-intra-depth 1 --tu-inter-depth 1 --no-tskip --input "_video.y4m" -o "video.hm10"
--frames 122 --q 20 --keyint 24 --rect --max-merge 1 --hash 1    --wpp --no-rdo --no-rdoq --tu-intra-depth 1 --tu-inter-depth 1 --no-tskip --input "_video.y4m" -o "video.hm10"

* 77418bf, 228.88s (0.53 fps) (--no-wpp)
* 77418bf, 132.30s (0.90 fps) (   --wpp) and without adding --wpp, same results
* 77418bf, 116.12s (1.05 fps) (   --wpp) and (--tu-inter-depth 1)
* c881d82, 111.25s (1.10 fps) (   --wpp) and (--tu-inter-depth 1)

One last thing: .. create and/or make public a standard test sequence, based on which we can have hard evidence of performance changes. For what is worth, I am using a 2GB yuv file, of which the first 100 frames are encoded using this command:

x265 --input stream.yuv --width 720 --height 480 --rate 24 -o stream.h265 --rect --max-merge 1 --hash 1 --wpp --tu-intra-depth 1 --tu-inter-depth 2 --no-tskip -f 100

agreed. but could we also include 720x480 dimensions in that standard since this is all i (maybe others too) encode, i am not ready for hd content at this time. plus, on slower system specs, hd testing is too exhausting/timeconsuming to process completely under many testings

[ozok]

I too have memory leak with build from Vid01.

[Vid01]

I too have memory leak with build from Vid01.

Confirmed also here. It is a problem currently in the code base, not of the build itself.

[DarrellS]

I too have memory leak with build from Vid01.

Confirmed also here. It is a problem currently in the code base, not of the build itself.

Right, which is why I assumed we would have to wait until September for a fixed version. The memory leak isn't confines to just XP then although the --wpp issue seems to be. I was getting around 2.5fps with --wpp but the files are not playable. I can only use --no-wpp and only in older builds.

Well, back to trying to fix my PC because I took someone's advice to reinstall Windows XP which is running fine (haven't tried any encodes yet) but now I can't get my old drive to run properly. I'm having an issue with My Computer and Windows Explorer taking forever to load (tried recommended fixes but did not work). I thought it was a cable issue so I tried to replace the IDE cable (my boot drive and one DVD burner is IDE) but somehow bent the pins and had to tear the computer down and take the MB out to straighten the pins and reconnect the IDE cable (I hate these sideways IDE connectors on Gigabyte boards). That didn't solve the problem so I'll have to restore a backup from a few days ago and hope that it's not corrupt also or I'll have to install a backup from June which means I'll lose a bunch of stuff I've installed since then.

[vhelp]

what .extention are you using during encode and what software (and decoder) are you playing them in ?

i am using .hm10 because the directshow filter hevcdecfltr.dll v2.0.1.6 plays them fine (video only) in my gui's built-in player. but if i call the encoded file as .h265, then it won't play, post # 350. maybe that is your problem ? and/or, maybe you need to re-uninstall and re-install the strongene lentoid hevcdecfltr.dll decoder. i know you know but maybe others here don't, so, just in case:

regsvr32 hevcdecfltr.dll /u --> to uninstall

regsvr32 hevcdecfltr.dll --> to reinstall

edit: just to note, i have found that every so often, i have to reinstall the darn decoder. i don't know what corrupts it, but thats what i have to do from time to time.

[El Heggunte]

edit: just to note, i have found that every so often, i have to reinstall the darn decoder. i don't know what corrupts it, but thats what i have to do from time to time.

Possibility 1: faulty antivirus or/and firewall ;

Possibility 2: bad sectors on the HDD --- test it with chkdsk /f /r /v
Also, and regardless of the "health status" of the HDD, use always and only a REAL defragmenter, I mean, one which *actually* changes the location of the files and directory entries

[vhelp]

i haven't defrag'ed in years. its just like you said in last sentence. and for my sys specs, there just isn't a fast enough defrag'er like the once old optune. they all takes hour to do. plus, even defrag'ing (due to ms os strategy/design is intentional) will always fragment at every startup *and* daily use, thus, its pointless.

[vhelp]

@ozok, when you get a chance, can you double-check your gui (i still can't get yours to work on my pc) to see it is working the same ?

my gui's piping for this x265 c881d82 build is not releasing its PID/handle. it returns '0' and the only way to close it down is to go into taskmgr and manually close it. however, all other x265 builds work as before. something stange about this build.

edit 1: i found where the problem is. it is the routine that obtains the cpu usage. pid/handle are returned when i comment out that code. the routine seems incompatible to this particular x265 build.
edit 2: resolved. small programming bug. all is working correctly again

[Jacobr]

Are you 100% sure that we can now use wpp? On my laptop, using the last non-leak build ( sorry, don't remember the name ), i was still unable to play it back with lentoud decoder, that .12 new version, mind you.
Also, just for the notes, any1 interested in simplistic gui avi/mp4/mkv->mp4/mkv with hevc video?

edit: oh, just found the new ozok's gui. fabulous work, puts my script to shame, though it still can remux things automatically

[El Heggunte]

i haven't defrag'ed in years.

Hopefully you didn't mean you haven't run chkdsk in years

[vhelp]

i haven't, for both. well, actually, i tried your chkdsk /f /r /v but doesn't work in dos/window. have to reboot into dos only. but my fingers are too slow betwen those boot cycles.