Current Patches, Where to get them, How they affect speed/output

[kemuri-_9]

yeah, it looks like gcc 4.3.4 prerelease builds have some issues, try this 4.3.3 build i did:

http://forum.doom9.org/showthread.php?p=1252595#post1252595

gcc is something you don't want to experiment with unless you want to report bugs, as generally there's lots of them.

Edit:
are you on an AMD chip btw? me and komisar have issues with that build and we're on AMD cpus...

[Fishman0919]

yeah, it looks like gcc 4.3.4 prerelease builds have some issues, try this 4.3.3 build i did:

http://forum.doom9.org/showthread.php?p=1252595#post1252595

gcc is something you don't want to experiment with unless you want to report bugs, as generally there's lots of them.

Edit:
are you on an AMD chip btw? me and komisar have issues with that build and we're on AMD cpus...

skystrife x264.1114M.x64.exe does not work on my AMD 9950 but works fine on my Intel Q6600 and Q9650. This build works fine on my AMD 9950.

[komisar]

Fishman0919, lexor, how about this test builds?
http://forum.doom9.org/showthread.php?p=1252756#post1252756
(his make with new toolchain)

[Fishman0919]

Fishman0919, lexor, how about this test builds?
http://forum.doom9.org/showthread.php?p=1252756#post1252756
(his make with new toolchain)

This one works fine on both my AMD and Intel Quad CPU's

[skystrife]

