Video capturing under Wine, some overview - wine-devel

12 May 2005


      Prompted by the recent work by Maarten Lankhorst on getting his video
cam to work in Wine, I did some in depth investigations on how Windows
actually does this stuff.
This is a summary of what I found and some thoughts about it. I would
like some comments on how to progress.
Basically applications have two obvious ways to use video capture
services in Windows. One is avicap32.dll which is basically the Video
for Windows way of doing this and the other one is
ActiveMovie/DirectShow, soon to be obsoleted by Microsoft as well, as it
seems.
Avicap32 implements two functions, one is for the enumeration of the VfW
devices registered in the system. For this it does enumerate all entries
in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MediaResources\msvid
eo and for compatibilty reasons with 16bit Windows also in the Drivers32
section in system.ini. I have an untested version of this code already.
The enumeration function does not try to detect any devices other than
what it finds in above mentioned places. I assume that a webcam driver
installation would have to do that. 
The second function in Avicap32.dll creates a (hidden) window which
handles the actual interaction with the video device as well as being an
optional user interface for the video data. The communication with the
video device is always by so called installable drivers, like wineoss,
etc. is used for audio devices. The interface to these installable video
drivers is for the video device specific parts declared in a header file
msviddrv.h which is really part of the DDK. (How would we add that to
the Wine headers?)
In modern Windows systems there is one MS provided installable driver
vfwwdm32.dll, which is basically a translation layer between the
installable interface and modern WDM stream based video drivers.
Devenum uses the avicap enumeration function to find all registered VfW
video sources and provide them to an application. Presumably there are
other possible video source objects which would provide a direct
interface to WDM stream class devices somehow and could be enumerated by
devenum as well.
DirectShow seems to be somwhat complicated. Video sources can be
provided from VfW again, which is provided by the "VfW Capture Filter"
class in qcap.dll. This is basically a DirectShow filter wrapper around
the same installable driver interface as is used in avicap32.dll (and
through above mentioned vfwwdm32.dll driver an application can also
access WDM stream class video capture sources indirectly. How the direct
interface to WDM stream class devices is provide I haven't found out yet
but according to MSDN it should be possible somehow.
For Wine purposes the VfW path seems the most interesting one.
Separating the Video4Linux interface into an installable multimedia
driver such as winev4l would cleanly separate platform specific code
from the rest of the Wine DirectShow and Avicap implementation. Trying
to emulate direct access to WDM based drivers would not be possible
anyhow, as that would seem to require kernel driver support, which is
mostly absent in Wine.
I could probably hack an experimental winev4l driver together based on
the work already done by Maarten Lankhorst, but would first want to make
sure that this is considered the way to go, before investing more time
into this. While the current implementation by Maarten is not as clean
and nice because of the direct V4L dependency in standard Wine DLLs, it
is something which already works somehow and could be integrated into
Wine in quite a short time.
What are the thoughts about this?
Rolf Kalbermatter