I'm forwarding this correspondence to wine-devel, in case it interests other developer / users....
-------- Original Message -------- Subject: Re: video4linux - wine Date: Wed, 5 Jan 2005 22:52:33 +0100 From: Jasper van Veghel vanveghel@home.nl To: MediaHost (TM) webmaster@startcom.org References: 20050105193015.GA14955@Skye.mill1.nb.home.nl 41DC68AF.2060405@startcom.org
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