Chapter 1. Features of the Indigo2 Video Option for Indigo2 IMPACT

Indigo2 IMPACT workstation video capabilities are provided by the Video Library and Indigo2 Video option board for Indigo2 IMPACT. The board provides video input and output for Indigo2 workstations equipped with IMPACT graphics.

This chapter introduces

For an introduction to video, see Appendix A, "Video Basics."

Video Library Capabilities

The Video Library provides a software interface to the Indigo2 Video board for Indigo2 IMPACT, enabling applications to

  • display live video in a window

  • capture live video to system memory

  • encode graphics to video in real time

  • produce high-quality single-frame video output

The Video Library (VL) is a collection of device-independent and device-dependent C language calls for Silicon Graphics workstations equipped with video options. The VL provides generic video tools, including simple tools for importing and exporting digital data to and from Silicon Graphics systems, as well as to and from third-party video devices that adhere to the Silicon Graphics architectural model for video devices. Video tools are described in the Media Control Panels User's Guide, which you can view using the IRIS® InSight[tm] viewer; similar applications are supplied in source-code form as examples in the 4Dgifts directory (/usr/people/4Dgifts/examples/dmedia/video/vl and /usr/people/4Dgifts/OpenGL).

The VL works with other Silicon Graphics libraries, such as the OpenGL® and IRIS Graphics Library[tm] (GL). The VL does not depend on the X Window System[tm], but you can use X Window System libraries or toolkits to create a windowing interface.

The VL allows programs to get events 60 times per second on a quiescent system; it also enables programs to share resources or to gain exclusive use of resources. It supports input and output of video data to or from locked-down memory at the nominal frame rate. The VL provides an API that enables applications to

  • perform video teleconferencing

  • blend computer graphics with frames from videotape or any video source

  • present video in a window on the workstation screen

  • digitize video data

The software for the Indigo2 Video board for Indigo2 IMPACT includes a graphical user interface that makes it convenient to access VL capabilities. Features of this panel, /usr/sbin/vcp, are referred to in the course of this guide.

VL System Software Architecture

This section describes features of these VL system components and tools:

  • video daemon

  • generic video tools

  • library and header files

Figure 1-1 diagrams the interaction between the VL, the video daemon, the kernel, the hardware, and the X Window System server.

Figure 1-1. VL System Components


The VL communicates with the IRIX kernel for device initialization, vertical retrace, setup, and maintenance of any device-supported direct memory access (DMA).

Besides these components, the VL includes a collection of applications that support device configuration and control setting and retrieval, generic tools that display video on a workstation, and video control panels.

Video Daemon

The video daemon, /usr/etc/videod, which has device-dependent and device-independent portions, handles video device management and status information.

Device Management

Management that the video daemon performs includes:

  • Multiple client access to multiple devices

    The library supports connections from multiple client applications and manages their access to a limited number of video devices.

  • Dispatching events

    As events are handled and noted by devices, the daemon notifies applications that have expressed interest in those events.

  • Handling events

    As events are generated by the various devices, the daemon initiates any action required by an event before it hands the event off to interested applications.

  • Maintaining exclusive use

    Types of data or control usage for video clients in a Video Library application are Done Using, Read-only, Lock, and Shared. These usage levels apply only to write access on controls, not read access. Any application can open and read the control's values at any time.

  • Client cleanup on exit

    When a client exits or is terminated abnormally, its connection to the daemon is broken; the daemon performs any cleanup required of the system. Any exclusive-use modes that have been set are cleared; interested clients are notified that the device is no longer in exclusive use. Controls set by the client might persist, but are not guaranteed to remain after the client closes the connection.

Status Information

Status information for which the video daemon is responsible includes:

  • System status of video devices

    The video devices installed in a system can be queried as to availability and control status.

  • Video positioning (offset) information

  • Control setting and retrieval

    Device-independent and device-dependent controls are set and retrieved through the video daemon.

Generic Video Tools

The generic video tools include:

videopanel (vcp) 

Use this graphical user interface to set controls, such as hue or contrast, on devices. The panel resizes itself dynamically to reflect available video devices.

vlcmd 

Use the Video Library command-line interface to enter Video Library shell-level and other commands.

videoin  

Use the video input window tool to view video in a window.

videoout 

Use the video output tool to output video from a rectangular or full-screen area of the screen on hardware that supports the screen-to-video path.

vlinfo 

Use the video info tool to display information about video devices available through the VL, such as the name of the X server, number of devices on the server, and the types and ID numbers of nodes, sources, and drains on each device.

vintovout 

Use this tool to display video input on the device attached to video output.

vidtomem 

Use this tool to capture a single frame (the current video input) or a specified number of frames, depending on the hardware limits for burst capture, and write the data to disk. Capture size can also be specified. The data, which can be translated or left as raw data, can be used by the memtovid tool.

memtovid 

Use this tool to output frames (images) to video out on hardware that supports the memory-to-video path.

The vlinfo, vidtomem, and memtovid tools are command-line tools. In addition to their reference pages, these tools have explanations in the Media Control Panels User's Guide, which you can view using the IRIS InSight viewer. Similar applications are supplied in source-code form as examples in the 4Dgifts directory (/usr/people/4Dgifts/examples/dmedia/video/vl and /usr/people/4Dgifts/examples/OpenGL).

Library and Header Files

The client library is /usr/lib/libvl.so. The header files for the VL are in /usr/include/dmedia. The header file for the VL, vl.h, contains the main definition of the VL API and controls. The header file for Indigo2 Video is /usr/include/vl/dev_ev1.h (linked to /usr/include/dmedia/vl_ev1.h).

