Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watcgl.UUCP
Path: utzoo!watmath!watcgl!dmmartindale
From: dmmartindale@watcgl.UUCP (Dave Martindale)
Newsgroups: net.graphics,net.wanted
Subject: Re: Graphics to VCR, Help
Message-ID: <249@watcgl.UUCP>
Date: Sun, 28-Oct-84 16:41:16 EST
Article-I.D.: watcgl.249
Posted: Sun Oct 28 16:41:16 1984
Date-Received: Mon, 29-Oct-84 02:18:13 EST
References: <1051@trwrba.UUCP>, <567@watdcsu.UUCP>
Organization: U of Waterloo, Ontario
Lines: 72

There are at least three different issues involved when trying to
record computer graphics output on VTR's.

The first is matching the format of the frame buffer to the NTSC video
standard, in terms of the number of pixels displayed.  NTSC provides
484 full lines of video, interlaced.  You thus need a frame buffer that
displays about that many lines.  1024x1024 displays just cannot be
encoded directly into NTSC format.  Also, the frame buffer has to be
able to put out the data in an interlaced format: all the even lines in
one field, all the odd ones in the next field.  The number of pixels
horizontally doesn't matter as much, as long as the horizontal sweep
rate is about 15.73KHz.  However, the resolution that will actually be
visible on the screen in the horizontal direction will be between
300-400 pixels in luminance (brightness) with somewhat less colour
resolution.  So displaying a vertical line that is only one pixel wide
will not look very good if it is a different colour from the
background.  These are fundamental (bandwidth) limitations of the NTSC
standard and cannot be bypassed if you are using standard video
equipment.

The next problem is synchronization.  NTSC specifies a horizontal sweep
of 15734 Hz, a vertical sweep of 59.94Hz, a particular number of lines
of vertical blanking, and a particular structure of the pulses during
the vertical interval.  Some frame buffers don't put out video that
looks anything like this standard at all; 1000-line systems usually use
a 32KHz horizontal sweep, for example.  Some frame buffers that are
designed to be displayed on standard TV have the rates "about right"
and may be good enough for the TV to lock onto, but not good enough for
a VTR to handle.  Only a few frame buffers provide real, RS170 (NTSC)
sync in their video signals.   Another way of getting good sync is to
use a standard TV sync generator, and lock your frame buffer to it;
again only a few frame buffers seem to provide external sync
capability.

The last problem is encoded signal quality.  The TV encoders that
generate RF for feeding to a TV set seem to be pretty awful.  Even the
cheap (all-in-one) RGB-to-NTSC encoders are not very good.  But if you
get a broadcast quality NTSC encoder (intended for encoding the output
of a studio colour camera) and your frame buffer puts out RGB signals
compatible with this encoder, you can get quite good results (subject
to the bandwidth limitations mentioned above).

In the computer graphics lab at Waterloo, we have a Leitch sync
generator and a Cox NTSC encoder (both intended for TV studio use).
The frame buffer in use is an Adage/Ikonas RDS3000, which handles
external sync plus has enough flexibility in its video timing to fit
either a 512x484 or 640x484 into the video frame.  We record on an
ordinary Sony U-Matic 3/4 inch recorder, though the video produced is
standard so any sort of NTSC VTR would work.  The quality is
surprisingly good.

However, for this quality of equipment, you'll have to spend $5K+, and
it takes an oscilloscope to set it up properly.  And, of course, the
Ikonas is not included in that price.  Generating good-quality video is
not cheap, at the moment.

If you have a graphics system of some sort that cannot be coerced into
producing NTSC timing of its signal at all, then there are "black
boxes" that can convert video from a variety of formats to NTSC video.
They are basically frame buffers in their own right, which digitize the
incoming signal and store it in memory using the timing of the incoming
signal, simultaneous with the contents of memory being scanned and
turned back into video at NTSC rates.  Cox makes one; other
manufacturers must do so as well.  They are all likely to cost $10K+.

To understand better what is going on in the process of generating video
signals, try borrowing a book on television engineering from your nearby
university library.

	Dave Martindale
	Computer Graphics Lab
	University of Waterloo