Well, sure, a lot of the infrastructure is there already; it seems to me that
we'll have to implement several Quartz interfaces / filters and the approriate
DLL for VFW to work with DirectX. I'm not quite sure which one to base it on,
though; there are quite a lot that deal with VFW, multi-media and stream captur-
ing; a lot of abstraction is handled in Quartz (including qcap and amstream),
but for the raw video stuff it seems to me that these are the ones where it's
really at (and consequently, what we'll have to base the stuff in Quartz on)

winmm.dll
msvfw32.dll
msvideo.dll
avicap32.dll

As for the devenum stuff, I've had to modify createdevenum.c to include the
CLSID for VideoInputDeviceCategory and have it create the corresponding registry
entries in CreateSpecialCategories, for which I've extended the stub of avicap32
a bit to actually return a device (a static string, nothing special) - the
corresponding filter either references Quartz's VideoRenderer as the DShow or
the VfwCapture one .. I've been having more luck with VideoRenderer (MSN 6.2
seemed to respond quite well to that), but native devenum seems to go for the
other one. Perhaps they're related in some way (AFAIK there's no implementation
of VfwCapture in wine; there is, however, one of VideoRenderer .. perhaps Vfw-
Capture captures from the stream and VideoRenderer renders it and provides info
about it through IAMStreamConfig (which is a part of VideoRenderer) - anyway,
I'm sure this is all well documented and everything on MSDN, but as I said, I've
never worked with DirectX before I started looking into this (wouldn't have
expected it to be related to it even)

Anyway, it would be nice to make some headway with this, and if you have some
sample code or even a small application to test this out with (one that indeed
uses this DirectX stuff) then I'd be glad to dive back into it :-) Would indeed
be nice to return something useful to Wine.

Jasper

