[HEVC] x265.EXE: mingw builds

[ozok]

Yes, as Brazil said mp4box included in my gui wasn't standalone build, so I added necessary(hopefully) dlls to package and re-uploaded it.

[Marchand]

x265gui_build89 is working perfectly. Look at the result of the video and audio:

https://shared.com/mn0q7p8he3

ffmpeg version N-55159-gf118b41 Copyright (c) 2000-2013 the FFmpeg developers
built on Aug 1 2013 18:04:40 with gcc 4.7.3 (GCC)
configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 52. 40.100 / 52. 40.100
libavcodec 55. 19.100 / 55. 19.100
libavformat 55. 12.102 / 55. 12.102
libavdevice 55. 3.100 / 55. 3.100
libavfilter 3. 82.100 / 3. 82.100
libswscale 2. 4.100 / 2. 4.100
libswresample 0. 17.103 / 0. 17.103
libpostproc 52. 3.100 / 52. 3.100
Input #0, mpegts, from 'C:\Users\Marchand\Videos\00200.1.m2ts':
Duration: 00:00:07.50, start: 11.608967, bitrate: 41182 kb/s
Program 1
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
Stream #0:1[0x1100]: Audio: dts (DTS-HD MA) ([134][0][0][0] / 0x0086), 48000 Hz, 5.1(side), fltp, 1536 kb/s
Output #0, rawvideo, to 'C:\Users\Marchand\Videos\00200.1.yuv':
Metadata:
encoder : Lavf55.12.102
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 23.98 tbc
Stream mapping:
Stream #0:0 -> #0:0 (h264 -> rawvideo)
Press [q] to stop, [?] for help
frame= 180 fps= 84 q=0.0 Lsize= 109350kB time=00:00:07.50 bitrate=119320.0kbits/s dup=1 drop=0
video:109350kB audio:0kB subtitle:0 global headers:0kB muxing overhead 0.000000%

ffmpeg version N-55159-gf118b41 Copyright (c) 2000-2013 the FFmpeg developers
built on Aug 1 2013 18:04:40 with gcc 4.7.3 (GCC)
configuration: --disable-static --enable-shared --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libcaca --enable-libfreetype --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib
libavutil 52. 40.100 / 52. 40.100
libavcodec 55. 19.100 / 55. 19.100
libavformat 55. 12.102 / 55. 12.102
libavdevice 55. 3.100 / 55. 3.100
libavfilter 3. 82.100 / 3. 82.100
libswscale 2. 4.100 / 2. 4.100
libswresample 0. 17.103 / 0. 17.103
libpostproc 52. 3.100 / 52. 3.100
Input #0, mpegts, from 'C:\Users\Marchand\Videos\00200.1.m2ts':
Duration: 00:00:07.50, start: 11.608967, bitrate: 41182 kb/s
Program 1
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc
Stream #0:1[0x1100]: Audio: dts (DTS-HD MA) ([134][0][0][0] / 0x0086), 48000 Hz, 5.1(side), fltp, 1536 kb/s
Output #0, ipod, to 'C:\Users\Marchand\Videos\00200.1.m4a':
Metadata:
encoder : Lavf55.12.102
Stream #0:0: Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s
Stream mapping:
Stream #0:1 -> #0:0 (dca -> aac)
Press [q] to stop, [?] for help
size= 120kB time=00:00:07.46 bitrate= 131.7kbits/s
video:0kB audio:118kB subtitle:0 global headers:0kB muxing overhead 1.771538%

yuv [info]: 720x576 25Hz, frames 0 - 179 of 180
x265 [info]: detected SIMD architectures SSE2 SSE3 SSSE3 SSE4.1
x265 [info]: performance primitives: intrinsic assembly
x265 [info]: Main profile, Level-3 (Main tier)
x265 [info]: thread pool with 4 threads, WPP enabled
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME method / range / maxmerge : star / 64 / 5
x265 [info]: Keyframe Interval : 28
x265 [info]: WaveFrontSubstreams : 9
x265 [info]: QP : 32
x265 [info]: enabled coding tools: rect amp rdo rdoq lft sao sao-lcu sign-hide tskip tskip-fast rdoqts
[100.0%] 180/180 frames, 0.69 fps, 257.48 kb/s, eta 0:00:00
encoded 180 frames in 260.22s (0.69 fps), 257.48 kb/s
x265 [info]: frame I:7 kb/s: 1836.80 PSNR Mean: Y:48.622 U:48.514 V:42.995
x265 [info]: frame P:173 kb/s: 192.66 PSNR Mean: Y:38.853 U:39.368 V:40.749
x265 [info]: global: kb/s: 256.60 PSNR Mean: Y:39.233 U:39.723 V:40.836

