Out-of-the box "Camera example" and "QML Camera example" don't display any preview and console debug displays "failed to renderstream"

As said in summary, I didn't write any custom code, I just tried to run the shipped in examples.

According to the debug messages, I could figure out that with my setup, it's the directshow plugin in qtmultimedia module which is used as an implementation.

And I found a couple of issues in that code:

• The culprit was the ICaptureGraphBuilder2::RenderStream() call in the DSCameraSession::openStream() method that failed to connect the Capture source to the custom frameGrabber, returning the VFW_E_NOT_CONNECTED error code (which isn't documented as being a return candidate btw, see http://msdn.microsoft.com/en-us/library/aa930715.aspx).
  Acknowledging that my hardware devices are only capable of capturing NV12 and YUV Format, by watching the steps of the DSCameraSession::updateProperties() method, and that the actualFormat.pixelFormat() was set to RGB24, I made the hypothesis that the pSG->SetMediaType() was maybe too hard a constraint which may have the problem occur.
  As the ICaptureGraphBuilder2 is documented to be a helper which handles pretty well automated connections, I just skipped the output media type forcing and let things be.
  It kind of worked, since the RenderStream did not fail, and pixels started to move, showing a weird preview. At least, the sample grabber callback was called.
  I instinctively found my way around to visualize actual frame data by patching the DSCameraSession::captureFrame() method, and building the intermediate QImage with a width divided by 3, but I know this to be a mere hack.
  The result is a greyscale preview, running fine in realtime.
  Having a little experience in image processing, I sense I'm actually trying to force-fit Luminance data into RGB channels and this can't be good. I'm currently working on a proper solution.

• Moreover, I noticed that the "Capture" button in the Camera example was never enabled. The reason was the DSCameraSession::pictureInProgress() always returns true, ever since the beginning of the execution. I consider this to be due to this method implementation asking for m_snapshot emptiness, which is indeed true from the very beginning, this member being initialized empty.
  I just introduced an additional boolean member to store picture-in-progress state, initialized with false, and everything just worked fine, I could immediately take photos by clicking on the now enabled dedicated button.

• At last, I was surprised to find in the code that when enumerating the sensors handled format in DSCameraSession::record() method for finding a match with the Render Surface supported ones, the process comes to fall back with the smaller available resolution.

I've seen other bugs related to directshow plugin in JIRA's base, but none describing exactly my experience. I fear these are environment-specific problems. I would appreciate any suggestions on how to address them in a more elegant way than I did.

I'm joining a patch to be applied to dscamerasession.cpp which gathers my modifications.