Hey sr55, a MinGW Windows binary is up for you to test

mirkwood · Post by **mirkwood** » Tue Jan 09, 2007 5:14 am

sr55 (and anyone other Windoze beta testers interested),

I put a zip of HBTest.exe built using MinGW gcc up on the FTP site in the beta/Windows directory. It's HBTest-r100-mingw.zip. It contains just HBTest.exe, you shouldn't need any other libraries beyond the normal ones that come with Windows.

This build still has a number of issues, nothing I mentioned here on the forum yesterday is fixed, I just want you to try this MinGW build and see if you can encode a full movie with x264 without it dying. Keep an eye on frame rate and memory usage. I think there might be a memory leak somewhere as you noticed.

johnallen backed out his thread delay changes so you might be back down to 75-80% CPU usage.

And can you also try doing a 2-pass ffmpeg encode of something? Just pick a short chapter on a DVD so you don't have to wait forever, and just specify the ffmpeg encoder and let it pick the audio encoder automatically, for either .mp4, .avi, or .ogm output formats. The result I'm getting with a 2-pass ffmpeg encode is that the output file has a very low quality video bitrate of 100kbps, and thus looks like crap.

Make sure to run HBTest.exe from a Windows command shell (cmd.exe) and not from a Cygwin bash shell.

Let me know your results!

Post by **s55** » Tue Jan 09, 2007 5:44 pm

0.7.2 failed at 55.2MB output filesize twice on the One tree hill dvd. It was supposed to be running on 0.7.0 overnight but i mixed the exes up so its running now

Post by **s55** » Tue Jan 09, 2007 7:07 pm

No memory leak with 0.7.0 constant 50MB
31% and its not died yet. if its gonna die should be withing the next 10% as thats where 0.7.2 died twice.

Post by **s55** » Tue Jan 09, 2007 7:58 pm

49% 34MB ram usage. hasnt died yet so looks like theres alot of problems with 0.7.2 that are needing sorting

John may have removed his dodgy threading code so that might fix some/all of the issues. I dont know if u want to recompile with mingw b4 i start testing it

.7.0 looks solid.

mirkwood · Post by **mirkwood** » Tue Jan 09, 2007 8:00 pm

sr55 wrote:John may have removed his dodgy threading code so that might fix some/all of the issues. I dont know if u want to recompile with mingw b4 i start testing it

I tried to imply above that the MinGW binary I have up for you is already compiled without John's changes, it was compiled with the latest trunk last night after John removed the thread delay changes.

Post by **s55** » Tue Jan 09, 2007 9:47 pm

Ok, we still have a memory leak here. Ram usage is at 250MB at the moment only 16% into the encode.

On the bright side however this version doesn't seem to be slowing down to silly frame rates. IT appears to have managed a steady 20~23fps which seems reasonable. I'll report back if that suddenly disappears.

Processor usage is still 90% +/- 10

mirkwood · Post by **mirkwood** » Tue Jan 09, 2007 10:31 pm

sr55 wrote:No memory leak with 0.7.0 constant 50MB
31% and its not died yet.

Are you doing x264 encodes with 0.7.0 and 0.7.1? Last time I checked, x264 encodes for me with 0.7.0 and 0.7.1 hang or crash, which is the entire reason I got involved with compiling HandBrake on Windoze, to get rid of that.

But if x264 works for you with 0.7.0 and 0.7.1, then that's odd...I'll have to try again.

Post by **s55** » Tue Jan 09, 2007 11:15 pm

All X264 Encodes ATM

Your Rev100 MingW Build seems to encode OK but has memoryleaks and performance problems

Rev99 kept crashing at around 33~36% with those stack errors. With john code removed now in rev100 it seems to have cured that problem, or maybe something else did? I dunno. Rev100 works its just a tad leaky. 500MB ram usage b4 i killed it there as it had slowed to a crawl, 15fps reported. Actual seemed to be alot less

0.7.0 Works perfectly although its quite slow. There are other issues with it like 2pass/deinterlace which just break it 9 times out of 10

mirkwood · Post by **mirkwood** » Tue Jan 09, 2007 11:23 pm

sr55 wrote:0.7.0 Works perfectly although its quite slow. There are other issues with it like 2pass/deinterlace which just break it 9 times out of 10

Oh right 2 pass x264 breaks with 0.7.0 and 0.7.1, that must have been the problem I was having, that sounds familiar.

Post by **s55** » Wed Jan 10, 2007 12:29 am

Anyway, Theres a pretty major memory leak here and it looks like its cross platform. It may also be causing major performance issues as well. Just need to find out what change caused it and remove it. Hopefully its that simple

johnallen · Post by **johnallen** » Wed Jan 10, 2007 2:27 am

I'll try to make my changes less "dodgy" in the future.