ffdshow tryouts project: Discussion & Development

[clsid]

If you want to be stubborn it is your choice. Fact is that x264 encoding support was removed from ffdshow for a valid reason. It was buggy and outdated. Plus it was just as much of a 'hack' as x264VFW and also was not officially supported by the x264 devs.

x264VFW is still being maintained and works much better.

If you don't like the minimalistic GUI of the official x264VFW build, then either use its command-line field for configuring options, or use Komisar's modified version which has a more extensive GUI.
http://komisar.gin.by/

[Falcon4]

Not trying to be stubborn... just stuck between a rock and a hard place - between ffdshow and x264vfw. Each one points at the other and calls it broken... well, with ffdshow doing more of the pointing-at-itself thing, it seems.

I think I speak for a lot more than just myself when I say that I don't really care for VFW. I'd MUCH rather use DirectShow itself. I mean, if that even makes any sense... I'd really love to see a DirectShow-based clone of VirtualDub. Anything, anything at all, that would allow me to accomplish my one basic task: capturing video directly to x264. I really don't care how it's done, I just want such a utility to exist!

I mean, are there seriously no alternatives? We have ffdshow-VFW (which is inexplicably being given the axe), and we have x264vfw, and that's it? Do I need to dust off the "C for Dummies" book and write my own? Hell, I can't even wrap my head around Visual C++ 6.0, I barely manage to code for Atmel AVR with AVR libc - and admittedly I do have a pretty good understanding of that code now, I wrote an interrupt-based multiplexed LED display driver for fun the other day and integrated it into an "ice maker turbo" project... but I have no idea how to write a Windows GUI application. I'd really want to develop a DirectShow-based VDub alternative for MP4 formats, that's not just a front-end for command-line apps like mp4box and friends...

[iSunrise]

Sync problem does not happen with H264, right?
I haven't found the code yet that handles the delay caused by frame threading.
H.264 works just fine.

[LigH]

The complaints were mainly related to a) using AVC video streams in the AVI container, and b) using the VfW API specifically.

a) AVI was not made for B-frames (an issue for Indeo 4 already, and all MPEG-1/2/4-in-AVI codecs as well, see Xvid with/without packed bitstreams) – especially not weighted ones, differences between non-IDR and IDR I-frames, multiple reference frames ... as the english idiom visualizes it, it is "pushing a square peg into a round hole". In contrast, the MP4 container has a matching square hole, the MKV container even an adjustable one... ;)

b) The VfW API is limited in several areas. Unfortunately, it is simply the most widely used one. Software supporting DirectShow encoder filters is possibly more sparse than CLI encoders. And Microsoft is already about to deprecate DirectShow, substituting it with the Media Foundation. How long will it take until programmers will accept that API (not only for decoders, but for encoders as well)?

But debating capturing directly into AVC is even more interesting, as it looks like the german idiom of "shooting sparrows with cannons": To make an AVC codec encode in real time, you may have to disable (or at least severly limit) all the features which make it most efficient. Especially long-term predictions and wide-range motion search, multiple referencing, weighted B-frame relations... Of course, x264 may be able to store live input. Just with a limited efficiency and complexity. So limited that it even fits in the AVI container ... uhm, what did I just say?! :o
__

P.S.: Just mentioning it – are there already any plans to expand ffdshow with Media Foundation API features?

[madshi]

And Microsoft is already about to deprecate DirectShow, substituting it with the Media Foundation.
Haha, yeah, sure. They also planned to replace the win32 API with the DotNet framework. You can't force developers to switch if they don't want to, unless you want to break compatability, which Microsoft never does, if they can help it.

[nevcairiel]

Except, Media Foundation is actually nice, its just the usual problem - someone has to actually start using it. I could write a player, and port my splitter and audio decoder - but that still leaves me short a video decoder and a proper renderer (the default EVR in MF is rather bad).

Personally, i would love to ditch DirectShow and use Media Foundation - it just needs more then one person do slowly steer the community in that direction. ;)

However, i don't exactly expect ffdshow to go MF, it just doesn't have any development resources at all anymore.