VL Architectural Model of Video Devices

The two central concepts for VL are:

  • path: an abstraction for a way of moving data around

  • node: an endpoint of the path, such as a video source (such as a VTR), video drain (such as the screen), a device (Indigo2 video), or the blender in which video sources are combined for output to a drain

VL routines explained in this chapter enable you to build a fully connected topology of sources and drains.

A path defines the useful connections between video sources and video drains. Figure 1-2 shows a simple path in which a frame from a videotape is displayed in a workstation window.

Figure 1-2. Simple VL Path


Figure 1-3 shows a more complex path with two video sources: a frame from a videotape and a computer-generated image are blended and output to a workstation window. This path is set up in stages.

Figure 1-3. Simple VL Blending


VL Programming Model

The VL recognizes five classes of objects:

  • devices, each including sets of nodes

  • nodes: sources, drains, and internal nodes

  • paths, connecting sources and drains

  • controls, or parameters, that modify how data flows through nodes; for example:

    • video device parameters, such as blanking width, gamma value, horizontal phase, sync source

    • video data capture parameters

    • blending parameters

  • buffers, for sending frame data to and receiving frame data from host memory; the VL buffers are implemented as ring buffers containing a number of blocks; each maintains a pointer, a size, and pointers to the head (oldest) and tail (newest) valid data

Data transfers fall into two categories:

  • transfers involving memory (video to memory, memory to video), which require setting up a ring buffer

  • transfers not involving memory (such as video to screen and graphics to video), which do not require a ring buffer

Syntax elements are as follows:

  • VL types and constants begin with uppercase VL; for example, VLServer

  • VL functions begin with lowercase vl; for example, vlOpenVideo()

For the two categories of data transfer, based on the VL programming model, the process of creating a VL application consists of these steps:

  1. Open a connection to the video daemon (vlOpenVideo()); if necessary, determining which device the application will use (vlGetDevice(), vlGetDeviceList()).

  2. Specify nodes on the data path (vlGetNode()).

  3. Create the path (vlCreatePath()).

  4. (Optional step) Add more connections to a path (vlAddNode()).

  5. Set up the hardware for the path (vlSetupPaths()).

  6. Specify path-related events to be captured (vlSelectEvents()).

  7. Set input and output parameters (controls) for the nodes on the path (vlSetControl()).

  8. For transfers involving memory, create va ring buffer to hold data for memory transfers (vlGetTransferSize(), vlCreateBuffer()).

  9. For transfers involving memory, register the buffer (vlRegisterBuffer()).

  10. Start the data transfer (vlBeginTransfer()).

  11. For transfers involving memory, get the data (vlGetNextValid() or vlGetLatestValid(), vlGetActiveRegion(), vlPutFree()) to manipulate frame data.

  12. Clean up (vlEndTransfer(), vlDeregisterBuffer(), vlDestroyPath(), vlDestroyBuffer(), vlCloseVideo()).

Table 1-1 lists calls explained in this chapter.

Table 1-1. Video Library Calls for Data Transfer

All Transfers

Transfers Involving Memory

Setting Controls

vlOpenVideo()
vlGetDevice()
vlGetDeviceList()
vlGetNode()
vlCreatePath()
vlAddNode()
vlRemoveNode()
vlSetupPaths()
vlSelectEvents()
vlBeginTransfer()
vlEndTransfer()
vlDestroyPath()
vlCloseVideo()

vlGetTransferSize()
vlCreateBuffer()
vlRegisterBuffer()
vlGetNextValid()
vlGetLatestValid()
vlPutValid()
vlGetNextFree()
vlGetActiveRegion()
vlPutFree()
vlGetDMediaInfo()
vlGetImageInfo()
vlDeregisterBuffer()
vlDestroyBuffer()

vlSetControl()
vlGetControl()
vlControlList()
vlGetControlInfo()


Indigo2 Video for Indigo2 IMPACT Formats

The Indigo2 Video board for Indigo2 IMPACT translates video signals into a form usable by the Indigo2 workstation. It also does the reverse, translating graphics from the workstation display into video signals. This section describes the Indigo2 Video board's I/O interface.

The Indigo2 Video board's native video format is YUV 4:2:2. The board also supports 32-bit RGB video data. Data coming from or going to the Indigo2 Video board for Indigo2 IMPACT is always ordered top to bottom. The Indigo2 workstation, on the other hand, commonly stores image data with lines ordered bottom to top. Both the Indigo2 workstation and the Indigo2 Video board for Indigo2 IMPACT store pixels from left to right within lines.

The Indigo2 Video board for Indigo2 IMPACT uses 32-bit RGB format for single frame output, and it is produced by some of the video capture convenience routines. The format of these pixels is shown in Figure 1-4.

Figure 1-4. Format of 32-Bit RGB Pixels


In Figure 1-4, the bits are numbered from right to left, with the least significant (rightmost) bit numbered zero.


Note: The alpha stored in the higher eight bits is not accessible except for memory transfers of RGB data to the Indigo2 Video board for Indigo2 IMPACT (such as in the program memtovid.c). When graphics data is input in real time to the video over a dedicated path, this alpha is not accessible.

You can use the capabilities of the Indigo2 Video board to record video signals in composite or S-Video format. For information on the requirements for recording to and from video, see the Indigo2 Video Owner's Guide. For information on videotape formats, see "Videotape Formats" in Appendix A.