MediaHost (TM) wrote:
> Maybe we can start the same procedure with a simpler application. Any 
> ideas? Of course I would be interested first, what you implemented at 
> devenum. So I'm not a wine developer (specially not the windows part of 
> it) I can give it a try and maybe we can return something useful into 
> wine.....
> 
> Jasper van Veghel wrote:
> 
> >Rob Shearman wrote:
> > 
> >
> >>Mike McCormack wrote:
> >>
> >>   
> >>
> >>>There's currently no support, but you could add it via the Still Image 
> >>>(STI) API.  It's meant for scanners and webcams.  There's probably a 
> >>>way to add VFW (Video For Windows drivers) too.
> >>>
> >>>I have written an IDL file for IStillImage, which I haven't gotten 
> >>>round to submitting as yet.  I've attached it incase you're 
> >>>interested... I think it still needs some fixing up.
> >>>
> >>>Mike
> >>>
> >>>
> >>>MediaHost (TM) wrote:
> >>>
> >>>     
> >>>
> >>>>Question: Is there support for video4linux devices with wine? Is 
> >>>>there some support for webcams? What are the settings (config)? I 
> >>>>couldn't find anything useful on google concerning this issue....
> >>>>       
> >>>>
> >>You're probably much better off implementing a DirectShow -> V4L filter, 
> >>especially if you want to capture movies or sound.
> >>
> >>Rob
> >>
> >>   
> >>
> >
> >I've recently been looking into VFW with Wine, and though I certainly am no
> >expert at the Windows API concerning this (first time I really looked into 
> >DX),
> >nor Wine for that matter, I was able to get a bit further from where I 
> >started,
> >so allow me to share my experiences with you.
> >
> >As an application to test this stuff with I went for MSN 6.2, though 
> >certainly
> >not the best application for this, it seemed neat to finally have Webcam 
> >support
> >on MSN - I eventually got some of it working with a load of native DLLs, 
> >some
> >hacking on the SSL stuff (I ended up simply setting useSSL = false, the 
> >applica-
> >tion was sending plain-text over an SSL socket, which wasn't working; this 
> >fixed
> >things, or at least for this application ;-)) and adding some undocumented 
> >flag
> >to InternetSetOption (optionId = 87) - anyway, it seems that MSN is using 
> >some-
> >thing along the lines of the following webcam class I found using Google -
> >indeed, using a DirectShow filter:
> >
> >http://www.jolash.com/projects/other_projects/webcam/WebCam.h
> >
> >For things to start working under Wine I used the following native DLLs, 
> >which
> >I also registered with regsvr32 (for CLSIDs etc.)
> >
> >COMCTL32.DLL
> >urlmon.dll
> >CRYPT32.DLL MSOSS.DLL
> >oleaut32.dll ole32.dll rpcrt4.dll
> >MSVCRT.DLL
> >shlwapi.dll shdocvw.dll
> >MLANG.DLL
> >qcap.dll amstream.dll
> >
> >Though I'm not sure if amstream is needed. Don't know what qcap does as I 
> >only
> >managed to get to a point where something in qcap was called which was then
> >being forwarded to Quartz (IAMStreamConfig, for which I added a bunch of 
> >stubs
> >and semi-stubs (filled in some bogus information for 
> >VIDEO_STREAM_CONFIG_CAPS,
> >VIDEOINFOHEADER and AM_MEDIA_TYPE)
> >
> >It turned out that, at least MSN, and this webcam class too, uses devenum 
> >to
> >find the video input devices (CLSID_VideoInputDeviceCategory), for which 
> >I've
> >added the proper code to CreateSpecialCategories and hence 
> >CreateClassEnumerator
> >(it also seems that the windows DLL of devenum always recreates the dynamic
> >registery entries whereas Wine only seems to add them once and then never 
> >again,
> >that is, once they're in the registry they stay there (hence if a new 
> >audio card
> >gets added to the system ..)) The Windows DLL seemed to be using avicap32 
> >to
> >collect information on the available video input devices, so I've simply 
> >had
> >capGetDriverDescription return some string with a fictional video driver 
> >(this
> >also makes it possible to use a native devenum.dll) Next up is Quartz, 
> >which
> >seemed to want IAMStreamConfig (collecting information on the video stream 
> >(res,
> >depth, sps, ..) for starters, but I never got around to implementing 
> >enough of
> >that for the program to accept it and move on, so that's where I got 
> >stuck. It
> >may also have had something to do with MSN wanting an IKsPin which isn't 
> >imple-
> >mented (which is why native quartz may have failed, when trying to 
> >approach the
> >kernel in some way) Here's a small scenario of what I observed working 
> >with both
> >native and hacked up DLLs ;-)
> >
> >DEVENUM - Read all VideoInputDeviceRenderer's (from CLSID)
> >DEVENUM - BindToObject() --> VfwCapture
> >QCAP    - BindToClass --> Quartz(VideoRenderer)
> >QUARTZ  - VideoRenderer_create
> >QUARTZ  - [FAIL] InputPin_QueryInterface (IKsPin)
> >QUARTS  - VideoRenderer_QueryInterface (IAMStreamConfig)
> >
> >Anyway, the 'patches' I wrote are probably not worth much as the whole 
> >under-
> >taking was more of a little endeavor trying to see how far I go (MSN 
> >actually
> >managed to sign in, by the way, but kept crashing a few seconds after that 
> >(the
> >webcam stuff can be accessed without signing in though, there's a preview 
> >option
> >in one of the menus), but perhaps this brief explanation of my steps will 
> >prove
> >useful for someone wanting to implement this aspect of VFW :-) Perhaps 
> >someone
> >could build a control from the class I mentioned earlier which can then be 
> >used
> >for testing (through the webpage that refers to it says it's missing some 
> >code;
> >but at least it's a starting point)
> >
> >Jasper
> > 
> >
> 
> -- 
> Regards
> 
> Signer:      Eddy Nigg
> Company: StartCom Linux at www.startcom.org <http://www.startcom.org/>
>                MediaHost^(TM) at www.mediahost.org 
> <http://www.mediahost.org/>
> Skype:      startcom <callto://startcom/>
> Phone:      +1.213.341.0390
>