[madshi]

In what way do you like MF better? From what I've seen pretty much the only thing it does better is copy protection... ;)

[nevcairiel]

I actually ended up writing a small MF player one day, and in the process reading up about the whole pipeline from start to end, and it just feels more "designed" to do what it does, rather then DirectShow which basically just happend to end up as what it is now, without much design or logic behind it.

Anyhow, some key points that stood out for me:
- They got rid of the stupid media types and replaced it with a fully dynamic system, with pre-defined attributes for many of the information that were missing previously (especially decoder->renderer communication)
- Connection-less design, the filters don't have to manage the connection between each other anymore, the Media Session does that for you (and seems to work pretty good)

One of the biggest advantages, which i guess is rather subjective, but still "real" for me:
- A chance to get rid of the sub-par "standards" defined by Gabest filters, and the bugs in them that every other filter seems to actively work around, rather then fix it at its source.

Overall, it just felt alot more like you're actually focusing on developing the task you're trying to solve, and not trying to get your code to work with DirectShow.

PS:
I'm not really talking about end-user visible features, more like how working with the APIs feels from a coders perspective.. :)

[madshi]

Ok, sounds like a minor improvement to me, but you have to re-learn the whole framework, and you can't drop DirectShow support, unless you want to break compatability with 99% of the software out there. So I don't really see the sense of it.

[nevcairiel]

Thats the problem, isn't it. Advancement is impossible, because backwards compat is required.

[madshi]

I think advancement would still be possible, but the advantages of the advancement would have to be big enough to be worth supporting two different code paths.

[nevcairiel]

All the advantages from easier working with MF go down the drain if you still have to maintain DirectShow at the same time, eh.

[madshi]

Yeah. Maybe MS could have tried to hack in an intermediate layer to make every MF filter automatically DirectShow compatible somehow. That would have helped.

[SamuriHL]

Windvd 2010 uses solely media foundation and as a player is pretty darn stable. Ui blows but i've never seen it crash or slow down or any other "weirdness". I'd love to see an end to end open source mf playback solution. As Nev said, it seems cleaner.

[clsid]

Using MF instead of DS will not suddenly makes things more stable. Crashes are purely a code quality issue, not the fault of DS.

I assume that LAV Filters can relatively easily be made compatible with MF. I also assume that there will be a LAV Video decoder in the future. That leaves the need for a good renderer and subtitle support. madVR might one day fill the void of the first. Subtitle support is best implemented directly in the renderer. An external library for subtitles then comes to mind. That could then also be re-used to for example replace the current sub renderer in MPC-HC.

Two reasons for using MF would be (1) to use in a new player, and (2) to extend the current capabilities of WMP/MC.

Question in case 2 is: is it possible to replace or override the existing MS MF codecs? Afaik there is no merit system and the registry keys are protected (which can be worked around, but that is obviously not ideal).

[nevcairiel]

