Video for Windows
| Component of Microsoft Windows | |
 Media Player 2.0 in Windows 3.1 | |
| Introduced in | Video for Windows 1.0 (November 1992) |
|---|---|
| Latest version | Video for Windows 95 (August 1995) |
| Replaced by | |
| ActiveMovie | |
Video for Windows, or VfW, refers to Microsoft's initial set of software for playing, editing, and capturing video content. VfW was initially released primarily as a software development kit, for developers of hardware devices involving video to use the VfW SDK and include parts of it with their device, or for software developers to include components of VfW with their software. A runtime version for viewing videos was made available as a free add-on for Windows 3.1, and became a core component of the OS with Windows NT 3.5 and Windows 95 and later. After this, development on Video for Windows did not continue, and it was superseded as ActiveMovie, later known as DirectShow.
Overview[edit | edit source]
With the arrival of high-density storage media such as CD-ROMs on personal computers in the early 1990s, multimedia was becoming a popular field. Microsoft's initial foray was the Multimedia PC standard, which debuted in 1991 alongside Windows 3.0 with Multimedia Extensions 1.0, but in response to Apple's QuickTime software, Microsoft released Video for Windows in 1992.
Video for Windows primarily included three components:
- The Audio Video Interleave (AVI) container
- A set of APIs for compressing and decompressing video
- A suite of sample software for manipulating digital video
Video for Windows was designed to be extensible; originally, it only supported the Microsoft RLE and Video1 codecs, but developers later wrote decompressors for codecs such as Cinepak, Indeo, and MPEG-1, which could be used in any Video for Windows application if the appropriate codec was installed.
Video for Windows also included an updated version of Media Player from Windows 3.0 with Multimedia Extensions 1.0, which was included in the runtime playback version of Video for Windows, and was subsequently also included in Windows NT 3.5 and Windows 95. This was enabled by Media Player using the Media Control Interface (MCI) API to control the playback of different kinds of media. Video for Windows added MCI support for AVI playback, allowing developers to easily embed video into their applications. If they required greater control, they could also call the Video for Windows APIs directly to manipulate video, with all of the Video for Windows APIs made available to developers.
The other software included with Video for Windows was distributed in both source code and executable form, with the intention that developers would tweak it to write their own software, though many developers simply distributed Microsoft's samples verbatim, including
- VidCap: Simple software for capturing digital video
- VidEdit: Simple software for editing digital video
- BitEdit: Basic bitmap image editor
- PalEdit: Palette editor
- WaveEdit: PCM sound editor
Display Technology[edit | edit source]
The trouble with using the Windows platform for video display is that the Windows GDI (which wasn’t significantly changed between version 3.0 and 3.1) isn’t well-suited to that type of application; while drawing the Windows vector graphics primitives to the screen was relatively speedy, drawing entirely new frames (DIBs, in this case) to the screen using the existing StretchDIBits API was slow. As a result, Video for Windows included several faster ways to draw DIBs to the screen.
DISPDIB.DLL was originally developed for Windows 3.0 with Multimedia Extensions 1.0, and was designed to allow applications to accelerate full-screen display of video by disabling the Windows GDI and letting an application write directly to the VGA framebuffer, just like under DOS, taking over the entire screen. This worked because the Windows kernel always had the low 1MB of physical memory mapped, exporting a selector pointing to linear address A0000h.
However, the user-experience wasn't perfect, since many users still wanted to be able to work with video in a window; full-screen was fine for playback, but not sufficient for editing. The solution was another API added in VfW called DrawDib, which allowed drawing decompressed video frames directly into the framebuffer, circumventing GDI.
DVA / VFlatD[edit | edit source]
GDI was bypassed by way of a virtual device driver called DVA.386, which stands for Direct Video Access, and was internally dubbed the "Virtual Flat Framebuffer Device", or VFlatD. Introduced in Video for Windows 1.1, DVA.386 was compatible with many Super VGA adapters, and allowed Video for Windows to get a pointer to a linear framebuffer (stored in DIB format), emulating a linear framebuffer on banked framebuffer display adapters (most SVGA cards at the time only mapped a 64K window of their framebuffer at a time, usually to A0000h, and to write to the whole screen, one had to switch banks).
DVA works using the virtual memory capabilities of the 80386 processor, mapping a region of the entire framebuffer’s size into the virtual address space of the processor. For example, on a graphics card with a 256KB framebuffer, split into 4 64K banks, a 256KB region would be mapped. DVA then installs a page-fault handler; if a part of the first 64K is accessed, it’ll cause a page fault, which then makes DVA switch the display adapter to the first bank, and map the physical address it’s mapped at to the first 64K of the linear framebuffer, marking those pages as present. Any future accesses to that first 64K occur at full speed, but if the user access another 64K region, it’ll cause a page fault, unmap the first 64K of the linear framebuffer, switch banks, and map that to the appropriate region.
DVA was impressive, though it was not without its limitations. For one, it only supported framebuffers up to 1MB in size, which was impressive in 1992, but rapidly becoming outdated after that, being just barely enough for 800x600 at 16bpp. Additionally, it had no support for alternate color spaces or any other accelerated features of video boards. Additionally, DVA was not extensible, meaning that other developers couldn’t add features to it or add support for it on other display adapters; it had built-in bank-switching code for many popular chipsets, but not all.
DVA evolved into VFLATD.386 (later known as VFLATD.VXD) in Windows 95, where display drivers could provide their own bank-switching code and pass it to DVA as a callback to execute. As such, DVA was able to be used for a wider variety of display adapters.
Display Control Interface[edit | edit source]
Microsoft and Intel collaborated to develop another API for Video for Windows 1.1d known as the Display Control Interface, or DCI. DCI was based on the same fundamental premise as DVA; obtaining access to a linear framebuffer, but its feature set was considerably expanded. DCI was designed from the beginning to accelerate digital video playback, incorporating support for color spaces such as YUV and hardware acceleration for video decompression and scaling, stretching, and zooming of multiple offscreen and overlay surfaces.
DCI was implemented through display drivers incorporating a "DCI Provider" (DCISVGA.DRV was one such DCI provider, including support for a few common SVGA adapters, and DVA was reworked to become a DCI provider as well) which would interface with the DCI Manager (DCIMAN.DLL) through the DCISendCommand function, which in turn used the GDI Escape function. Support for basic DCI escapes was built-in to Windows 95 display mini-drivers using the DIB engine.
The minimal set of DCI APIs consisted of
DCIOpenProvider: Returns a device context to the DCI providerDCICloseProvider: Closes the DCI provider handleDCICreatePrimary: Fills in aDCISURFACEINFOstructure with information about the front bufferDCIDestroy: Releases/frees a DCI surfaceDCIBeginAccess: Locks the surface for access, placing a pointer to the framebuffer in theDCISURFACEINFOstructureDCIEndAccess: Unlocks the surface
DrawDib was implemented on DCI by opening the DCI provider, creating the primary surface, and then obtaining a pointer to the linear framebuffer with DCIBeginAccess. After that, ICDecompressEx would be called to transfer the decompressed video frame into the framebuffer.
More advanced DCI adapters support offscreen surfaces through DCICreateOffscreen and even overlay surfaces. To make these visible, call DCIDraw, which uses the destination rectangle set by DCISetDestination to determine the position and size of where the offscreen surface is to be drawn, and the region set by DCISetClipList to determine which parts of the destination rectangle are obscured and which are visible (they can also be combined with the DCISetSrcDestClip function). This is key if the programmer is attempting to draw the offscreen surface onto a window, which may be partially or fully obscured. To obtain the clipping region, call WinWatchOpen, passing in a window handle to obtain a window-watch handle, which can be used to query if the clipping status has changed with WinWatchDidStatusChange, and used to obtain the list of clipping regions with WinWatchGetClipList. A program can also be notified of a change to the clipping region asynchronously by passing a callback procedure to WinWatchNotify. Alternatively, one can obtain the clipping regions directly from a window handle with GetWindowRegionData or from a device context with GetDCRegionData, though that's less efficient as it recomputes the clipping region on every call, while WinWatch keeps it around and only recomputes the region when it changes.
Some DCI providers also support overlay surfaces, which use chroma keying.
Applications were not intended to call into DCI directly. Instead, they were supposed to call a DCI client such as WinG or Video for Windows, which would in turn call into DCI directly, as DCI was not guaranteed to be available, but DCI clients provided fallbacks. As such, the DCI Manager APIs are barely documented and were deprecated after Windows 95.
]
Apple Lawsuit[edit | edit source]
DCI was encumbered by legal action from Apple in December 1994, who claimed that code used in the generic DCI SVGA driver had been developed for them by the San Francisco Canyon Company in an attempt to speed up video performance under QuickTime for Windows, and the same company later contracted with Intel.
Microsoft accused Apple of attempting to use this suit to sway the technological war between Video for Windows and QuickTime, as Apple had offered a "QuickTime Amnesty Program" for any developers to avoid suit by switching to QuickTime. Microsoft disputed Apple's claims, even offering to defend any developers who included Video for Windows in their software from suit by Apple.
Ultimately, Microsoft released Video for Windows 1.1e in March 1995, which removed the offending DCISVGA.DRV, though by this point DCI support in third-party display drivers was already becoming ubiquitous.
32-bit DCI[edit | edit source]
Microsoft did port DCI to 32-bit Windows (with a 32-bit DCI Manager, DCIMAN32.DLL being callable from Win32), with Windows NT 3.5 including full support for DCI at the display-driver level.
Evolution into DirectDraw[edit | edit source]
DCI 2.0 was planned for Windows 95, but it quickly evolved into DirectDraw (which uses many of the same constants, enumerations, structures, error codes, driver escapes, and even identifies itself in some APIs as DCI 2.0). The general structure of DCI mirrors DirectDraw, including creating and accessing surfaces in memory and blitting between them, though DirectDraw uses COM as opposed to the C-based API of DCI. However, there is a direct correspondence between many DCI APIs and DirectDraw APIs
DCIOpenProvider->DirectDrawCreateDCICloseProvider->IDirectDraw::ReleaseDCICreatePrimary->IDirectDraw::CreateSurface(withddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE)DCICreateOffscreen->IDirectDraw::CreateSurfaceDCIDestroy->IDirectDrawSurface::ReleaseDCIBeginAccess->IDirectDrawSurface::LockDCIEndAccess->IDirectDrawSurface::UnlockDCIDraw->IDirectDrawSurface::Blt
When a DirectDraw driver is unavailable on a Windows 9x operating system, it can fall back to use DCI if available via the Hardware Emulation Layer, which can also fall back to the DIB engine as a last resort. Additionally, OPENGL32.DLL’s software renderer on Windows 9x used DCI to draw to the screen, as did the original version of GDI+, because the same redistributable DLL had to be able to work not only on NT systems, but also on the 9x family, where very old drivers without DirectDraw support could be installed, and DCI was a faster option than GDI. On Windows 9x, DirectDraw will also use DISPDIB.DLL to draw fullscreen graphics in any VGA-compatible modes (i.e. 320x200x256 Mode 13h or 320x240x256 Mode X). Rather than being focused primarily on accelerating display of video content, DirectDraw was intended to facilitate graphics performance for games competitive with MS-DOS, enabling direct access to features of the display adapter such as page-flipping and synchronization with vertical retrace.
Starting with Windows NT 4.0, Microsoft began stripping out DCI support from the operating system, removing several DCI-related exports from GDI32.DLL, removing support for DCI from display drivers, and reimplementing the DCI Manager APIs on top of DirectDraw and GDI. The reason for this was simple; NT 4.0's video architecture had been redesigned, moving large parts of GDI and USER (and the new DirectDraw, which started work on NT shortly after NT 4.0's development began) into the kernel-mode module WIN32K.SYS, meaning that the NT 3.x display drivers that implemented DCI directly would be incompatible, so a clean break could be made to supplant DCI. Only the minimal set of DCI APIs are supported, supporting a single surface, which one can lock, write into, and then unlock, using their close mappings to DirectDraw.
Meanwhile, Windows 95/98/Me continued to have full native support for DCI as a peer to DirectDraw, since DCI display drivers were still supported. Vestigial DCI Manager support remains in modern versions of Windows NT despite the absence of the lower-level components. On Windows NT, DISPDIB is implemented on top of DrawDib, since directly accessing the VGA adapter (which isn’t even guaranteed to be present on a Windows NT system) was unsupported, and DrawDib was in turn implemented using CreateDIBSection.