HEVC import - frame size 720 x 576 at 25.000 FPS
HEVC Import results: 180 samples - Slices: 7 I 173 P 0 B - 0 SEI - 1 IDR
IsoMedia import 00200.1.m4a - track ID 1 - Audio (SR 48000 - 2 channels)
Saving to C:\Users\Marchand\Videos\00200.1.mp4: 0.500 secs Interleaving

General
Complete name : C:\Users\Marchand\Videos\00200.1.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : iso4
File size : 348 KiB
Duration : 7s 465ms
Overall bit rate mode : Variable
Overall bit rate : 382 Kbps
Encoded date : UTC 2013-08-20 23:18:23
Tagged date : UTC 2013-08-20 23:18:23

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L9.0
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 7s 200ms
Bit rate : 257 Kbps
Maximum bit rate : 328 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 5:4
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.025
Stream size : 226 KiB (65%)
Title : 1.h265:FMT=HEVC@GPAC0.5.1-DEV-rev4707
Encoded date : UTC 2013-08-20 23:18:23
Tagged date : UTC 2013-08-20 23:18:23

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 7s 465ms
Source duration : 7s 488ms
Bit rate mode : Variable
Bit rate : 129 Kbps
Maximum bit rate : 141 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -21ms
Stream size : 118 KiB (34%)
Source stream size : 118 KiB (34%)
Tagged date : UTC 2013-08-20 23:18:23

[vhelp]

i saw this update at bitbuket, 'min chen, 9f38435 fix bug in WinXP mode' but no download. but don't know if that means the mem link or some other fix i'm not aware of.

[El Heggunte]

Commit 9f38435 itself MIGHT work, BUT something between it and 6fe2b6e
has made the source-code "not-compileable" (various errors at 82% of the process)
I've posted to the mailing list already, but no replies thus far.

EDIT: commit 1d890ba uploaded some minutes ago.

[vhelp]

thank you.. was not aware of this.. will wait for the next version to be released.

[Trepack]

Up-to-date Whit commit 77418bf
Build info [Windows][GCC 4.8.1][32 bit] 8bpp

x265 encoder version 0.3+488-77418bf4a67b

[El Heggunte]

^ Thanks for that ,
BTW I've updated post #1 (again).

Regarding the memory leaks: I really cannot confirm them, because first,
my test encodes are always very-short, and secondly,
I make them even shorter by dividing them into several pieces,
all of which are joined later through the olde-n-goode copy /b

[El Heggunte]

Now the latest binary is 41f2025

Just for the notes, yeah, now the dämn thing is being compiled MUCH faster

[DarrellS]

Is anyone using any of the settings that are supposed to speed up the encoding? I've tried everything in the PDF (the updated pdf has even more options) but every single one makes the encoding slower. Last attempt with new command line was 0.10 fps.

What kinds of encode speeds are people getting with what CPUs and with what command lines? I just can't see using this encoder for any kind of serious encoding if I can't get at least 5 fps and all these encodes under 0.80 fps just ain't gettin' it. It would be nice to get over 1.0 fps. I was getting more than that with the Lentoid encoder and I was getting at least 0.50 with the slowest TAppencoder.

These guys are going to have to make a lot of serious advances before the next release if they expect to compete with the other guys. I think they need to add a lot more features from the x264 codec like a superfast or ultrafast preset so it could be at least 1/100th as fast as x264. Maybe call them snail and worm preset.

I don't see myself building a $10,000 computer (or even a $3,000 computer) in the near future (or any other kind of future) which is what it would take to get any kind of encode speeds. Wonder what a 4K disc player and 4k TV will cost.

I guess all the professional athletes and movie stars will be able to afford them

[vhelp]

These guys are going to have to make a lot of serious advances before the next release if they expect to compete with the other guys.

yeah, and also, they need to fix that mem leak. it is also in the lastest 77418bf build. it looks like they enlarged the cache that is causing the mem leak because the taskmgr graph is more spread out now. iow, instead of 5 tics to eat up 500mb its not 15 tics, something like that. and that was on just 122 test frames.

