Detection of OS

[juGGaKNot]

I need the command or a program ( that works in .cmd ) that tells me if the os is x86 or x64 ( 32/64 bit ) to make a script for automatic selection of x264.

What should i be looking for ?

thnx, cheers.

[LoRd_MuldeR]

If you are on Windows, make a 32-Bit executable and call IsWow64Process() (http://msdn.microsoft.com/en-us/library/ms684139(VS.85).aspx) function. Since that function is missing on older Windows versions, we must load it on runtime via GetProcAddress() (http://msdn.microsoft.com/en-us/library/ms683212(VS.85).aspx).

They even have the example code attached that should compile directly in VisualStudio (just in case you aren't familiar with C/C++).

[LoRd_MuldeR]

I have attached a binary for you:
http://www.mediafire.com/file/vm2czjemiqt/IsWow64.exe

int main(int argc, _TCHAR* argv[])
{
if(IsWow64())
{
printf("Running on WOW64\n");
return 0;
}
else
{
printf("Running on 32-bit Windows\n");
return 1;
}
}

[juGGaKNot]

I have attached a binary for you:
http://www.mediafire.com/file/vm2czjemiqt/IsWow64.exe

int main(int argc, _TCHAR* argv[])
{
if(IsWow64())
{
printf("Running on WOW64\n");
return 0;
}
else
{
printf("Running on 32-bit Windows\n");
return 1;
}
}

thnx

btw i am trying to use your makeinstantplayer to make an exe file with redirect but i cant find any readme

i want it to extract to same folder and open a webpage with 2 pages ( 2 links )

"%mypath%\bin\MakeInstantPlayer.exe" "/NOGUI" "/NOSPLASH" "/EXTRACT=%mypath%" "%mypath%\Final_Movie_X264.mp4"

i have all the files from your app in the bin

[juGGaKNot]

cd > "dir.txt"
set /p mypath=<"dir.txt"
del "%mypath%\dir.txt"
"%mypath%\bin\win.exe" > "%mypath%\win.txt"
set /p window=<"%mypath%\win.txt"
del "%mypath%\win.txt"
SET x264=spam
"%x264%"
pause
if "%window%"=="Running on 64-bit Windows" GOTO A2
SET x264=x264.x86.exe
GOTO END
:A2
SET x264=x264.x64.exe
GOTO END
:END

Works great, i will not add

"if "%window%"=="Running on 32-bit Windows" GOTO A1"

to force x86 all the time unless its 64.

So :

thnx

btw i am trying to use your makeinstantplayer to make an exe file with redirect but i cant find any readme

i want it to extract to same folder and open a webpage with 2 pages ( 2 links )

"%mypath%\bin\MakeInstantPlayer.exe" "/NOGUI" "/NOSPLASH" "/EXTRACT=%mypath%" "%mypath%\Final_Movie_X264.mp4"

i have all the files from your app in the bin

[LoRd_MuldeR]

thnx

btw i am trying to use your makeinstantplayer to make an exe file with redirect but i cant find any readme

i want it to extract to same folder and open a webpage with 2 pages ( 2 links )

"%mypath%\bin\MakeInstantPlayer.exe" "/NOGUI" "/NOSPLASH" "/EXTRACT=%mypath%" "%mypath%\Final_Movie_X264.mp4"

i have all the files from your app in the bin

Maybe the Readme is a bit unclear here, but the command-line arguments do not belong to MakeInstatPlayer.exe, but to the generated InstantPlayer EXE file :D

[juGGaKNot]

Maybe the Readme is a bit unclear here, but the command-line arguments do not belong to MakeInstatPlayer.exe, but to the generated InstantPlayer EXE file :D

So there is no way to make it like i want via cmd ?

[LoRd_MuldeR]

So there is no way to make it like i want via cmd ?

You must pass the required CLI arguments when calling the player EXE, not when calling MakeInstantPlayer itself.

Also note that /EXTRACT cannot be combined with the other arguments for obvious reasons...

[juGGaKNot]

You must pass the required CLI arguments when calling the player EXE, not when calling MakeInstantPlayer itself.

Also note that /EXTRACT cannot be combined with the other arguments for obvious reasons...

Yes my first try was with mplayer.exe

than i saw /NOGUI and i was thinking its for the makeplayer.exe ( as is in the readme for cli usage ... )

thnx

will try

[LoRd_MuldeR]

Yes my first try was with mplayer.exe

than i saw /NOGUI and i was thinking its for the makeplayer.exe ( as is in the readme for cli usage ... )

thnx

The CLI options listed in the Readme file apply to the self-running player EXE generated by MakeInstantPlayer.exe, but not to MakeInstantPlayer.exe itself.

I will edit the Readme file and make this part more clear in order to avoid confusion...

[juGGaKNot]

the mplayer --help does not have any of these setting

so do you have a example ? something like

mplayer.exe -i file.mp4 -o file.exe options ( "/EXTRACT=folder" )

where i is for opening and o for .exe output ... ? :)

or "silent" mode for makeinstantplayer.exe ?

LE : aaa you use MakeNSIS v2.44 for this, that was the problem

k going in deep in the MakeNSIS --help.

LE2 : hmm or UPX 3.0, damn, only have one hour to find it lol

LE3 : its too hard, i give up for today.

The CLI options listed in the Readme file apply to the self-running player EXE generated by MakeInstantPlayer.exe, but not to MakeInstantPlayer.exe itself.

I will edit the Readme file and make this part more clear in order to avoid confusion...

Yes i see, thnx for the exe

cheers.

[LoRd_MuldeR]

the mplayer --help does not have any of these setting

so do you have a example ? something like

mplayer.exe -i file.mp4 -o file.exe options ( "/EXTRACT=folder" )

Of course MPlayer doesn't have these settings, because these are NOT options for MPlayer. It's that easy :sly:

If you use my MakeInstantPlayer tool to convert a video into a self-running EXE, than that EXE file (and only that one!) will support the CLI options described in the MakeInstantPlayer Readme.

They do not apply to MakeInstantPlayer.exe, MPlayer.exe, MakeNSIS.exe, UPX.exe or anything else, except for the self-running EXE :rolleyes:

[J_Darnley]

What about Windows' environment variable PROCESSOR_ARCHITECTURE ? I don't know what it can be but here it is set to x86

[Atak_Snajpera]

Would't be easier to just check if x:\%Windir%\SysWOW64 exists????

[juGGaKNot]

What about Windows' environment variable PROCESSOR_ARCHITECTURE ? I don't know what it can be but here it is set to x86

I'd rather use other things, the other

NUMBER_OF_PROCESSORS

does not work on a vista 32 with quad xeon ( it sais 2 not 4 )

So i will have to learn vbs lol.

Would't be easier to just check if x:\%Windir%\SysWOW64 exists????

Yes but not all people use c for windows so i will have to check no ?

set x264=32
if exists A:\%Windir%\SysWOW64 GOTO X1
if exists B:\%Windir%\SysWOW64 GOTO X1
if exists C:\%Windir%\SysWOW64 GOTO X1
if exists D:\%Windir%\SysWOW64 GOTO X1 .................
:x1
set x264=64
GOTO END
:END

[squid_80]

No, %windir% should include the drive letter at the start.

Also, IsWow64Process() is not suitable to detect if the OS is 64-bit, it only reports if the current process is 64-bit. This is noted on the IsWow64Process MSDN page.

[juGGaKNot]

No, %windir% should include the drive letter at the start.

Also, IsWow64Process() is not suitable to detect if the OS is 64-bit, it only reports if the current process is 64-bit. This is noted on the IsWow64Process MSDN page.

I see, i only tested 32 bit so far

guess i will go with

set x264=32
if exists "%Windir%\SysWOW64" GOTO X1
GOTO END
:x1
set x264=64
GOTO END
:END

start "encode" /b /low /max /wait "%mypath%\bin\%x264%.exe"

But what if it is dual boot and the folder is there but he is running on the 32 bit ?

[dat720]

Yes but if the process is 64bit then the OS must be 64bit granted if the process is running 32bit under a 64bit OS then it would give a false value.

With VB its very easy to get information like this with a WMI call to Win32_Processor

AddressWidth: 32
Caption: x86 Family 6 Model 23 Stepping 7
DataWidth: 32
Description: x86 Family 6 Model 23 Stepping 7

AddressWidth, Caption, DataWidth, and Description are probably the most useful for processor achitecture, as i was testing that with a virtual machine i can only assume AddressWidth and DataWidth would report 64 under a 64bit Windows but i have no 64bit Windows installs here to test with.

Here... a quick Google search turns this up, it may save you asking so many questions.
http://vlaurie.com/computers2/Articles/environment.htm

C:\Documents and Settings\Administrator>echo %windir%
C:\WINDOWS

Edit:
Confirmed under Vista 64 the values for AddressWidth and DataWidth are 64.

Address Width: 64
Data Width: 64
Description: Intel64 Family 6 Model 23 Stepping 7

Note that the caption and description values are not always present so they may be a bad choice to rely on

[dat720]

But what if it is dual boot and the folder is there but he is running on the 32 bit ?

If it is dual boot running in 32bit the folder "%Windir%\SysWOW64" will not exist as the 64bit OS *WILL* be on another partition hence the System drive will be a different letter like D, or if someone was silly enough to dual boot from the same partition it will still not exist as the %windir% variable only contains the Current Windows Directory, a 32bit and 64bit OS cannot reside in the same Directory.

[juGGaKNot]

Yes but if the process is 64bit then the OS must be 64bit granted if the process is running 32bit under a 64bit OS then it would give a false value.

With VB its very easy to get information like this with a WMI call to Win32_Processor

AddressWidth: 32
Caption: x86 Family 6 Model 23 Stepping 7
DataWidth: 32
Description: x86 Family 6 Model 23 Stepping 7

AddressWidth, Caption, DataWidth, and Description are probably the most useful for processor achitecture, as i was testing that with a virtual machine i can only assume AddressWidth and DataWidth would report 64 under a 64bit Windows but i have no 64bit Windows installs here to test with.

Here... a quick Google search turns this up, it may save you asking so many questions.
http://vlaurie.com/computers2/Articles/environment.htm

C:\Documents and Settings\Administrator>echo %windir%
C:\WINDOWS

Edit:
Confirmed under Vista 64 the values for AddressWidth and DataWidth are 64.

Address Width: 64
Data Width: 64
Description: Intel64 Family 6 Model 23 Stepping 7

Note that the caption and description values are not always present so they may be a bad choice to rely on

There are about 2-3 months until the programmer will be able to code it, i'm just testing for bitrate and others now.

until then i will use the exe

thnx, cheers all

[dat720]

VB is easier than you think... give it a go
Theres a ton of references out in Google land, if you can think of it, it's most likely already been done.

Start with a simple VBS script, you can "port" these into Visual Basic without too much effort, and on top of that Microsoft provide a free version of their Visual Studio software called Visual Studio Express Edition.

I started in my current job with zero VB experience and less than 12 months later i now code and maintain a "toolbox" application that is some 2500-3000 lines of code, without attending any courses! all self taught!

Just about anything you need can be adapted from "The Scripting Guy" examples:
http://www.microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx

Being able to create your own programs is a very empowering thing!

[LoRd_MuldeR]

Also, IsWow64Process() is not suitable to detect if the OS is 64-bit, it only reports if the current process is 64-bit. This is noted on the IsWow64Process MSDN page.

No, it doesn't! It reports whether the current process is a 32-Bit process running on 64-Bit Windows, aka WOW64 (Windows-On-Windows 64-bit) :sly:

Hence it is suitable to detect a 64-Bit OS. Also it is much more reliable to use a Win32 API function than relying on some folder or some environment variable!
Folder names may change on future Windows versions. Environment variables may change in future Windows versions too or they may be messed up on the individual computer.
At the same time a Win32 API function is well documented, backward-compatible and they cannot be messed up, except maybe for using "root kit" techniques...

There are the following three cases possible for IsWow64Process(), and only these:

1. There is no function (entry point) named "IsWow64Process" available in kernel32.dll -> We are running on old 32-Bit Windows
2. The return value is FALSE -> Our 32-Bit Process not running on WOW64, hence we are running on new 32-Bit Windows (WindowsXP SP-2 or later)
3. The return value is TRUE -> Our 32-Bit Process is running on WOW64, hence we are running on 64-Bit Windows

(It also would return FALSE for a 64-Bit process running on 64-Bit Windows. But this case can be ignored as I provided a 32-Bit binary only)

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

More info here:
http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx

WOW64 is the x86 emulator that allows 32-bit Windows-based applications to run seamlessly on 64-bit Windows.

A 32-bit application can detect whether it is running under WOW64 by calling the IsWow64Process function.

IsWow64Process Function

Wow64Process [out]
A pointer to a value that is set to TRUE if the process is running under WOW64. If the process is running under 32-bit Windows, the value is set to FALSE. If the process is a 64-bit application running under 64-bit Windows, the value is also set to FALSE.

[juGGaKNot]

VB is easier than you think... give it a go
Theres a ton of references out in Google land, if you can think of it, it's most likely already been done.

Start with a simple VBS script, you can "port" these into Visual Basic without too much effort, and on top of that Microsoft provide a free version of their Visual Studio software called Visual Studio Express Edition.

I started in my current job with zero VB experience and less than 12 months later i now code and maintain a "toolbox" application that is some 2500-3000 lines of code, without attending any courses! all self taught!

Just about anything you need can be adapted from "The Scripting Guy" examples:
http://www.microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx

Being able to create your own programs is a very empowering thing!

k but i have wireless net, i will get the files in 3-4 days.

No, it doesn't! It reports whether the current process is a 32-Bit process running on 64-Bit Windows, aka WOW64 (Windows-On-Windows 64-bit) :sly:

Hence it is suitable to detect a 64-Bit OS. Also it is much more reliable to use a Win32 API function than relying on some folder or some environment variable!
Folder names may change on future Windows versions. Environment variables may change in future Windows versions too or they may be messed up on the individual computer.
At the same time a Win32 API function is well documented, backward-compatible and they cannot be messed up, except maybe for using "root kit" techniques...

There are the following three cases possible for IsWow64Process(), and only these:

1. There is no function (entry point) named "IsWow64Process" available in kernel32.dll -> We are running on old 32-Bit Windows
2. The return value is FALSE -> Our 32-Bit Process not running on WOW64, hence we are running on new 32-Bit Windows (WindowsXP SP-2 or later)
3. The return value is TRUE -> Our 32-Bit Process is running on WOW64, hence we are running on 64-Bit Windows

(It also would return FALSE for a 64-Bit process running on 64-Bit Windows. But this case can be ignored as I provided a 32-Bit binary only)

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

More info here:
http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx

Yes, using it, if any testers have problems i will pm you.

thnx, chers.

[Kurtnoise]

Hence it is suitable to detect a 64-Bit OS.
from Examples paragraph (http://msdn.microsoft.com/en-us/library/ms684139(VS.85).aspx):
Note that this technique is not a reliable way to detect whether the operating system is a 64-bit version of Windows because the Kernel32.dll in current versions of 32-bit Windows also contains this function.
so, using IsWow64Process is not good enough...You have to compare also the size of IntPtr (or something like that.../me dotNet user) from the system.

[LoRd_MuldeR]

from Examples paragraph (http://msdn.microsoft.com/en-us/library/ms684139(VS.85).aspx):

so, using IsWow64Process is not good enough...You have to compare also the size of IntPtr (or something like that.../me dotNet user) from the system.

Don't you guys read what you refer to??? They say that you cannot link to IsWow64Process() statically, because it is missing in old 32-Bit Windows versions. Hence you must check for the existing of that function via GetProcAddress(). That check alone is NOT enough to find out whether you are on 32-Bit or 64-Bit Windows, because newer 32-Bit Windows (WinXP SP2 and later) has that function too. So of course you must not only check for the existence of IsWow64Process(), you must also call it (if available) and check the result! That's all we can learn from the part you quoted! Nothing else!

If we are on a newer 32-Bit Windows, which has IsWow64Process() available, then the results of IsWow64Process() will always be FALSE, which unambiguously indicates that this is 32-Bit Windows! If that function is available and returns TRUE, then this unambiguously indicated we are on 64-Bit Windows. And if the function is missing, we are on 32-Bit Windows (an old version before WinXP SP2) for sure. IsWow64Process() would also return FALSE when called by a 64-Bit process on 64-Bit Windows (as that process is not running inside WOW64), but this case cannot happen with the 32-Bit binary that I provided!

So please read before you post and stop quoting phrases out of their context, giving people the wrong idea...


There are the following three cases possible for IsWow64Process(), and only these:

1. There is no function (entry point) named "IsWow64Process" available in kernel32.dll -> We are running on old 32-Bit Windows
2. The return value is FALSE -> Our 32-Bit Process not running on WOW64, hence we are running on new 32-Bit Windows (WindowsXP SP-2 or later)
3. The return value is TRUE -> Our 32-Bit Process is running on WOW64, hence we are running on 64-Bit Windows

(It also would return FALSE for a 64-Bit process running on 64-Bit Windows. But this case can be ignored as I provided a 32-Bit binary only)

[squid_80]

At the same time a Win32 API function is well documented, backward-compatible and they cannot be messed up, except maybe for using "root kit" techniques...
<snip>
(It also would return FALSE for a 64-Bit process running on 64-Bit Windows. But this case can be ignored as I provided a 32-Bit binary only)

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

More info here:
http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx

Don't you guys read what you refer to???
So please read before you post and stop quoting phrases out of their context, giving people the wrong idea...
How about you read what you refer to more carefully, and suggest using the GetNativeSystemInfo function (which doesn't require any access rights to call, unlike IsWOW64Process) instead of using IsWOW64Process for something which it isn't intended. Then you can use the same source code in a 32-bit or 64-bit executable.

[LoRd_MuldeR]

How about you read what you refer to more carefully, and suggest using the GetNativeSystemInfo function (which doesn't require any access rights to call, unlike IsWOW64Process) instead of using IsWOW64Process for something which it isn't intended. Then you can use the same source code in a 32-bit or 64-bit executable.

Oh come on, you really can't stop :rolleyes:

1. The OP wants to detect 32-Bit vs. 64-Bit Windows. To check for a 64-Bit OS we must unavoidably use a 32-Bit binary, because a 64-Bit executable would fail to launch on 32-Bit OS. Consequently we talk about pure 32-Bit code here! Okay, we could use a 64-Bit binary an assume a 32-Bit OS, if the program crashes. But that's the most ugly solution of them all.

2. I use the handle return by GetCurrentProcess() (http://msdn.microsoft.com/en-us/library/ms683179(VS.85).aspx) to call the IsWow64Process() function. GetCurrentProcess() functions returns a "dummy" handle, that is always available in any process and that has full access rights to the current process (PROCESS_ALL_ACCESS). Hence your argument doesn't hold.

3. As far as I understand, GetNativeSystemInfo() returns the kind of CPU, but not the kind of operating system! We can have a 32-Bit OS running on a x64-capable processor, but then we still cannot run 64-Bit processes. Hence we want to know the type of OS, not the CPU. So unless I'm mistaken, GetNativeSystemInfo() is totally useless here!

[EDIT]

Okay, I checked that again and it seems GetNativeSystemInfo() would work too (using the "wProcessorArchitecture" member). But this doesn't mean that IsWow64Process() doesn't work :D

[LoRd_MuldeR]

Here is an updated version:
http://www.mediafire.com/file/zgktjtqezdu/IsWow64.2009-05-26.zip

Added the error handling code that was missing in the MSDN example and adjusted "targetver.h" ;)

--------------[EDIT]--------------

Here is a MinGW binary. In contrast to the previous MSVC 9.0 binaries, this one will run on Windows 9x too:
http://www.mediafire.com/file/t2jnyykt2fm/IsWow64.2009-05-26.MinGW.zip

[juGGaKNot]

Here is an updated version:
http://www.mediafire.com/file/zgktjtqezdu/IsWow64.2009-05-26.zip

Added the error handling code that was missing in the MSDN example and adjusted "targetver.h" ;)

--------------[EDIT]--------------

Here is a MinGW binary. In contrast to the previous MSVC 9.0 binaries, this one will run on Windows 9x too:
http://www.mediafire.com/file/t2jnyykt2fm/IsWow64.2009-05-26.MinGW.zip

thnx

for now i'm dropping 64 bit support since

So now you know what went wrong. you cannot use 64 bit x264 with 32 bit avisynth directly. Everything in chain MUST be 64 bit. I mean everything. Decoder , filter , splitters and so on.

and i have not finished the profiles yet.

[LoRd_MuldeR]

You can use 64-Bit x264 in combination with 32-Bit Avisynth (Filters, Decoders, etc) easily via avs2yuv :)

Have a look here:
http://forum.doom9.org/showthread.php?t=144140

[juGGaKNot]

You can use 64-Bit x264 in combination with 32-Bit Avisynth (Filters, Decoders, etc) easily via avs2yuv :)

Have a look here:
http://forum.doom9.org/showthread.php?t=144140

I will, for now i'm working on high resolutions, with the old profile r699 i get good quality at 3400, with r1153 i need double bitrate for the same quality

Only resolutions higher than 1024x640 :|

thnx for the app and the suggestions.

cheers.

[LoRd_MuldeR]

I will, for now i'm working on high resolutions, with the old profile r699 i get good quality at 3400, with r1153 i need double bitrate for the same quality

Instead of using such an archaic revision, you should try to tweak the settings. r699 neither had AQ nor Psy RDO. These can still be disabled in current revisions, although that usually is a bad idea...

[juGGaKNot]

Instead of using such an archaic revision, you should try to tweak the settings. r699 neither had AQ nor Psy RDO. These can still be disabled in current revisions, although that usually is a bad idea...

I just did but still ratefactor 25 ( and qp are all over 30 ) at 7000 bitrate 1280x800.

--level 4.0 --vbv-bufsize 24000 --vbv-maxrate 24000 --ref 4 --mixed-refs --bframes 4 --b-adapt 2 --weightb --direct auto --subme 9 --trellis 0 --psy-rd 0.0:0.0 --partitions all --8x8dct --me umh --threads auto --thread-input --merange 24 --fullrange on --aq-strength 0.0 --qcomp 1 --progress --no-psnr --no-ssim

And that old file was main not high ... :|

Writing library : x264 core 57 svn-699C
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x1:0x130 / me=esa / fpel_cmp=sad / subme=6 / me-prepass=0 / brdo=1 / mixed_ref=1 / me_range=16 / chroma_me=0 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=1 / direct=2 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=3400 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30

At 1024 all is k even with autovaq and psyrd
At 1280 needs double bitrate

LE : trellis 0/2 is also the same for my source ( 0 a bit better )

[LoRd_MuldeR]

I just did but still ratefactor 25 ( and qp are all over 30 ) at 7000 bitrate 1280x800.

CRF values of r699 are not comparable to r1153, because CRF was redefined various time since then.

So if you want to hit a specific bitrate, then use 2-Pass instead of CRF! Especially when VBV is involved. And always compare files of same size (not files of same CRF).

And that old file was main not high ... :|

You use high profile settings (--8x8dct) and you wonder why your stream comes out as "high" profile? ^^

[juGGaKNot]

CRF values of r699 are not comparable to r1153, because CRF was redefined various time since then.

So if you want to hit a specific bitrate, then use 2-Pass instead of CRF! Especially when VBV is involved. And always compare files of same size (not files of same CRF).

2 pass, same bitrate, was talking about the finalratefactor and qp

You use high profile settings (--8x8dct) and you wonder why your stream comes out as "high" profile? ^^

I'm not that stupid, just saying the old should suck more since its main and not high but its actually better than my high with or without psy shit and new b-adapt etc etc etc

[LoRd_MuldeR]

I'm not that stupid, just saying the old should suck more since its main and not high but its actually better than my high with or without psy shit and new b-adapt etc etc etc

That would be VERY surprising ;)

But maybe you should provide a sample (unprocessed source) and start a new thread about that in the H.264 forum (http://forum.doom9.org/forumdisplay.php?f=77), because it's not really related to the "OS" thread anymore...

[juGGaKNot]

http://forum.doom9.org/showthread.php?t=146857

knock yourself out, i will also upload a 1280 one in 2-3 days.