x264 Windows x64 support

[asarian]

Originally Posted by burfadel

Ah ok! For the couple of times it has happened to me, and its not just with the latest versions, I'm not sure how far back it would go (hasn't always done it), its always at the end of the encode! Its not a major issue since the encoded file is still fine, but it would be good if it didn't happen - I'm guessing that it would be a very difficult problem to find, and it may not even be x264 which is causing it. It could be avisynth... Are you using Avisynth v2.5.8 RC4?

I still use AviSynth 2.5.7, as I heard 2.5.8 is so radically different, it hardly even compares to 2.5.7 (okay, I exaggerate a bit, but there's some truth to it).

How could AviSynth be causing it, though, I wonder? I mean, even if it stopped serving frames, why would that cause x264 to hang? (as in: become unpollable to Windows). Still, using v2.5.8 RC4 might be worth the experiment.

[burfadel]

I haven't had any troubles with v2.5.8... except for that one possible problem which doesn't seem to do with avisynth after all! I hadn't mentioned about the 'crash' (not responding dialogue, nothing actually crashes!) because its not even repeatable, if you encode the same thing again the problem isn't there! I wonder if anyone else has found this?

[Audionut]

Guys, please take these OT posts to a different thread.

[asarian]

Originally Posted by Audionut

Guys, please take these OT posts to a different thread.

Trying to determine what causes x264 to become unresponsive in a Windows 64-bit environment is not off-topic for this thread.

[squid_80]

Yes it is. This thread is about x264 compiled specifically for windows x64. Your problem concerns running x86 x264 under a certain 64-bit version of windows. Since it's not a problem that is special to the builds in this thread it's OT.

[burfadel]

It is a little off topic, it was more a side mention as this problem could still apply to the x264 x64 version. As for me it only occurs at the very end of encoding (quite literally the file has been completely written), it could be related to the closing of the threads or something? - I'm not sure exactly what I'm talking about here but those that know what they're doing should know what I mean! If there is an issue with the closing of the threads/programme, it would also apply to the x64 version? It could well be a bug in Vista as well?...

I should also point out that calling it a Windows 64-bit environment is incorrect, as there are two versions of 64 bit Windows (including Vista). There's the x64 version of Vista and the not well known IA64 (Intel Itanium) version of Vista which are incompatible with each other

[techouse]

But x64 is the more used one; haven't seen IA64 in years.

P.S.: Nice to see that there's some *nix competition under construction now

[burfadel]

I didn't even know there was an IA64 version of Vista until I saw separate Vista updates for it on the Microsoft download site . There must be a large enough number of IA64 systems out there for Microsoft to justify releasing an IA64 version of Vista.

Its a shame that a lot of programmes and filters used by people are no longer being developed, so there's almost no hope for x64 versions, such as most avisynth plugins, besweet (and the inability currently to use such things are Nero AAC encoder as part of the x64 chain), Virtualdubmod... and thats assuming Megui/Staxrip and others in x64.

I have heard there are different ways to get around this, one simple method being to stream frames to a memory buffer. This is done by using 32 bit x264 like normal, but with using a possible 'pass frames' method, stream the frames to a memory buffer (as long as its set up correctly) that can be separately accessed using a 64 bit version of x264. The x64 x264 can be accessed in theory by using the command prompt's 'call' command from x264 x86, such as 'call x264x64.cmd', where the .cmd file instructs to load the x64 version of x264. I'm not sure whether that would work or not, but it would be a good medium term workaround if it did and you'd still have a noticeable performance benefit.

[techouse]

I think that using a 64-bit *nix system with mplayer as the decoder is simpler than your method... Even for a *nix newbie.

[LoRd_MuldeR]

Can't we pipe from 32-Bit ffmpeg or 32-Bit MEncoder to a 64-Bit x264 encoder ???

[burfadel]

There is a way to do it. Technically there's no reason a 32 bit process can't call a 64 bit process and vice-versa, its just Microsoft disallows it citing 'security' reasons. There are workarounds for it, at least from what I've heard

[LoRd_MuldeR]

Originally Posted by burfadel

There is a way to do it. Technically there's no reason a 32 bit process can't call a 64 bit process and vice-versa, its just Microsoft disallows it citing 'security' reasons. There are workarounds for it, at least from what I've heard

I know that a 32-Bit Process can call a 64-Bit one for sure.
For example ProcessExplorer itself is a 32-Bit process, but it creates a 64-Bit child process when running on 64-Bit Windows.
The question is: Can STDOUT be redirect from a 32-Bit process to a 64-Bit one? And if so, how to do it?

[squid_80]

Originally Posted by burfadel

There is a way to do it. Technically there's no reason a 32 bit process can't call a 64 bit process and vice-versa, its just Microsoft disallows it citing 'security' reasons. There are workarounds for it, at least from what I've heard

I've never heard of this restriction. I know for a fact it's possible to pipe from 32-bit avs2yuv to 64-bit x264, similar to what Lord_MuldeR describes.

[LoRd_MuldeR]

What did I miss?

[burfadel]

Thats pretty much what the restriction is, you can't call a 64 bit process from 32 bit and vice versa (hence the claim thats its not a valid Win32 application)

[clsid]

You are confusing DLLs with processes I think.

[LoRd_MuldeR]

Originally Posted by burfadel

Thats pretty much what the restriction is, you can't call a 64 bit process from 32 bit and vice versa (hence the claim thats its not a valid Win32 application)

Originally Posted by clsid

You are confusing DLLs with processes I think.

Yes, passing data via STDOUT from a 32-Bit process to a 64-Bit process (or vice versa) should be possible.
That's because in that case we have to two completely separate processes. No 32-Bit and 64-Bit code is mixed in the same process.
I suspect I did not call it properly, because I didn't work with x264 and input from STDOUT so far...

[deets]

great stuff, is a nice 10% faster here as well ill keep an eye on this one

[LoRd_MuldeR]

LOL. Stupid my used wrong syntax to create the pipe and overwrote x264_x64.exe with random data

It does work now, like this:


However I get some continuous horizontal shift in the output file. I suspect the color format is wrong. Any ideas?


[EDIT]

Here is a sample of what I get:
http://www.mediafire.com/file/kcy4n2...x64-avs2yuv.7z

[asarian]

Originally Posted by burfadel

It is a little off topic, it was more a side mention as this problem could still apply to the x264 x64 version.

Precisely. I only referenced my bad experience with 32-bit x264 under Windows 2008 64-bit, with the question added whether this 64-bit version would not have similar problems.

Judging from LoRd_MuldeR's examples above, it seems you cannot just so easily create a 'drop-in' replacement environment for x264-64bit, so I may just stick bit x264 in a 32-bit OS for now.