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.