You cannot easily override the MF codecs used by WMP, except removing them from the "preferred codecs" list (the protected keys you're talking about), but isnt that the same with DS?

[clsid]

There are fewer DS filters from MS, so the problem is less obvious in that case. It is mostly WMV and MP3 that are 'locked in'. Things like the preferred MPEG2/AC3 decoder are configurable.

Maybe things will be better in Windows 8. For example support for VC1 in M2TS is non-existent simply because they didn't have enough time to implement it before win7 was finished.

[HeadlessCow]

Two reasons for using MF would be ... (2) to extend the current capabilities of WMP/MC.
.

Media Center (and Media Center Extenders) are exactly the reason I'd love to see more MF support. Divx5 offers an MKV splitter that's able to work (and stream to the Xbox360) but, since that's the only thing it adds, you still end up giving up and just installing Directshow codecs for everything.

Of course, given the lack of any useful MF codecs, who knows what will actually stream properly to the 360... :(

[therobin]

Is anyone here willing to add a hack to ffdshow VFW implementation to accept HDYC FourCC input? HDYC is the FourCC used by Blackmagic Design hardware for HD input to indicate UYVY input using BT.701 color space. Doing this will allow the use of ffdshow's HUFFYUV codec to capture HD video with ease (no need for massive HDDs or RAID with a good CPU). Currently the only hack of huffyuv that allows this is 32bit only and is difficult to install on 64bit systems. And it would be great to have access to all the tools in ffdshow VFW for capturing HD video.

See this thread on VirualDub forum for more details: http://forums.virtualdub.org/index.php?act=ST&f=6&t=16116&hl=hdyc&
The author of the mod states "The huffyuv build does nothing special. All I did was modify GetBitmapType to accept UYVY || HDYC."

[pankov]

dear developers,
I've been struggling for a long time when using FFDShow audio decoder in MPC-HC (you can look at my posts in the MPC-HC thread here http://forum.doom9.org/showthread.php?p=1498882#post1498882 and in a few followup posts) and finally tonight I found which setting is causing the problem.
It's the "addToROT"=dword:00000001 registry value.
Can somebody, please, explain what it does and what's its GUI representation?
Also does anybody have an idea why it can cause MPC-HC behave so strage? Is it a bug in FFDShow or is it in MPC-HC?

[clsid]

There is no setting in the GUI for that. The default value is 0, so I am curious why it was at 1 for you.

[clsid]

Some info about the purpose of the option:
http://msdn.microsoft.com/en-us/library/dd390650(v=vs.85).aspx

[pankov]

There is no setting in the GUI for that. The default value is 0, so I am curious why it was at 1 for you.
I have absolutely no idea, but since I've been using the same settings for several years (imported from .reg files) I guess it's default value could have been different in the past ... or something else could have changed it. In fact I've just looked at my backups and saw that this setting was set to "1" even in my oldest Registry export from 26.02.2005.
I've turned it off now but the question why it causes such behavior in MPC-HC remains. Is this MPC's fault ... or is it a fault at all? Sadly I don't understand that much about DirectShow, but what's the purpose of this setting in ffdshow itself? is it ffdshow that's connecting to remote graphs or it's the other way around?

[clsid]

It is for other apps to connect to a graph in which ffdshow is present. For example the "connect to remote graph" function in GraphEdit. Or apps that make use of the RemoteAPI for controlling ffdshow settings.

[XhmikosR]

@clsid: ffdshow is crashing for me after r3842 (probably r3844 is the rev which the crash started) with this (http://www.mediafire.com/file/4x636dmmrrfgv56/CrowdRun_720p50.x264.CRF23.10bit.mkv) 10bit h264 video using ffmpeg-mt. r3847 still crashes.

BTW, I'm getting the following warnings when compiling ffmpeg-mt which I guess it's cause by #define HAVE_PTHREADS 1 in ffmpeg-mt's config.h.


In file included from libavcodec/pthread.c:33:0:
libavcodec/../../pthreads/pthread.h:108:0: warning: "PTW32_LEVEL" redefined [enabled by default]
libavcodec/../../pthreads/pthread.h:95:0: note: this is the location of the previous definition
In file included from libavcodec/../../pthreads/pthread.h:302:0,
from libavcodec/pthread.c:33:
../pthreads/sched.h:64:0: warning: "PTW32_LEVEL" redefined [enabled by default]
../pthreads/sched.h:51:0: note: this is the location of the previous definition libavcodec/utils.c: In function 'avcodec_open':

As for the ICL12 builds and the crashes I mentioned in my previous (https://forum.doom9.org/showthread.php?p=1492027#post1492027) post, I'm still getting them with ffmpeg and ICL12 builds but it doesn't happen with all the h264 videos. And the problem is that if I cut a sample I cannot reproduce the crash. I'll try to find the smallest available sample which can be used to reproduce the crashes. BTW, it doesn't matter if I use ffmpeg or ffmpeg-mt, it's crashing in both cases.

EDIT: r3848 still crashes with the above 10bit h264 video.

[clsid]

To fix it support needs to be added to ffdshow for handling the newlly added PIX_FMT_YUV420P9 and PIX_FMT_YUV420P10 colorspaces.

[nevcairiel]

swscale supports them as input formats , so you can convert them to any of the supported output formats using that pretty easily (even with dithering for the 10->8 conversion). Of course it would be preferable to output the actual 10bit data, if the renderer supports it, but thats alot more work, as these special 10bit DirectShow formats are not supported by swscale. ;) (and only madVR supports them for rendering, anyhow)

PS:
I don't follow libav development, as i use ffmpeg - so i cannot comment if the swscale support arrived in libav as well.

[clsid]

I have added a workaround to get the old behavior. That fixes the crash until the proper colorspace conversion is added.

swscale is already up-to-date, so it is just a matter of updating ffdshow.

[XhmikosR]

It seems to work like before in r3850, i.e. no crashes with 10bit videos.

Now about the ICL12 builds crash, I though I'd remove any workarounds in "libavcodec\golomb.h". And what do you know? It doesn't crash anymore. I haven't tried any debug builds though.
So clsid, since MSVC2010 and ICL12 work fine for me and you are the only one know who's using ICL10 and MSVC2008, can you confirm that this (http://pastebin.com/1DvjP0Lz) patch doesn't cause any crashes for you?
Test builds here (http://www.mediafire.com/?f36tdla8g54fw) for anyone who had crashes with h264 videos and ICL12.

Also, how about the ffmpeg-mt pthreads warnings I told you in my post above?

[VipZ]

I was about to post a bug that I had a file with h264 that crashed under x64 but was ok under x86, XhmikosR's golomb fix has fixed this now :)

[clsid]

This file posted by VipZ crashes with MSVC2008 x64 build with that change:
http://www.mediafire.com/?krlxvlj8sb67n90

Do you have more files that I should test?

The weird thing is about this whole issue is that the workaround is for compilers that somehow fail to expand the macro properly. It should not have a negative effect on compilers that do process the macro properly, since the manually expanded code should be equivalent.

[VipZ]

Clsid, here is the sample I was going to post about the crash issue, http://www.mediafire.com/?aajakpfoe8utg24

[XhmikosR]

This file posted by VipZ crashes with MSVC2008 x64 build with that change:
http://www.mediafire.com/?krlxvlj8sb67n90

Do you have more files that I should test?

The weird thing is about this whole issue is that the workaround is for compilers that somehow fail to expand the macro properly. It should not have a negative effect on compilers that do process the macro properly, since the manually expanded code should be equivalent.

Well all I know is that with that change the ICL12 crashes are gone for me. MCVS2010 x86 builds work as before, i.e. no crashes, with or without the patch.

But with that sample the ICL12 build indeed crashes, even with that pacth. The MSVC2010 build with my patch doesn't crash. The MSVC2010 build without my patch doesn't crash either. I cannot try the x64 builds since I'm on 32bit Windows. BTW, that sample doesn't play smoothly for me anyway.

Clsid, here is the sample I was going to post about the crash issue, http://www.mediafire.com/?aajakpfoe8utg24

With this sample, the unpatched ICL12 build crashes. The patched ICL12 build doesn't. MSVC2010 isn't affected, it doesn't crash with or without the patch.

[clsid]

x86 builds work fine. It is only the MSVC x64 builds that are having problems.

[SamuriHL]

I just built msvc2010 x86. No problem. I did not do an x64 build.

[VipZ]

As far as I discovered about this issue ICL12 and MSVC2010 x64 behave the same way, while MSVC2010 x86 seems to never have an issue.
I tested a MSVC2008 x64 build (ffdshow_rev3844_20110510_clsid_x64.exe) which crashes as well.

With this test patch it would seem to fix 3 builds, but break 1.

[XhmikosR]

Well, I don't use MSVC2008. Does the MCVS2010 x64 build crash, with or without the patch?

[clsid]

The problem is with the files. I got three test files, MKV/MP4/FLV. Either the FLV crashes and the other two work, or vice versa.

What bothers me is that the code is essentially the same, so I don't understand why the results are different.

[XhmikosR]

If the MSVC2010 builds work I'm fine with it. If not then it's something someone should dig into more.

[VipZ]

Well, I don't use MSVC2008. Does the MCVS2010 x64 build crash, with or without the patch?

Without patch MCVS2010 x64 crashes and with patch its fine.

IMO the patch is good.

[XhmikosR]

Then I'm good. No one is using MSVC2008 except for clsid. So unless he can find a better fix (like using #if _MSC_VER < 1600), I will commit the patch tomorrow.

I still wait for this


BTW, I'm getting the following warnings when compiling ffmpeg-mt which I guess it's cause by #define HAVE_PTHREADS 1 in ffmpeg-mt's config.h.

In file included from libavcodec/pthread.c:33:0:
libavcodec/../../pthreads/pthread.h:108:0: warning: "PTW32_LEVEL" redefined [enabled by default]
libavcodec/../../pthreads/pthread.h:95:0: note: this is the location of the previous definition
In file included from libavcodec/../../pthreads/pthread.h:302:0,
from libavcodec/pthread.c:33:
../pthreads/sched.h:64:0: warning: "PTW32_LEVEL" redefined [enabled by default]
../pthreads/sched.h:51:0: note: this is the location of the previous definition libavcodec/utils.c: In function 'avcodec_open':

[clsid]

Try this patch:
Index: golomb.h
===================================================================
--- golomb.h (revision 3848)
+++ golomb.h (working copy)
@@ -3,25 +3,25 @@
* Copyright (c) 2003 Michael Niedermayer <michaelni@gmx.at>
* Copyright (c) 2004 Alex Beregszaszi
*
- * This file is part of FFmpeg.
+ * This file is part of Libav.
*
- * FFmpeg is free software; you can redistribute it and/or
+ * Libav is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
- * FFmpeg is distributed in the hope that it will be useful,
+ * Libav is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
- * License along with FFmpeg; if not, write to the Free Software
+ * License along with Libav; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/

/**
- * @file libavcodec/golomb.h
+ * @file
* @brief
* exp golomb vlc stuff
* @author Michael Niedermayer <michaelni@gmx.at> and Alex Beregszaszi
@@ -37,9 +37,6 @@
#include <stdint.h>
#include "get_bits.h"
#include "put_bits.h"
-#ifdef HAVE_AV_CONFIG_H
-#include "libavutil/common.h"
-#endif

#define FFMIN(a,b) ((a) > (b) ? (b) : (a))

@@ -63,18 +60,31 @@
unsigned int buf;
int log;

- OPEN_READER(re, gb);
/* ffdshow custom code */
-#if defined(__INTEL_COMPILER) || defined(_MSC_VER)
- #ifdef ALT_BITSTREAM_READER_LE
- re_cache= AV_RL32( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ) >> (re_index&0x07);
- #else
- re_cache= AV_RB32( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ) >> (re_index&0x07);
- #endif
+#if 1 /*&& defined(_MSC_VER) && defined(WIN64)*/
+ unsigned int re_index = (gb)->index;
+ unsigned int re_cache = 0;
+ re_cache= av_bswap32( ((((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[3] << 24) | (((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[2] << 16) | (((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[1] << 8) | ((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[0]) ) >> (re_index&0x07);
+ buf=(uint32_t)re_cache;
+
+ if(buf >= (1<<27)){
+ buf >>= 32 - 9;
+ re_index += ff_golomb_vlc_len[buf];
+ (gb)->index = re_index;
+
+ return ff_ue_golomb_vlc_code[buf];
+ }else{
+ log= 2*av_log2(buf) - 31;
+ buf>>= log;
+ buf--;
+ re_index += 32 - log;
+ (gb)->index = re_index;
+
+ return buf;
+ }
#else
- // ICL and MSVC compilers sometimes mess up this macro
- UPDATE_CACHE(re, gb);
-#endif
+ OPEN_READER(re, gb);
+ UPDATE_CACHE(re, gb);
buf=GET_CACHE(re, gb);

if(buf >= (1<<27)){
@@ -92,6 +102,7 @@

return buf;
}
+#endif
}

/**
@@ -101,23 +112,25 @@
static inline int get_ue_golomb_31(GetBitContext *gb){
unsigned int buf;

+ /* ffdshow custom code */
+#if 1 /*&& defined(_MSC_VER) && defined(WIN64)*/
+ unsigned int re_index = (gb)->index;
+ unsigned int re_cache = 0;
+ re_cache= av_bswap32( ((((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[3] << 24) | (((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[2] << 16) | (((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[1] << 8) | ((const uint8_t*)( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ))[0]) ) >> (re_index&0x07);
+ buf=(uint32_t)re_cache;
+
+ buf >>= 32 - 9;
+ re_index += ff_golomb_vlc_len[buf];
+ (gb)->index = re_index;
+#else
OPEN_READER(re, gb);
- /* ffdshow custom code */
- #if defined(__INTEL_COMPILER) || defined(DEBUG)
- #ifdef ALT_BITSTREAM_READER_LE
- re_cache= AV_RL32( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ) >> (re_index&0x07);
- #else
- re_cache= AV_RB32( ((const uint8_t *)(gb)->buffer)+(re_index>>3) ) >> (re_index&0x07);
- #endif
- #else
- // ICL9.1-Release and MSVC8-DEBUG build can't process this macro properly.
UPDATE_CACHE(re, gb);
- #endif
buf=GET_CACHE(re, gb);

buf >>= 32 - 9;
LAST_SKIP_BITS(re, gb, ff_golomb_vlc_len[buf]);
CLOSE_READER(re, gb);
+#endif

return ff_ue_golomb_vlc_code[buf];
}

[XhmikosR]

I don't see why you have to complicate things and not use the vanilla code from libav. Anyway, I'll try it tomorrow, but I prefer my solution since it's cleaner and it works for the newer compilers.

[clsid]

Yours doesn't work in all cases. I am going to commit a better patch.

The pthread warning should be harmless. See the pthread headers.

[XhmikosR]

Mine works for all the recent compilers. The fact that you want to use an old compiler means nothing.
Do whatever you want, the crash was there for so long, I know my patch works, while yours is just complicating things and doesn't use vanilla code. Your patch is untested except from you with your compiler. ffdshow has enough custom code where no one really knows if it's needed except from you. You can go this way, or try to make things cleaner. If something is present in vanilla libav code then forward the problem to the respective developers.

[clsid]

MSVC2008 is not an old compiler. Besides, the alternate code will only be used for compilers that have an issue. Since it is a compiler issue, the Libav developers can not and will not fix it.

[hoborg]

It is only me? I got graphstudio freezes -black screen (audio still play) if i try to play h.264 using FFDshow DXVA decoder.
Using x86 2010 build 3844

I tryed older build 3775 and there is no such issue.
I will try track down revision where the problem is introduced later.

[adam777]

Hello all,
A sort of bug - the change introduced in rev 3843 causes some codecs that were set to ffmpeg-mt to remain blank in the codecs list, and crashes FFDShow as soon as one is being accessed (see http://i.imgur.com/3MBLK.png).
Should fallback to default libavcodec.
Adam.

[TheRyuu]

Fix libmpeg2 compilation with gcc/g++.
That FORCECPP flag is nice consider it never gets read anywhere...

libmpeg2 should get compiled with gcc though I thought, not g++. So would the proper way to fix this be to #ifdef _cplusplus the extern "C" parts (or does it not really matter)?

Index: src/codecs/libmpeg2/Makefile
===================================================================
--- src/codecs/libmpeg2/Makefile (revision 3851)
+++ src/codecs/libmpeg2/Makefile (working copy)
@@ -34,7 +34,6 @@
### SETTINGS ###

CFLAGS+= -I. -Iinclude
-FORCECPP=1

#CFLAGS+=-fverbose-asm -save-temps

@@ -45,6 +44,7 @@
### INCLUDES ###

include ../../makefile_c.inc
+CC=g++.exe


### TARGETS ###

[VipZ]

I just complied the 3851 x64 build with MCVS2010, no more crashes for me.

I got a question regarding the solution files, is there any reason for all builds to go into same folder instead of something like bin_MCVS2010_x64?