Programming Video for Windows by E. J. Bantz

Jump to a Section

Step 1 - Creating the Window
Step 2 - Connecting the Window
Passing Strings to SendMessage
Passing Structures to SendMessage
Processing Images from the Video Stream

Step 1 - Creating the Window
The video capturing processes starts with the capCreateCaptureWindowA function. When calling this function, a handle to a new window will be returned. The handle is a 32-bit number that is used to reference an object (in this case, a window). This handle is the foundation for the rest of your program, and should be kept it in a safe place.

You can customize the look and feel of this new window by changing the Style parameters. In this example, the window will be a Child and Visible upon creation.

lwndC = capCreateCaptureWindowA("My Capture Window", WS_CHILD Or WS_VISIBLE, 0, 0, 160, 120, Me.hwnd, 0)

All future commands are issued by sending a Windows Message to that new window. A Windows Message is sent with the SendMessage function that is built into the Win32 API. You pass this function the Handle of the window you would like to send a command to, the 32-bit message you are sending, a 16-bit parameter, and finally a 32-bit parameter. The 32-bit messages are replaced with an easy to understand constant. I've defined all of the messages that are used for Capturing Video inside VBAVICAP.BAS.

Step 2 - Connecting the Window
Once the Capture Window is created, you can connect the window to the video driver. The video driver is installed with your video camera. The connection is made with the WM_CAP_DRIVER_CONNECT message. This will "bind" the window to first Video driver it finds (index 0). Keep in mind that could send this message to any window, but only this special window created with the capCreateCaptureWindow will understand what you are talking about.

SendMessage lwnd, WM_CAP_DRIVER_CONNECT, 0, 0

Aside from defining all the possible message constants, VBAVICAP.BAS provides functions to make sending windows messages a bit easier. Making the following call is exactly the same as above:

capDriverConnect lwnd, 0

The functions are use used instead of SendMessage to avoid confusing the order in which the parameters are passed. You should always use the functions provided instead of SendMessage.

Passing Strings to SendMessage
The SendMessage API is always passed four things: a handle to a window (hwnd), some message to send to that window (wMsg), a short parameter (wParam), and a long parameter (lParam). The w in wParam stands for "WORD" and the l in lParam stands for "LONG". WORD and LONG are C data types. A WORD is 16bit number, and a LONG is a 32bit number. In VB, these are called INTEGER and LONG. The declaration looks like this:

Declare Function SendMessage Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Integer, ByVal lParam As Long) As Long

In order to pass a string to this function, you need to redefine lParam to be a String instead of a Long. Now, one might think that sending the wrong type of information to a DLL would cause big problems, and that's right, it normally would. Actually, we are sending the function exactly what it wants. You see, in Visual Basic, when you pass a STRING by Value to an external function, it will actually send a pointer to the STRING instead. A pointer is a 32bit number, which is a LONG, which is back to what it expected. So we did pass the right type of data after all. One more thing, we can't just change the declaration of SendMessage because some calls NEED lParam to be a LONG. So, you can just create a new declaration and call it something slightly different. Here is my new declaration:

Declare Function SendMessageS Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Integer, ByVal lParam As String) As Long

Passing Structures to SendMessage
Structures (User Defined Types) are not directly passed to the functions either. Passing a structure is a bit easier that passing a string though. This time, instead of letting Visual Basic pass the pointer for you, use just to it by hand. VARPTR() is a built in function that will return the location in memory (a Pointer) where the variable you pass it is being stored. In our case, the variable will be a User Defined Type. Again, a Pointer is a 32bit number, or LONG, which is what we can pass as lParam.

Here is a quick example of how to retrieve the capture parameters.

capCaptureGetSetup lwndC, VarPtr(CAP_PARAMS), Len(CAP_PARAMS)

Processing Images from the Video Stream
The most common question I have been receiving is, "How do I get at the video capture data during streaming?" The answer is in the call back functions. Use
capSetCallbackonFrame to process frames during preview, and capSetCallbackOnVideoStream to process frames during capture. Here is an example:

capSetCallbackOnFrame lwndC, AddressOf MyFrameCallback

MyFrameCallback is a function that you create for your application. It should be located in a module, not a form. This is the function that will be called every time a new frame has been received from the video driver. It gets passed a handle the a VIDEOHDR which should be declared as the following:


lpData As Long '// address of video buffer
As Long '// size, in bytes, of the Data buffer
As Long '// see below
As Long '// see below
As Long '// user-specific data
As Long '// see below
As Long '// reserved; do not use

End Type

lpData is the actual data from the device. You'll have have to manipulate the VIDEOHDR structure to get to it. Here is some sample code to copy the structure from memory in a real Visual Basic User Defined Type.

Function MyFrameCallback(ByVal lwnd As Long, ByVal lpVHdr As Long) As Long

Debug.Print "FrameCallBack"

Dim VideoHeader As VIDEOHDR
Dim VideoData() As Byte

'//Fill VideoHeader with data at lpVHdr
RtlMoveMemory VarPtr(VideoHeader), lpVHdr, Len(VideoHeader)

'// Make room for data
ReDim VideoData(VideoHeader.dwBytesUsed)

'//Copy data into the array
RtlMoveMemory VarPtr(VideoData(0)), VideoHeader.lpData, VideoHeader.dwBytesUsed

Debug.Print VideoHeader.dwBytesUsed
Debug.Print VideoData

End Function

In this example, RtlMoveMemory should be declared as the following:

Declare Sub RtlMoveMemory Lib "kernel32" (ByVal hpvDest As Long, ByVal hpvSource As Long, ByVal cbCopy As Long)

The End (For now...)

Return Home

  Fund Further Development
If you would like me to post more examples please send me a small Paypal donation

Last Updated: 07/21/02
E. J. Bantz