x264 r1114 02 (unpatched) (http://www.mediafire.com/?ymzozyddyw5) - Alternate Download (http://skystrife.com/x264/revision1114/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1114M.02.x86.exe (http://www.mediafire.com/?icy0m1n2zym) - Alternate Download (http://skystrife.com/x264/x264.1114M.02.x86.exe) / x264.1114M.02.x64.exe (http://www.mediafire.com/?znwjmggo0yn) - Alternate Download (http://skystrife.com/x264/x264.1114M.02.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff

I had someone who was having difficulty with the other build test the 32-bit version and it is working for him, so if you were having problems before try this build.

I still have no idea what might have caused the issue.

EDIT: x64 still has issues. -_-;

[bob0r]

Have you read the posts about the 64bit not working on some AMD systems, have you tested that?
Else use what komisar recommends.

[ash925]

thanks for new build,previous one failed with message in megui saying wrong parameter.

[skystrife]

Have you read the posts about the 64bit not working on some AMD systems, have you tested that?
Else use what komisar recommends.

It was the same message for 64 and 32 bit, so I'm hoping that I fixed both by recompiling. However, I'd need someone to check since they worked here regardless.

[kemuri-_9]

It was the same message for 64 and 32 bit, so I'm hoping that I fixed both by recompiling. However, I'd need someone to check since they worked here regardless.

x64 still broken on my AMD computers.

[skystrife]

Do you have any idea why that might be? Why would it break on just some architectures? Is it a 4.3.4 thing or ?

[kemuri-_9]

probably that revision of gcc 4.3.4 had some bugs, try a newer revision or use 4.3.3

[lexor]

x264 r1114 02 (unpatched) (http://www.mediafire.com/?ymzozyddyw5) - Alternate Download (http://skystrife.com/x264/revision1114/x264.exe)
gcc 4.3.4 fprofiled build.

-------------------------

x264.1114M.02.x86.exe (http://www.mediafire.com/?icy0m1n2zym) - Alternate Download (http://skystrife.com/x264/x264.1114M.02.x86.exe) / x264.1114M.02.x64.exe (http://www.mediafire.com/?znwjmggo0yn) - Alternate Download (http://skystrife.com/x264/x264.1114M.02.x64.exe)
gcc 3.4.5 fprofiled build with -march=pentium2. / gcc 4.3.4 fprofiled build.

Patches used:

x264_hrd_pulldown.09_interlace.diff
x264_win_zone_parse_fix_05.diff

I had someone who was having difficulty with the other build test the 32-bit version and it is working for him, so if you were having problems before try this build.

I still have no idea what might have caused the issue.

EDIT: x64 still has issues. -_-;
32bit works fine, 64bit doesn't (same error message) on i7.

64bit version kamisar offered to test works fine.

[bob0r]

komisar can you compile a clean x264 1114 git build, 64 bit for x264.nl?

[komisar]

bob0r, test first.

1114 with no patches. (mp4,pthread,gcc434,fprofiled,-mtune=generic)
x264_64.exe (http://komisar.gin.by/x264_64.exe)

skystrife, how you can patch gcc? Maybe you compile for intel emt64? You last x64 build not working for me...

kemuri-_9, 4.3.3 version of gcc have the same issue as for 4.3.4...

[burfadel]

Same for me, Skystrife's x64 build doesn't work. I think he compiled it as 64 bit and not x64, there is a difference. 64 bit, although generally refers to x64, also refers to IA64, which would explain the message! (completely incompatible). Many people don't realise that Server 2008/Vista comes in two different 64 bit versions! IA64 is only really for servers, not sure if Intel are even making IA64 cpu's any more.

[squid_80]

Vista was never released for Itanium. I think HP are the only company still making IA64 based machines.

[burfadel]

Yeah sorry only Server 2008 released with IA64. Either way, it looks as though thats what he COULD be compiling it for?... (or it could be just a bug in the compiler).

http://support.microsoft.com/kb/966319/

Thats a random update I chose that shows the IA64 and Vista x64 versions of the Windows Kernel :) (and its the latest kernel available that I know of for Vista).

[squid_80]

Regardless, Skystrife's build is definitely not mistakenly compiled for IA64.

[burfadel]

Ah ok :) the file size kind of gives that away too, IA64 seems to have significantly lower coding efficiency? ...??

[kemuri-_9]

kemuri-_9, 4.3.3 version of gcc have the same issue as for 4.3.4...

what issue?

[komisar]

kemuri-_9,
1-st: proper configure gcc for use crtfm (read this post (http://forum.doom9.org/showthread.php?p=1251846#post1251846));
2-nd: proper configure gcc for libgcov (to use profiling) (read this post (http://forum.doom9.org/showthread.php?p=1252042#post1252042));
3-rd: for platform-dependant-build use -march and -mtune (libgcc.a/libssp.a/libstdc++.a/etc use this flags) (e.g. for my "generic"-builds i use "-march=pentium2 -mtune=generic" for i686-pc-mingw32 and "-mtune=generic" for x86_64-pc-mingw32).

[kemuri-_9]

kemuri-_9,
1-st: proper configure gcc for use crtfm (read this post (http://forum.doom9.org/showthread.php?p=1251846#post1251846));
2-nd: proper configure gcc for libgcov (to use profiling) (read this post (http://forum.doom9.org/showthread.php?p=1252042#post1252042));
3-rd: for platform-dependant-build use -march and -mtune (libgcc.a/libssp.a/libstdc++.a/etc use this flags) (e.g. for my "generic"-builds i use "-march=pentium2 -mtune=generic" for i686-pc-mingw32 and "-mtune=generic" for x86_64-pc-mingw32).

1 - was the -ffast-math issue, correct? i fix that by manually compiling it.
2 - i've always been doing that.
3 - i don't bother.

[komisar]

kemuri-_9, then you should not be a problem with compiling.

[Rodger]

Please REMOVE the 1114er Release from the "Stable" server.
IT´s NOT! See here.
Difference is really ONLY between the wto builds!!!

http://www.bilder-space.de/thumb/23.02pscBD1HMYIsK2Uo.jpg (http://www.bilder-space.de/show.php?file=23.02pscBD1HMYIsK2Uo.jpg)

Oooppsy :)
The tags are wrong :rolleyes:
Build 1114 is on top
Build 1113 is below (DAMN!)

[DarkZell666]

Please REMOVE the 1114er Release from the "Stable" server.
IT´s NOT! See here.
Difference is really ONLY between the wto builds!!!

http://www.bilder-space.de/thumb/23.02pscBD1HMYIsK2Uo.jpg (http://www.bilder-space.de/show.php?file=23.02pscBD1HMYIsK2Uo.jpg)

Oooppsy :)
The tags are wrong :rolleyes:
Build 1114 is on top
Build 1113 is below (DAMN!)

Do you have more complete error logs ? Btw what software is it you're using ?

[kemuri-_9]

Do you have more complete error logs ? Btw what software is it you're using ?

this is probably referring to the fact that skystrife's r1114 x64 build is known to be broken.

Sharktooth needs to revert megui to r1113 or use someone else's build.

[Rodger]

this is probably referring to the fact that skystrife's r1114 x64 build is known to be broken.

Sharktooth needs to revert megui to r1113 or use someone else's build.
Hmmh? I´m using the usual Megui (32Bit) 0.3.1.1016.
Why should I get any 64bit Build from the stable servers?

===============================================================
@DarkZell....not really. I tried two times with the same results and immediately switched back to Build 1113 which works fine for me.

[kemuri-_9]

Hmmh? I´m using the usual Megui (32Bit) 0.3.1.1016.
Why should I get any 64bit Build from the stable servers?

If you're on an x64 Windows OS (XP, Vista, and 7 all have available x64 versions),
then you'll see a performance increase by getting the x64 build of x264.

i'm not sure how megui is handling this (i don't use it),
but i imagine that you have the x64 build,
as there haven't been any reports of skystrife's r1114 x86 build failing.

the problematic x64 build is exhibiting problems of immediately crashing upon trying to start up on some systems (majority of the reports are coming in from AMD CPU systems).

[Rodger]

How is the x64 Build to identify?
Well it´s right so far, I´m on Vista 64bit.
But It´s a E8400 @3560Mhz.

But since I didn´t do anything but update it still should be the plan to remove the dead build from the servers before too many users are affected.

I should really post in the megui thread a warning.

[DarkZell666]

Ah right, I haven't used MeGUI for a while, I was just wondering where that screenshot was coming from =)

r1114 isn't broken per se from what I understand, it's only some x64 miscompilation issues with GCC, and those aren't even specific to r1114. The x64 code itself actually works :p

@Rodger: As it turns out, your post would have been more appropriate in the MeGUI thread :)
(Edit: was too long to write my post :p)

[burfadel]

On Intel's it says its the wrong machine type, as if you're running a 16 bit windows app under x64, which is why I thought it might have been compiled for IA64 instead of x64 (not sure even if you could compile it for IA64). Either way, isn't there an even more beta GCC 4.4.0? The MPC Homecinema versions on www.xvidvideo.ru and discusses on here in other threads has its x64 version compiled with GCC 4.4.0. This may be a viable (and potentially faster) alternative. The x86 versions are still compiled with 4.3.2, so maybe there's a reason for that?

[kemuri-_9]

On Intel's it says its the wrong machine type, as if you're running a 16 bit windows app under x64, which is why I thought it might have been compiled for IA64 instead of x64 (not sure even if you could compile it for IA64). Either way, isn't there an even more beta GCC 4.4.0? The MPC Homecinema versions on www.xvidvideo.ru and discusses on here in other threads has its x64 version compiled with GCC 4.4.0. This may be a viable (and potentially faster) alternative. The x86 versions are still compiled with 4.3.2, so maybe there's a reason for that?

4.4.0 is more beta and more broken than 4.3.4.

[burfadel]

Well that makes sense! but for some reason it seems to work with MPC? (I haven't tried it and its coming up 5am here so I'm not going to!) but the way I look at it, if you want to maximise performance potential and use a beta that helps you achieve this, despite 4.4.0 being more developmental than 4.3.4, it may be beneficial to use simply because there's the potential that any bugs in it don't directly affect it unlike those in 4.3.4 :)

[kemuri-_9]

we already have tried 4.4.0 for x264, and it failed at doing so correctly at that point in time.

[skystrife]

x264.1114M.03.x64.exe (http://skystrife.com/x264/x264.1114M.03.x64.exe) should work. Ultimately it was unrelated to gcc and my perl script is at fault... though I don't see how.

Weird. Thanks to everyone who noticed this.

[lexor]

x264.1114M.03.x64.exe (http://skystrife.com/x264/x264.1114M.03.x64.exe) should work. Ultimately it was unrelated to gcc and my perl script is at fault... though I don't see how.

Weird. Thanks to everyone who noticed this.

Can confirm working on my i7. :)

[komisar]

skystrife, on amd athlon64 work fine....

[Rodger]

Is there a how to for the x64 Builds?

I guess just replacing a 32bit build with a 64bit build won´t work?!

[LoRd_MuldeR]

I guess just replacing a 32bit build with a 64bit build won´t work?!

You will also need 64-Bit Avisynth -or- pipe the source in from a 32-Bit process.

The latter allows you to use 32-Bit Avisynth, as you are used to it. I made a small tool for that purpose:
http://forum.doom9.org/showthread.php?t=144140

[lexor]

You will also need 64-Bit Avisynth -or- pipe the source in from a 32-Bit process.

The latter allows you to use 32-Bit Avisynth, as you are used to it. I made a small tool for that purpose:
http://forum.doom9.org/showthread.php?t=144140

That tool looks awesome, I'm gonna try it out when I get back home. I wish MeGUI did this kind of piping... but hey, I'm not the one to shy away from juggling tools :)

[LoRd_MuldeR]

That tool looks awesome, I'm gonna try it out when I get back home. I wish MeGUI did this kind of piping...

That shouldn't be too hard to implement in MeGUI.

Anyway, piping the input in from a separate 32-Bit process should only be a temporary workaround until 64-Bit Avisynth becomes more widespread.

Piping has some overhead, at least on the Windows platform...

[lexor]

That shouldn't be too hard to implement in MeGUI.

Anyway, piping the input in from a separate 32-Bit process should only be a temporary workaround until 64-Bit Avisynth becomes more widespread.

Piping has some overhead, at least on the Windows platform...

I thought the problem was not so much Avisynth as it was with the filters (as squid_80 lamented). So I think this method will still be preferred for a long time.

[LoRd_MuldeR]

I thought the problem was not so much Avisynth as it was with the filters (as squid_80 lamented). So I think this method will still be preferred for a long time.

Well, the more people use 64-Bit Avisynth, the more Plugin developers will release 64-Bit Plugins, hopefully...

[Rodger]

HUGE problem for me....a good deinterlacer that would work with avisynth64 (equal to yadif).

[kemuri-_9]

i use avisynth x86 to filter and create a lossless usually in either LAGS or FFVH,
and then open up the lossless with avisynth x64 to pass down to x264 without the need of piping.

my filtering is generally too slow to pass down to x264 directly anyway.

[Rodger]

latest Avisynth64 realease is still the "old one" from squid80?
http://members.optusnet.com.au/squid_80/

[paulvdb]

As far as I know that is still the latest Avisynth64. And the filters there are probably also the only 64 bit filters. At least I'm not aware of any other 64 bit avisynth filters. But then again I haven't really looked for them because squid80's page has all the filters that I normally use.

[TL0]

Did the most recent regression affect the output of first pass stats files, or was it only a minor bug for final pass only?
Does deblocking even matter for first pass stats file?

- Fix regression in r1085
Deblocking was very slightly incorrect with partitions=all.
Bug found by BugMaster.

[Dark Shikari]

Did the most recent regression affect the output of first pass stats files, or was it only a minor bug for final pass only?Final pass only.

[TL0]

Final pass only.

ok, did it cause any possible visual problems with video encoded by versions of x264 with the regression?

My encodes seemed ok from quick scanning but i have not watched them thoroughly.