i am guessing that they are spending their time only cleaning code they understand. but while they are doing that they are causing problems, like the mem leak. i suspect they are not testing the encoder. and now that they know there is a mem leak, they should consider investigating and fixing so they can avoid in advance in future cleaning/upgrading code snipets. or else its a big damper and leaves a sour taste in my assurance of this (x265.exe) encoder.

i'm still (preferably ) behind the times, 4k is not on my list. 720x480 is enough for me at this point in time.

[x265]

I would suggest that you use these settings for reasonable performance...

--rect --max-merge 1 --hash 1 --wpp --no-rdo --no-rdoq --tu-intra-depth 1 --tu-inter-depth 2 --no-tskip

Adding B frames, turning RDO on, or increasing the intra or inter depth will cause x265 to run considerably slower.

Our team is focused right now on implementing better frame-level parallelism, look-ahead, and rate control. Details of the development roadmap are posted on the x265 repository on Bitbucket.

Performance will continue to improve over the coming weeks and months (you didn't think we were done yet, did you?)

Yes, we are testing the encoder constantly, using a wide variety of test sequences. Whenever you develop new features or do performance optimization, bugs happen. As we test and find bugs, we squash them. As an open source project, we welcome and encourage participation from anyone who is able to constructively contribute, and we appreciate the feedback and contributions we have received so far.

Thanks!
Tom

[Marchand]

I would suggest that you use these settings for reasonable performance...
--rect --max-merge 1 --hash 1 --wpp --no-rdo --no-rdoq --tu-intra-depth 1 --tu-inter-depth 2 --no-tskip

Configurations tested and approved. thank you

General
Complete name : C:\Users\Marchand\Videos\00200.1.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : iso4
File size : 357 KiB
Duration : 7s 465ms
Overall bit rate mode : Variable
Overall bit rate : 391 Kbps
Encoded date : UTC 2013-08-23 00:46:35
Tagged date : UTC 2013-08-23 00:46:35

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L9.0
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 7s 200ms
Bit rate : 267 Kbps
Maximum bit rate : 333 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate mode : Constant
Frame rate : 25.000 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.031
Stream size : 235 KiB (66%)
Title : 1.h265:FMT=HEVC@GPAC0.5.1-DEV-rev4704+53 git-de3a049
Encoded date : UTC 2013-08-23 00:46:35
Tagged date : UTC 2013-08-23 00:46:35

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 7s 465ms
Source duration : 7s 488ms
Bit rate mode : Variable
Bit rate : 129 Kbps
Maximum bit rate : 141 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -21ms
Stream size : 118 KiB (33%)
Source stream size : 118 KiB (33%)
Tagged date : UTC 2013-08-23 00:46:35

[vhelp]

Yes, we are testing the encoder constantly, using a wide variety of test sequences. Whenever you develop new features or do performance optimization, bugs happen.

may i make the suggestion? ..please use taskmgr, in performance view to quickly spot there are memory leaks, and then sqash them! because you are not seeing them otherwise. the leaks started a few updates ago, i can't determine which x265.exe file it started because the commit signature is not in the file that i can see.

[vhelp]

yes, confirmed.. speed has noticably improved using the suggested (new) parameter changes below.

old:

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

260.69s (0.47 fps) (122 frames, amd dual core, xp sp2)

new:

x265 --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" --output "video.hm10"

135.75s (0.90 fps) (122 frames, amd dual core, xp sp2)

edit 1: corrected my copy/pastes entries.
edit 2: corrected encoding tests results (i re-ran again to make sure)

[El Heggunte]

@ vhelp

[C:\]
=>x265 -V

x265 [info]: HEVC encoder version 0.3+236-83def5041252
x265 [info]: build info [Windows][GCC 4.8.1][32 bit] 8bpp

Notice, it's an uppercase V.

[DarrellS]

Well, I wasn't running into the memory issue until I changed the settings and now it won't run past 7.9%. I had to use --no-wpp before. Speed jumped dramatically to 2.47 fps with Q6600 CPU at stock speed (2.4Ghz) on XP Pro with 4GB DDR2 1066 memory.

Switched back to 3+355 and still got 2.37fps with no memory issues. Interested in seeing what 3+488 will do without the memory crashes.

EDIT: No, I'm back to where I started. The output file doesn't play. I can't use --wpp and I can't use --no-wpp with the new settings so It looks like I'm stuck with slow encodes. I was getting faster encodes to begin with but none of them would play

Back to the drawing board.

[DarrellS]

Went back to --no-wpp and I'm running steady at 1.04 fps in 3+355. No higher and no lower so at least it is consistent. CPU is right around 30% and memory is right at 1.15GB. Both could be higher if I'm going to get a faster speed but without --wpp, I don't think that's going to happen. I'll try a newer build and see. I don't believe that I had a memory issue while not using --wpp. I'll see.

[tnti]

Went back to --no-wpp and I'm running steady at 1.04 fps in 3+355. No higher and no lower so at least it is consistent. CPU is right around 30% and memory is right at 1.15GB. Both could be higher if I'm going to get a faster speed but without --wpp, I don't think that's going to happen. I'll try a newer build and see. I don't believe that I had a memory issue while not using --wpp. I'll see.

http://xhevc.com/en/downloads/downloadCenter.jsp
Strongene PC HEVC/H.265 Decoder
Release Date: 2013/8/22
enjoy, profit

[DarrellS]

Thanks!

[mindwin]

DivX player + HEVC decoder plays fine videos encoded with "-wpp" option,
but Strongene HEVC Decoder does not (artifacts + hangs MPC).

[vhelp]

my experience using the following, with (--wpp) vs without (--no-wpp) vs without adding --wpp, used in the param string below:

x265  --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" --output "video.hm10"

132.30s (0.90 fps) (122 frames, amd dual core, xp sp2) (--wpp) and without adding --wpp.

x265  --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" --output "video.hm10"

228.88s (0.53 fps) (122 frames, amd dual core, xp sp2) (--no-wpp)

0. latest build used: 'x265 [info]: HEVC encoder version 0.3+488-77418bf4a67b'
1. bug: (crashes) i get random x265 crashing out during encode.
2. warning: (parameter order) i don't know if placement of certain or all param code matters. i don't see that noted anywhere.
3. bug: (parameters, used/not used as defaults) regarding: --wpp vs --no-wpp vs 'not adding --wpp'
it seems that encoding speed is the same if param string has --wpp or --wpp removed. i suspect that certain parameters are included by default - if left out completely - so, we don't know if certain parameter commands are being used. so in addition to the --wpp, there is no way of knowing what other params are being added/removed by deault during encoding.
4. bug: (console report) encoding speed reporting seems wrong. i saw clearly 2+ fps while it reported less than 1 fps.

[vhelp]

this change gave me even faster encode, 3rd encode:

x265  --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" --output "video.hm10"

228.88s (0.53 fps) (122 frames, amd dual core, xp sp2) (--no-wpp)

x265  --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" --output "video.hm10"

132.30s (0.90 fps) (122 frames, amd dual core, xp sp2) (--wpp) and without adding --wpp.

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

116.12s (1.05 fps) (122 frames, amd dual core, xp sp2) (--wpp) and (--tu-inter-depth 1)

[tnti]

DivX player + HEVC decoder plays fine videos encoded with "-wpp" option,
but Strongene HEVC Decoder does not (artifacts + hangs MPC).

The new version can play
Strongene HEVC Decoder

[tnti]

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

how to declare a specific fps of HEVC in monogram flv mux
or set a specific fps for output in X265 settings
?

Stronggene muxing their hevc streaming by using Monogram flv mux

The Monogram FLV Muxer is not configurable.
So if you give it an input from the Lentoid HEVC Source Filter, you'll always get a 25-fps output, and AFAIK ffmpeg still cannot deal with HEVC in an FLV container --- therefore, ...

No infile stdin - ?

videolan[/url].org)]> could you please port the stdin and Avisynth support of x264 to x265?
> Because it's a matter of *usability* ---
> --- raw video files are HUGE, whereas stdin consumes no space and
> Avisynth scripts are tiny.
>

