Hello everyone.
Our driver is based on a pretty old Microsoft sample driver named TestCap. However, it has been working great for years (since 2006).
But the latest Windows 8.1 has changed something and our driver does not work properly with Metro apps (e.g. Skype for Metro, Camera app). In desktop mode it still works great with most applications.
A few things that I?d like to mention.
- When Windows 8.0 has been released, our driver didn?t work properly until we have registered it under new mandatory category (see below):
File: capstrm.h
//---------------------------------------------------------------------------
// Topology
//---------------------------------------------------------------------------
// Categories define what the device does.
static const GUID Categories =
{
STATIC_KSCATEGORY_VIDEO,
STATIC_KSCATEGORY_CAPTURE,
#ifdef INCLUDE_WIN8_FEATURES
STATIC_KSCATEGORY_VIDEO_CAMERA, // required for Windows 8 metro apps !!!
#endif
};
- After debugging our driver under Windows 8.1, we have found out that:
a. Client application actually see our driver as a device (it appears under Webcams list in e.g. Skype). OK.
b. Client application walks through our resolutions list and choose the appropriate. OK.
c. Client application (or system) does not request data from our driver. Therefore, there is no video data visible in client application.
- It looks like all Metro applications use Media Foundation instead of DirectShow. Thus, we have tried to work with our driver in desktop client application that works through Media Foundation and got the same problem.
So, maybe it?s Media Foundation problem, not the Windows 8.1.
I would appreciate if somebody can give me a clue what exactly has been changed in Windows 8.1 so I could implement another fix in our driver.
I also know that new AvStream-based drivers do not have such problems - they work fine. But it would be easier to somehow troubleshoot existing Testcap-based driver rather then creating new one (avstream).
Thanks a lot,
Anton
xxxxx@gmail.com wrote:
- After debugging our driver under Windows 8.1, we have found out that:
a. Client application actually see our driver as a device (it appears under Webcams list in e.g. Skype). OK.
Skype uses DirectShow, not Media Foundation.
- It looks like all Metro applications use Media Foundation instead of DirectShow. Thus, we have tried to work with our driver in desktop client application that works through Media Foundation and got the same problem. So, maybe it?s Media Foundation problem, not the Windows 8.1.
This is true. Metro capture applications use Media Foundation (which,
in my opinion, is a significant step backwards from DirectShow). The
equivalent of “graphedt” in Media Foundation is “topoedit” (a “graph” in
DirectShow is a “topology” in Media Foundation), so you can do some
debugging using “topoedit”.
Does your camera product a compressed format? It may be you need to
find a DMO for your codec. Does your camera produce an odd aspect ratio
or unusual set of resolutions? The WinRT capture component seems to be
picky.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> Skype uses DirectShow, not Media Foundation.
Are you really sure of it?
IIRC DirectShow has major time lag issues which make this framework a very bad choice for live communication apps (unlike the media players for which DirectShow is targeted).
Also, IIRC Skype once used some proprietary sound/video processing framework called the “GIPS Engine”, which they licensed from some other company (from Norway IIRC), and which is not DirectShow at all.
Probably they can use DS’s cameras and microphones, but the codec/Internet transmission pipeline for Skype is IIRC not DS at all.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim S. Shatskih wrote:
> Skype uses DirectShow, not Media Foundation.
Are you really sure of it?
IIRC DirectShow has major time lag issues which make this framework a very bad choice for live communication apps (unlike the media players for which DirectShow is targeted).
DirectShow does not have time lag issues. You can see that in samples
like AMCap when using a live web camera. If you connect a capture
source to a network sink, there’s essentially no additional overhead.
Packets go directly filter-to-filter.
I had to trace through Skype last year for a funky capture driver
project. It clearly invoked DirectShow components. Now, it’s possible
they just instantiate DirectShow to do the hookup and then run the
plumbing themselves. I couldn’t have detected that.
Probably they can use DS’s cameras and microphones, but the codec/Internet transmission pipeline for Skype is IIRC not DS at all.
That’s likely. DirectShow doesn’t have a native network component.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.