(Fwd) Re: (Fwd) RE: NTSC output from iR.

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Wed, 29 Jan 1997 21:17:27 +0000


A response from Paul Spencer, our multimedia guru in residence.

Cheers,
Angus.

---- Forwarded mail from spencer++at++hailwood.asd.sgi.com (Paul Spencer)

Reply-To: spencer++at++hailwood.asd.sgi.com (Paul Spencer)
From: spencer++at++hailwood.asd.sgi.com (Paul Spencer)
Subject: Re: (Fwd) RE: NTSC output from iR.
Date: 29 Jan 1997 20:57:26 GMT

>
> NTSC *isn't* 60Hz - it's 59.96Hz,

Actually 59.94 Hz.

> however, your normal SGI CRT
> *is* exactly 60.00000000Hz.

Well, not really. Nominally, it is 60 Hz; but it certainly isn't
that precise. We drive it off a normal crystal; on recent DG boards
we use a 10 ppm tolerance part. That means the 107.352 MHz dot
clock of 1280x1024_60 can vary by +/- 107 Hz, so you get a range
of 59.99994 to 60.00006 Hz.

The exact frequency will vary from board to board, and vary with
temperature, and vary with line voltage; but it is *not* exactly
60 Hz.

> Hence, the buffer swap signal in the simulation
> switches the double buffers at 60Hz - which is not in sync with the
> NTSC vertical retrace - so you get a buffer swap partway down the screen.

Yes, precisely. This same effect will happen when you have two graphics
heads (either in the same system, or two separate systems); although
since the base frequencies are closer together, the two displays will
drift with respect to each other much more slowly.

> 1) How to get Performer to swap the double buffer in sync with the
> NTSC frame rate.

Genlock/framelock the two systems together! This is exactly the problem
that genlock is for; getting two video displays to match up.

> 2) How to get the NTSC encoder to run at exactly 60Hz. (Admittedly if we
> did this, it wouldn't be perfectly timed to the NTSC standard - but
> a VCR wouldn't care about that).

You can't do this and call it NTSC; and it wouldn't work on some
equipment anyway. Besides, you'd *still* have the same problem
of having two separate crystals running at two very slightly different
frequencies.

There is a second problem that you don't bring up. Suppose that we
had a graphics head slaved to an atomic clock, running at *PRECISELY*
59.94 Hz; and we had the NTSC output slaved to the atomic clock as
well, at *PRECISELY* 59.94 Hz. You would still have a technical
issue; the vertical retrace interval of the two video outputs would
not be aligned. There would be no relative drift of the two; but
the NTSC output could still have a tear in it.

This second problem is also fixed by genlocking/framelocking the two
together; this will assure that the two are running at the same
frequency, and have their vertical intervals aligned.

....paul

--
Paul Spencer                 Silicon Graphics Advanced Systems Division
spencer++at++sgi.com                               Mountain View, California

---End of forwarded mail from spencer++at++hailwood.asd.sgi.com (Paul Spencer) ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:29 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.