Patches welcome for either of these. stdin support should be simple,
avisynth less so but not that difficult.

"hevcsrc.dll" is the Source Filter which is used to play HEVC bitstream in DirectShow system, with the support to extensions of .hm91/.hm10/.hm12/.hevc/.265. Moreover, the input framerate in the filename can also be recognized, and the framerate format is <float>fps, like test_23.976fps.265.

[El Heggunte]

Yes, we are testing the encoder constantly, using a wide variety of test sequences. Whenever you develop new features or do performance optimization, bugs happen.

may i make the suggestion? ..please use taskmgr, in performance view to quickly spot there are memory leaks, and then sqash them! because you are not seeing them otherwise. the leaks started a few updates ago, i can't determine which x265.exe file it started because the commit signature is not in the file that i can see.

And more importantly, do the tests with the GCC builds, NOT with the MSVC builds.
Until proven otherwise, the x265 devs focus their work on the "MSVC-compatibility" so to speak. Possibly the memory leak issue doesn't happen with the MSVC builds, and so this issue and other possible issues are "non-existent" to the x265 development team.

[tnti]

Yes, we are testing the encoder constantly, using a wide variety of test sequences. Whenever you develop new features or do performance optimization, bugs happen.

may i make the suggestion? ..please use taskmgr, in performance view to quickly spot there are memory leaks, and then sqash them! because you are not seeing them otherwise. the leaks started a few updates ago, i can't determine which x265.exe file it started because the commit signature is not in the file that i can see.

