This page was archived in 2023 as part of the Mac Hut archive and is no longer updated.

Most of the site pages were last updated around 1999 and some information may be out of date.

Become a patron: Support our efforts by contributing a small amount each month to cover our hosting costs and the time it takes to archive these pages properly. Thank you.


Telecast Blanking and RS-170A

What is "Broadcast Quality"?

There is no agreed-upon definition for "Broadcast Quality". As those who follow the various mailing lists and news groups can attest, trying to establish one is like trying to get everyone to agree which is better: Mac or PC.

What it usually comes down to is that the specifications for "Broadcast Quality" are entirely up to the individual that is broadcasting it. Sometimes, sync signal requirements are used, other times visual quality is used, other times it concerns the sequence of black and bars that precedes the content on the tape. When it comes to trying to submit tapes for broadcast, you will even hear suggestions from seasoned editors like "always submit it after lunch, when the engineer is in a better mood."

Visual Quality

There is no hard and fast rule of an x.xMB/sec. minimum, or even a visually subjective rule about visible compression artifacts. The perennial example of "America's Funniest Home Videos" will demonstrate that if the content is worthwhile, broadcasters will broadcast it, no matter how bad the visual quality is.

Signal Sync Specifications

There is a proposed specification that mainly concerns signal sync, known as RS-170A. This is the closest thing to an objective definition of broadcast quality that is available. Unfortunately, its blanking specifications do not favor square-pixel digital video systems (like Telecast) that run at 640x480, due to simple math:

In order to put 640 square pixels on an NTSC line, a sample frequency of12.2727MHz must be used.

The pixel rate multiplied by the number of pixels determines how wide (in milliseconds) a line is. To get the pixel rate, divide 1 by the sample frequency -- each pixel runs for about 81.4 nanseconds.

 81.4 (nanoseconds per pixel) 
x 640 (pixels of active video)
------
 52.1 (microseconds of active video per line)

 63.55 microseconds (NTSC scan line)
- 52.1 microseconds (640 pixels@12.2727MHz)
------
 11.45 microseconds (horizontal blanking)

...which is outside the specification of the proposed RS170A specification of 10.5. It is for this reason that we cannot claim that Telecast is fully RS-170A-compliant.

Similarly, NTSC specifies about 485 scan lines of active video, but our output is only 480, so the vertical blanking is also 4-6 lines too long (when convolution is on, a line is effectively added at the top and bottom).

This results in an image that is a little smaller in both dimensions that a standard full-screen video signal. This is typically only a problem if signals are being combined in a switcher or something, and even the resulting overlap occurs off of the visible area of a consumer TV screen. But this may cause the tape to get bounced back by an engineer nonetheless.
 

What Do I Do If My Tape Gets Bounced?

The most straightforward solution to the problem is to run it through a DVE, expanding it by about six pixels in each dimension. This, however, may incur extra cost and soften the image somewhat.

As implied above, it is generally up to the subjective judgement of the engineer, and submission to a different engineer or even on a different day may yield differing results.

And one must not overlook the possibility that the engineer may use technical specifications to reject a tape when he or she is too polite to reject it on grounds of the quality or appropriateness of the content. In fact, engineers have been known to make patently fictitious claims such as "All MTV videos have to have been originally shot on film."

All this is not meant to belittle the problem. It is meant merely to clarify the nature of the problem, for all users of square-pixel digital video systems. It is unfortunate that this limitation will necessitate a certain amount of finger-crossing, but I hope that by clarifying the exact nature of the issue that effective workarounds can be developed.

Contents