When using the GStreamer SDK 2013.6 (Congo) for Windows 64 bits (Runtime) MSI installer and selecting "C:\Program Files\Gstreamer" as the install Directory, it forces itself into "C:\Program Files (x86\Gstreamer". 

As a work-around, to get it into the appropriate directory for 64-bit applications, you have to manually move the "Gstreamer" folder to "C:\Program Files" and then export the relevant parts of the Windows Registry. This is so you can, next, "Find and Replace" all instances of "Program Files (x86)\\Gstreamer" with "Program Files\\Gstramer" (two \\ necessary for escaping the slash [\], part of syntax for a registry import [.reg file]) and then reimport the registry. 

Also, while you are fixing this bug where the installer chooses the directory against your will, you could also make the DEFAULT be "C:\Program Files". For even better compatibility, to find "Program Files" no matter what drive Windows is installed on, the variable that windows uses is "%ProgramFiles%", whitout quotes, and the 32-bit variable is "%ProgramFiles(x86)%", again without quotes.

A Windows installation using default settings transforms "%ProgramFiles%" into "C:\Program Files". When using Linux-native apps compiled for windows, like Gstreamer, this would really help avoid bugs with path variables since Linux does not like a SPACE ( ) in any path; the Linux-native application would be using %ProgramFiles% (no spaces) and windows would automatically be transforming it into a space. Please start referencing paths using windows-native variables where applicable as follows:
%ProgramFiles% = C:\Program Files
%ProgramFiles(x86)% = C:\Program Files (x86)\
%UserProfile% = C:\users\(username)\

Summing it all up, I changed all instances in the registry to "%ProgramFiles%\Gstreamer\....". 

I'm sure you devs know all of this, except for the bug above; I'm just pointing it out of how it would help compatibility between an OS that uses spaces in paths and the others that don't, just like Linux will allow a dot (.) in its path where windows will not. I know you know that any environmental variable can be referenced by putting its name between %% signs, as I did with the three native-to-windows variables above.

Ty for all and keep up the great work!