The files in this directory are used to create capture drivers based on the Chips and Technologies PC9001A chipset. These include: Truevision Bravado Creative Labs Video Blaster ========== Modifying this sample driver =================== 1. If you avoid modifying the core message processing files (DRVPROC.C, VMSG.C) and isolate your changes to CTDEV.C, integration with future updates will be easier. 2. Update the VERSION, REVISION, RELEASE fields in SAMPLE.RCV, as appropriate, with each build. This will ensure our installation utilities are able to automatically load the newest version of your driver. 3. Change the VERSIONDESCRIPTION field in BRAVADO.RC to an appropriate name. Also change the module name in the .DEF file. 4. In addition to support for the standard DIB formats, the sample driver demonstrates how to save data in a custom format, in this case the native scaled YUV format found on boards using the PCVIDEO-Phillips encoder chipsets. This capability will be removed from the final shipping driver and is only provided here as a demonstration. ============= Changes since Final Beta ====================== 1. Prevent PCVIDEO from holding the READY line false for 20mS if read of frame buffer is attempted before acquisition is completed. Changed CT_PrivateAcquire(). IMPORTANT! 2. In InStreamISR, changed the logic which determines when a new frame can be captured. This insures that at least two vertical sync pulses are received prior to capturing the next frame. 3. Updated the VERSIONINFO fields in SAMPLE.RCV. 4. Added code and structure fields which simplify the task of combining capture drivers and codecs into a single driver. Search for _CODEC_SUPPORT to note the changes. 5. Added support for Base I/O port selection into the configuration dialog box. On the Bravado, this value can be altered dynamically, but on the Video Blaster, we just report the setting used by PCVIDEO.DLL. The user must use VBSETENV.EXE to set the I/O base for the Video Blaster since PCVIDEO.DLL uses the environment variable set by this program. ============= Changes since Beta1.0c ====================== 1. The VHDR_INQUEUE flag was not being set as frames were added to the queue. To update your driver, search the sample code for "VHDR_INQUEUE" and note the appropriate changes. 2. In response to the DVM_FRAME message (get a single frame), the sample source was not setting dwBytesUsed, dwTimeCaptured, or dwFlags in the VIDEOHDR structure. Note the change to the CaptureFrame function in "cap.c". WORD FAR PASCAL CaptureFrame(LPVIDEOHDR lpVHdr) { // ... // ... // If you provide compressed data, set dwBytesUsed to // the actual size of the compressed image. lpVHdr->dwBytesUsed = biDest.biSizeImage; lpVHdr->dwTimeCaptured = timeGetTime (); lpVHdr->dwFlags |= VHDR_KEYFRAME; return DV_ERR_OK; } 3. The speed of the RGB16 capture has been greatly improved (5x?). This was accomplished by using a look up table with resulting changes in CAP.C, RECT.C, MAPA.ASM, and MAPC.C. Search for the variable "fpYUVtoRGB16" to note the changes. 4. Additional logic has been added to the sample driver to increase robustness. For example, if the channel is closed while streaming capture is being performed, or buffers are left in the queue, the channel now refuses to close. Search for "gfVideoInStarted" and "lpVHdrFirst" to note the changes. 5. An additional error value has been defined "DV_ERR_PROTECT_ONLY" which your driver can return if it only runs in enhanced mode. Vidcap will run in either enhanced or standard modes. Due to problems with EMM386, drivers which access memory via linear mapping of extended memory in standard mode should return this value. Note the changes in INITC.C: DWORD FAR PASCAL InitCheckMem( void ) { int j; LPSTR lpc; if ((GetWinFlags() & WF_ENHANCED) == 0) return DV_ERR_PROTECT_ONLY; // ... // ... return DV_ERR_OK; } 6. The DVM_STREAM_GETPOSITION message was always returning 0. Search for "dwTimeStream" in CAP.C to note corrections. 7. MAX_OUT_CHANNELS is now set to zero in CT.H to reflect the fact that the VIDEO_OUT channel is not used in the sample driver. ============= Changes since Beta1 ========================= 1. Replaced DV_VM_OPEN, DV_VM_CLOSE, DV_VM_DATA, DV_VM_ERROR, with the generic MM_DRVM_OPEN, MM_DRVM_CLOSE, MM_DRVM_DATA, MM_DRVM_ERROR. 2. The parameters to videoStreamGetError and DVM_STREAM_GETERROR have changed. Vidcap will always call videoStreamGetError in the inner capture loop, since some drivers which are non-interrupt driven rely on this "wake-up" call. 3. Added VHDR_KEYFRAME as a flag to the VIDEOHDR.dwFlags field. Removed VHDR_STARTFRAME and VHDR_CONTFRAME flags from the same field. 4. When receiving DVM_ADDBUFFER, the dwBytesUsed field must be set to zero by the driver. 5. A dwError field was added to the VIDEO_OPEN_PARMS. This allows drivers to return an error code if they fail to open. Vidcap displays the corresponding error text in the status bar, giving the user some feedback. Additional error messages are also defined in MSVIDEO.H. 6. Vidcap now allows drop frames to be inserted in the video stream if the driver misses frames. All other tools handle drop frames by just continuing to display the previous frame for the time slot. This allows capture up to 100fps for all drivers, and removes the requirement of defragmenting disks. The "Error: Data rate too high." message no longer appears. Additional logic was added to the sample driver (in CAP.C) to (a) return accurate time information in milliseconds of when the frame was captured, and (b) ensure that a full frame of video has been captured since exiting the last interrupt. 7. The YUV to palettized conversion routine has been improved to allow capture at 15fps. Also, the Luma component has been scaled (actually part of the YUV look-up table creation process) to brighten the image. 8. The configuration dialog box now prints the name of the driver and the version number. 9. Cleaned-up error handling in low memory conditions. 10. The sample driver writes out uncompressed YUV data. This can be used to test installable codecs. ============== Setting up drivers =========================== The Drivers applet in the control panel cannot install more than one driver of type MSVIDEO. Either deinstall an existing driver, or manually edit SYSTEM.INI. If you choose to manually edit SYSTEM.INI, you can select between any available driver at run time. [Drivers] msvideo=targa16.drv msvideo1=testdrv.drv msvideo2=bravado.drv msvideo3=vblaster.drv msvideo4=MYDRVR.DRV Vidcap takes a command line parameter specifying the index of the driver to use: VIDCAP -d0 (uses targa16.drv) VIDCAP -d1 (uses testdrv.drv) VIDCAP -d2 (uses bravado.drv) VIDCAP -d3 (uses vblaster.drv) VIDCAP -d4 (uses MYDRVR.drv) ============== Other DLLs required ======================== Some of the MSVIDEO drivers use a vendor supplied DLL to provide low level device control. The appropriate DLL must be present on the path prior to installing or using the driver. Driver Support DLL -------- -------------------- Targa16.drv none Testcap.drv none Bravado.drv VW.DLL VBlaster.drv PCVIDEO.DLL ====== Vidcap drivers and Installable Compressors =========== A significant enhancement in AVI since the previous release is the ability of all the tools to handle video streams in compressed formats. When writing an AVI file, Vidcap honors the VIDEOHDR.dwBytesUsed field, and writes a RIFF chunk of this size. The FOURCC biCompression field of the BITMAPINFOHEADER returned by the driver in response to a DVM_FORMAT message is written to the AVIStreamHeader.fccHandler field in the file. To display a compressed stream, the installable compressor interface searches for a codec which can support the format specified in the AVIStreamHeader.fccHandler. Depending on the request, the codec either just decompresses the frame, or can take responsibility for rendering also. This allows codecs to be written which send the compressed image to a hardware decompressor if one is present, and perform software conversion to a DIB if hardware is unavailable. Note that the APIs and Messages for Installable Compressors and Vidcap drivers have been designed so that a single driver can perform both capture and codec functions. The VIDEO_OPEN_PARMS.fccType field passed when the driver is opened contains 'vcap' if a capture channel is requested, and contains 'vidc' when a codec is opened.