.TH XVideo 3 "September 9 1987" "X Version 10" .SH NAME XVideo - extension library for X video windows .SH SYNOPSIS .nf #include /* include Xlib.h before XVideo.h */ #define SCOPE extern #include "XVideo.h" .SH DESCRIPTION \fIXVideo\fP is an X extension library providing support for video windowing on the Parallax 1280 videographic display. You can display live, full-motion video from any NTSC source in an X window. Other options include still and scaled windows (using a hardware zoom) and limited graphics overlay on top of video. A \fIVideo Window\fP is defined as a standard X window that allows video to exist within it. On the Parallax 1280, video is encoded in 8-bit DYUV format, and completely bypasses the color lookup tables. Overlay graphics within a video window use a reserved portion of the color table. The current implementation reserves colors 0-0xBF for normal graphics, 0xC0 and the odd values between 0xC1-0xFF for overlay graphics in video windows, and all other color values for internal use. Video windows have restrictions and rules beyond those for normal X windows. Only one live video window may exist at a time; this constraint is enforced by the X server. Other restrictions apply to placement of video windows. It is not possible to fill every pixel within a video window with video information. The Parallax 1280 restricts video to modulus 16 x-coordinates. So video information (inside a video window) will begin at the first modulo-16 x-coordinate, and will end at the last legal x-coordinate before a new modulo-16 boundary (that is, its width will be modulo-16 as well). Partially obscured video windows may make the shape of the video region too complicated for the hardware, especially with live windows. Areas that should contain video but cannot are set to color 0xC0. On the typical color display, this is the same dark blue which X uses as the default value for BlackPixmap. Live Video requires full use of 7 of the Parallax 1280's eight bit planes for the video being digitized. Only one bitplane (zmask = 1) is available for overlay graphics on live video windows. When a bit in this plane is 1, a graphics color is displayed; when it is 0, the underlying video is displayed. The graphics color which is used depends on the underlying video. Color value 0xC1 will be used if the video pixel underlying is very dark; color value 0xFF will be used over very bright video pixels. The color map for these values can be set to either display all the same color, or to contrast against the video. The default is that graphics will be light against dark video and dark against light video. Still Video allows the LSB 6 bits of the display pixels to be used for graphics, as the video is not constantly digitizing into the MSB 7 bits like it would be for live video. Thus over still video you can have 32 independent colors (The LSBit must be 1 to flag that this is a graphics pixel). The zmask must be set to 0x3f and the color values must be between 0xc1 and 0xff and must be odd. Color values 0xc1-0xff are not allocated by X. It is assumed there will be only one video window, and that all 32 of these colors are available to the video window. The standard X call for changing color table entries is used to change these colors. It is not always possible to fill every pixel within a video window with video. For example the 1280 restricts video to modulus 16 X coordinates. Partially obscured video windows may make the shape of the video region too complicated for the hardware. Thus areas that should contain video but can not, are set to color 0xc0. This color is settable by the video window program, but should be set to a dark color if contrasting colors are going to be used for graphics over video. This allows programs following the color rules outlined above to not have to worry about what parts of the Video Window are actually video regions and which aren't. Graphics drawn within a video region should always contain a zmask less than or equal to 0x3f. It is only by seeing this plane mask that the server can distinguish between operations involving video and those that do not. Graphics drawn with a larger mask in a video region will cause the video region to shrink out of the way. This may be a desirable effect, but has limitations. 1) The next XStartVideo will obliterate this graphics, 2) usually a fill type graphics operation should be used first, to guarantee that what was previosly a video region now is entirely not. Graphics drawn within live video must have zmask=1. Other zmasks will freeze the video. Graphics drawn within still video should have zmask of 0x3f or less. Color values passed through the X greater than 0xbf will be flagged by X as illegal. Since the color values are always used in video regions with zmasks of 0x3f or less, the upper two bits of color value is ignored. Thus use color values 1..3f to represent color values c1..ff. .SH DIAGNOSTICS .SH FILES .SH SEE ALSO .SH AUTHOR .nf Bob Goodwin of Parallax mods by Russell Sasnett MIT Project Athena Visual Courseware Group