And more importantly, do the tests with the GCC builds, NOT with the MSVC builds.
Until proven otherwise, the x265 devs focus their work on the "MSVC-compatibility" so to speak. Possibly the memory leak issue doesn't happen with the MSVC builds, and so this issue and other possible issues are "non-existent" to the x265 development team.

x265_0.3+500-8cbc34f927b6.7z
http://www.mediafire.com/download/cad2eb5pqcpub12/x265_0.3%2B500-8cbc34f927b6.7z
un7z, enjoy, profit

[DarrellS]

Yes, we are testing the encoder constantly, using a wide variety of test sequences. Whenever you develop new features or do performance optimization, bugs happen.

may i make the suggestion? ..please use taskmgr, in performance view to quickly spot there are memory leaks, and then sqash them! because you are not seeing them otherwise. the leaks started a few updates ago, i can't determine which x265.exe file it started because the commit signature is not in the file that i can see.

And more importantly, do the tests with the GCC builds, NOT with the MSVC builds.
Until proven otherwise, the x265 devs focus their work on the "MSVC-compatibility" so to speak. Possibly the memory leak issue doesn't happen with the MSVC builds, and so this issue and other possible issues are "non-existent" to the x265 development team.

x265_0.3+500-8cbc34f927b6.7z
http://www.mediafire.com/download/cad2eb5pqcpub12/x265_0.3%2B500-8cbc34f927b6.7z
un7z, enjoy, profit

No. Still no good. Crash, crash, crash. Where is that MSVC build to try?

[El Heggunte]

.........

x265_0.3+500-8cbc34f927b6.7z
http://www.mediafire.com/download/cad2eb5pqcpub12/x265_0.3%2B500-8cbc34f927b6.7z

My message was for Tom (x265), not for ourselves.

@ Tom (again) --- you need to include in the wiki and/or the PDFs precise instructions for creating XP-compatible MSVC binaries As I said before, the "x265.exe is not a valid Win32 application" problem hasn't been addressed yet (afaik, at least).

[tnti]

.........

x265_0.3+500-8cbc34f927b6.7z
http://www.mediafire.com/download/cad2eb5pqcpub12/x265_0.3%2B500-8cbc34f927b6.7z

My message was for Tom (x265), not for ourselves.

Also (and this one is for Tom again), you need to include in the wiki and/or the PDFs precise instructions for creating XP-compatible MSVC binaries As I said before, the "x265.exe is not a valid Win32 application" problem hasn't been addressed yet.

How to use

[tnti]

Yes, we are testing the encoder constantly, using a wide variety of test sequences. Whenever you develop new features or do performance optimization, bugs happen.

may i make the suggestion? ..please use taskmgr, in performance view to quickly spot there are memory leaks, and then sqash them! because you are not seeing them otherwise. the leaks started a few updates ago, i can't determine which x265.exe file it started because the commit signature is not in the file that i can see.

And more importantly, do the tests with the GCC builds, NOT with the MSVC builds.
Until proven otherwise, the x265 devs focus their work on the "MSVC-compatibility" so to speak. Possibly the memory leak issue doesn't happen with the MSVC builds, and so this issue and other possible issues are "non-existent" to the x265 development team.

x265_0.3+500-8cbc34f927b6.7z
http://www.mediafire.com/download/cad2eb5pqcpub12/x265_0.3%2B500-8cbc34f927b6.7z
un7z, enjoy, profit

No. Still no good. Crash, crash, crash. Where is that MSVC build to try?

http://www.mediafire.com/download/0v5usor7xum9qt4/x265.7z
Can use？