SMP Support does not work in last build
Hi. The last build I tried (655) broke the threads option, even if you specify a value greater then 1 it will only use one thread. The old build (600) works correctly. Please verify and fix.

Threading bug is fixed in the new version just uploaded. Sorry for the delay.

I'm not so sure it's fixed. It works fine in one pass mode but if I do two passes with Gordian Knot/Virtualdubmod it tells that the number of frames in each pass is different and refuses to continue. The original DTS version didn't have any problem doing two passes. Maybe I'm doing something else wrong? I don't think so because I've tried changing every setting and the only one that makes a difference is the number of threads. The la-*test*-('") version definitely makes better use of two cores than any other version so far -- it's the first one that actually got my CPU usage to stay pegged at 100%. Unfortunately as soon as it loads the second pass all that time saved with faster encoding turns into time wasted because the second pass fails and then you have to start over. With one thread instead of two.

I experience the same threading problem. With single thread the X264 encode proceeds correctly (though slowly) on both passes. With 2 threads, as soon as the second pass starts I get the wrong number of frames error. I've seen something about this on another forum so the problem may not be limited to just the VFW build. I'll post again if I can relocate the thread.

Hello all. I just want to clarify that this is a well-known problem with GKnot and x264 VfW (after rev607). The source of the problem is the many changes that occured after rev606 in the field of the encoding speed. I transfer here the words of snow_xmas from Doom9: I have added r606 into my space. This version has no bugs. And move r658 to "x264vfw_Beta". From r607, the encoding melody has changed, encode some frames at the same time. Instead of encode frame by frame. So from r607, Maybe the last frame has finished to process and some others haven't. But while converting soft would stop to process. And in the 1st pass stats file, some frames do not exist. So it will display "2nd pass has more frames than 1st pass". When developers stop to provide vfw, libx264 code was deserting vfw day after day. Maybe r606 is the last version which can support vfw well. I have to say sorry to everyone. And I like vfw same to you. I will amend the code as far as possible. So we don't have other choice if we want to make two passes with x264 VfW and of course with 2 threads: Only use the rev606. Download from here: http://amd.streamload.com/snow_xmas/x264vfw/ Because I have search and ask a lot here and there, I truly believe that it's very difficult to have further development in x264 VfW. Some people try or tried to do something (like DTS, snow_xmas and others), but it seems that they work alone and not as a team. And this is a hard work for one man... Except that, I am not even sure that it could be possible to achieve something due to the many changes in the x264 development from one side and the native limitations of the VfW framework on the other. Anyway, the truth is that (if you tweak it to the max) the quality of the x264 VfW rev606 is still amazing! That's why I am still using it. If anyone is thinking to switch to the x264 CLI version but he doesn't want to spend much time learning it, I propose (and I am sure DTS will agree) the excellent lmx264gui, which is a CLI frontend identical to the VfW configuration panel. That's all.

All one-pass modes work fine with >1 threads. Just remember to bring it back down to 1 when doing multipass. Also, you might want to try the new vfw with the new autogk... Yes, the older r606 using slices and parallel encoding works fine, but slices can cause all sorts of compatibility problems and does actually reduce the quality of your encodes.