Notes on pixel aspect ratios of consoles as it applies to encoding videos.
Table of contents

Definitions

Active Area
The maximum portion of a signal that can actually be used to display dots on a television, whereas the rest of the signal is consumed by operations like resetting the TV's electron guns or generating syncing pulses. Defining a signal's active area requires a number of parameters: number of lines, time spent on each line, number of lines consumed by non-display functions, time for each display line consumed by non-display functions, and finally update frequency. The number of visible lines and (scanline period * update frequency) define the vertical and horizontal resolutions of the active area, respectively. NTSC on a System M television, or PAL on a System B television defines all but frequency for these signals, so generally Rec. 601 is used to define an active area for these signals. For consoles, the active area will use the characteristics of the underlying system the console was designed for (NTSC/PAL), but the console will be using its own update frequency, which affects its horizontal resolution (and PAR).
DAR
Display Aspect Ratio. The width/height ratio of the displayed image on the screen. Note that the DAR of TV sets is 4:3, however the DAR of the output signal can be different - there will just be black letter-/pillar-boxing on the screen where the aspect ratio difference causes blank areas.
Dot
Section of glowing TV phosphors, as produced by the output hardware's smallest discrete output period. Output hardware may produce one dot per cycle, or one dot per many cycles. The shape of the "dot" is more often rectangular than square, and is determined by how fast the TV's electron gun is moving horizontally and how fast the output hardware is changing its signal. Most calculations on this page regarding dots assumes System M-compliant television sets, which spend 52.148[1] microseconds on the active portion of a scanline.
Framebuffer
An array of pixels in a console's memory that represents the image of a game that is to be displayed on the television. This is the image that a console's CPU and GPU construct before being sent to a digital video to analog (DAC) chip that converts the image into a standards-compliant output signal (NTSC/PAL/SECAM) for display on a television. The most important distinctions between the framebuffer and the output signal for the purposes of correcting and encoding video is that the framebuffer is comprised of square pixels whereas the output signal will probably be comprised of non-square dots, and the framebuffer consists only of the "game part" of the resulting image while the full output signal might include blank border area where the console does not supply data.
(Scan)Line
Horizontal line of dots drawn to the TV screen. The height of these lines is generally fixed with respect to the television set's construction (see System M).
PAR
Pixel Aspect Ratio. The width/height ratio of a dot drawn to a screen. This number is also the number of square pixels needed to approximate one of these dots.
Rec. 601 (BT.601)
Also known as BT.601, Rec. 601 defines a standard for converting analog video into digital video. The standard defines a number of capture lines and and a sampling frequency for both NTSC and PAL to get an active area. For NTSC, the active area is 704 samples over 52.666µs, by 480 lines, with a PAR of 10:11. For PAL, the active area is is 702 samples over 52µs and, by 576 lines, with a PAR of 59:54. These values are actually for the clean-aperture portion of the picture that is important for encoding, see PAR for the Course for much more detail. NOTE: A very important facet of Rec. 601 with regards to encoding videos is that Rec. 601 defines a way of capturing analog video for conversion into digital video, it does not define how analog video is displayed or actually looks. It's a one-way process. This distinction is important because a Rec. 601 capture of an SD console's output (via any number of capture devices) will use a certain PAR regardless of the console's actual PAR, and there will be some amount of border around the image since most consoles do not actually output to the full active area, but a Rec. 601 device will still record the entire active area even if there isn't anything there. More about the origin of this standard and details about its values can be read about in Rec. 601 - The origins of the 4:2:2 DTV Standard.
SAR
Source Aspect Ratio: The width/height ratio of the internal or original image before it hits the TV. This is often the size of the hardware's framebuffer but not always.

Recommended Reading

Extra Reading

Output Formatting

Outside of ensuring that PAR is correct, there is no one "correct" way of formatting output video for an SD console, due to the differences between the part of a console's signal that it is actually outputting an image to, and the huge variability of how televisions can present the signal. Whether there is a border around the resultant image at all, and if so, the size of that border, is determined entirely by if you consider the entire active area of a console's signal as important, if you want a 4:3 DAR for your output to match that of a TV, and whether you consider non-integer scaling of lines (vertical resolution) acceptable. For consoles where it makes sense, multiple options for formatting output are presented to account for the prior decisions, except for the 4:3 DAR output frame, which is assumed for all options.

Maximum Fit

This type of scaling simply fits the PAR-corrected output video to one of the 4:3 frame's edges. This is generally just scaling the longer dimension to 4K width or height and keeping the either dimension proportional, then adding black border to the empty space. This generally looks good and fits as much of the actual game into the frame as possible, but can result in non-integer scaling of the vertical dimension. Note that for early PAL consoles, this will usually result in letterboxing, which is actually accurate to TV display for early Japanese PAL consoles. Since the consoles were designed for the shorter NTSC system that could at most do 240 lines, and almost all PAL TVs would generally show at least 260 lines, there would be borders at the top and bottom of the image[8].

Integer Scaling

This is scaling the PAR-corrected image's vertical dimension to as large an integer-scaling factor as possible that still fits within the target 4:3 frame, which for 4k is 2880x2160. Since scanlines are a defined, quantized parameter of consoles' output, having uneven lines due to uneven scaling can be undesirable. Horizontal resolution, defined by dots, is by contrast a continuous value that will almost always be defined by non-integer values, so it is not as important to preserve integer scaling for the horizontal dimension. This type of scaling can result in wasted space if the original image being scaled does not scale nicely to some size that is near the final frame size. A fringe bonus of this type of scaling is that it might represent actual output on a television better than the other methods since most TVs would not be adjusted to fit every image perfectly, or show the entire active area (impossible for most consumer sets).

Active Area

This format amounts to padding the PAR-corrected framebuffer image out to the console's active area, then scaling. Consoles' active area will be a 4:3 frame that scales nicely to the target resolution, but may or may not maintain integer scaling of the vertical dimension, and will almost certainly result in a lot of wasted space. This is not a realistic output mode as no consumer television would have been adjustable to show this much of the signal.

Examples

Note that these are simulated images designed only to show off the relative proportions of the image to the frame.
Maximum FitInteger ScalingActive Area
NTSC
PAL

Console Data

Output formatting instructions for each console are designed assuming the TASVideos official publishing script workflow. This means specifically for these instructions that the video is scaled to a 4:3 aspect ratio as a final step in processing. The steps presented here will modify a video dump from a specified emulator such that scaling to a 4:3 aspect ratio at the end will yield the correct PAR.

Atari 2600

NTSC Maximum Fit / Integer Scaling 

AviSource("seaquest.avi")
Crop(0, 4, 0, -4)
AddBorders(4, 0, 4, 0)
The 2600 does not actually have a fixed vertical resolution, and will display as many lines as the programmer tells it to display[10]. However, a common number of lines used is 192 since they will all reside in the "safe" area of an NTSC television, and so that figure will be assumed. Crop 4 pixels of border from left and right, add 4 pixels of border to top and bottom for 168x216 resolution. Correcting this resolution for PAR yields exactly 288x216 pixels, which has a DAR of 4:3 and is conveniently exactly 1/10th of the 4k resolution 2880x2160. When the script stretches the source video to 4:3, 12:7 PAR will be achieved. Note that borders for 2600 games vary quite a bit and there may be border on only one side of the frame, or several sides. The amount of cropping on the top/bottom and the amount of padding on the left/right sides can be moved around, as the borders basically represent an amount of overscan allowance or picture centering.

Commodore 64

PAL Integer Scaling 

AviSource("astro.avi")
crop(112, 18, -8, -24) # For a *full borders* dump
The borders in the signal are not generated by the C64 - the listed border size is the maximum possible displayable border given the output characteristics, thus any amount of border around the framebuffer is technically correct. Nevertheless, this crop attempts to retain their relative proportions. The method used to derive these numbers assumes a 4K target resolution but that's just for convenience. To prepare our image, we cut the full border image down to the 402x292, using the border sizes listed.
2880/PAR = 3077.98 pixels, so we want to scale an image such that it gets very close to this size before applying PAR. Integer scaling our image by 8x yields 402 * 8 = 3216, so we're off by 3216 - 3077.98 = 138.01 pixels. Converting back to the original size, we have 138.01 / 8 = 17.25 pixels to remove from the sides. To preserve the proportions of the borders, we remove 17.25 * (46 / (46 + 36) ) = 10 pixels from the left, and 17.25 - 10 = 7.25 pixels from the right, however, that leaves us with a non mod 2 size which can mess up AviSynth, so instead we take off 8 pixels from the right side.
2160/8 = 270, so that is our target number of lines to keep. 292 - 270 = 22 lines to remove. We proportion the borders the same way as we did horizontally. We remove 22 * (43 / (43 + 49) ) = 10 pixels from the top, and 22 - 10 = 12 pixels from the bottom.
The resulting image is 384x270. Scaled 8x (or scaling vertical resolution to 2160, equivalently), we get 3072x2160. Correcting for PAR gives 2874x2160, with the corrected framebuffer occupying ~2395x1600 pixels. The encode script will expand 384x270 to 2880x2160, which gives us 6 pixels (0.2%) error in horizontal scaling.

Intellivision

Maximum Fit / Integer Scaling 

AviSource("tower.avi")
crop(4,0,-4,0)
horizBorder = last.crop(0,0,last.width, 4)
last = stackvertical(stackvertical(horizBorder, last), horizBorder)
Intellivision is handled nearly identically to how the Atari 2600 is (they have very similar hardware). Crop 4 pixels of border from left and right, add 4 pixels of border to top and bottom for 168x216 resolution. Correcting this resolution for PAR yields exactly 288x216 pixels, which has a DAR of 4:3 and is conveniently exactly 1/10th of the 4k resolution 2880x2160. When the script stretches the source video to 4:3, 12:7 PAR will be achieved. A note on the borders: BizHawk output contains 8 pixels of border on each side of the image. The Intellivision does not actually output a border - the borders from BizHawk are there as allowance for internal framebuffer space the core uses to hold sprites[4], so the actual relative sizes of borders on a TV would vary based on the TV's tuning. The Intellivision however can set the color of the unused portion on the screen, so line doubling needs to be used for adding the vertical border to the source.

NES

NTSC Maximum Fit 

AviSource("mario.avi")
AddBorders(3, 0, 2, 0)
This formatting is noteworthy for NTSC NES because just scaling the footage directly to a 4:3 DAR gets very, very close to accurate PAR. Note that this scaling assumes that the captured video is 256x224 pixels, not 256x240 pixels. We see that the corrected framebuffer is 292.57 pixels wide. Multiplying 224 by 4/3 we get 298.67 dots, a difference of 6.097 dots. Converting back to pixels by multiplying by (7/8), we get 5.33 pixels. The NES outputs an image that is 1.5 pixels shifted to the right[8], so the border is 1 pixel thicker on the left.

NTSC Integer Scaling / Active Area 

AviSource("mario.avi")
AddBorders(12, 8, 12, 8)
NOTE: Coincidentally, for NTSC NES, both integer scaling and active area formats are identical. There is also an important caveat for these formats: the NTSC NES actually outputs 240 lines[8], but BizHawk (and other emulators) will only output 224 of these lines by default. This is because TVs of the era would uniformly be unable to display more than 224 of these lines. For this reason, floating a 256x224 frame in borders may be inaccurate since there are actually 240 lines, though the 16 lines not shown may have garbage in them.
We know from the maximum fit derivation that the output image will be constrained by height. Dividing our target resolution of 2160 by 224, we get 9.6, so our scale factor is 9x. Corrected width then becomes 256 * (8/7) * 9 = 2633.14 dots, and scaled height becomes 224 * 9 = 2016 pixels. Our width difference is 2880 - 2633.14 = 247 dots, and our height difference is 2160 - 2016 = 144 pixels. Scaling back to native to get borders, we have for width (247 * (7/8)) / 9 = 24 pixels, and for height we have 144 / 9 = 16 pixels.
The active area derivation is simply to set the width and height to 280x240 (the NES's active area) and scale to 4:3.

PAL Maximum Fit 

AviSource("mario.avi")
AddBorders(0, 13, 0, 13)
Dividing our target resolution by the corrected framebuffer width, we have 2880 / (256 * 1.3862) = 8.116 scale factor. Scaling height we get 240 * 8.116 = 1947.8. Finding our height difference and scaling back to native scale, we have (2160 - 1947.84) / 8.116 = 26.15 pixels.

PAL Integer Scaling 

AviSource("mario.avi")
AddBorders(2, 15, 2, 15)
Determine our scaling factor assuming width defines it by 2880 / (256 * 1.3862) = 8.115, so an 8x scale factor. Find width and height differences by 2880 - (256 * 1.3862 * 8) = 41 dots, and 2160 - (240 * 8) = 240 pixels. Converting our differences back to native scale, we have (41 / 8) / 1.3862 = 3.7 pixels, and 240 / 8 = 30 pixels.

PAL Active Area 

AviSource("mario.avi")
AddBorders(11, 24, 10, 24)
Add borders to the image to get a 277x288 pixel resolution per the active area of a PAL NES[8], favoring the left side since the NES places the image 1.5 pixels right of center[8], then scale to 4:3. Note that PAL TVs would draw at least 260 lines (20 before and 20 after the NES image)[8], so this output format may actually be closest to representing the top and bottom borders accurately for a PAL system.

SNES

†: These framebuffers need to be at least doubled prior to correcting for PAR in order to preserve high-definition detail.

A note on "Hi-Res" modes

The SNES's Hi-Res Mode 5 and Mode 6 achieve a higher resolution by setting bits in the SETINI register.[12] Both modes set the pseudo-hires mode bit which makes the SNES use a 512 pixel-wide resolution. The screen interlace bit can also be set in these modes, which will increase the vertical resolution to 448 (or 477 for PAL) pixels/lines.[13] Games can also set the interlace bit without using Mode 5 or 6 (resolution 1), and while this is not technically a "hi-res" mode, it is included here and treated like one. The only game I've seen that uses this resolution is Top Gear 2, which uses it for its ending credit sequence.

NTSC

Same as NES.

NTSC Hi-Res

Maximum Fit
# Resolutions 1/2/3
AviSource("secretofmana.avi")
AddBorders(6, 0, 5, 0)
We see that the corrected framebuffer is 585.14 pixels wide. Multiplying 448 by 4/3 we get 597.33 dots, a difference of 12.19 dots. Converting back to pixels by multiplying by (7/8), we get 10.67 pixels. The NES outputs an image that is 1.5 pixels shifted to the right[8], so the border is 1 pixel thicker on the left.
Integer Scaling
# Resolutions 1/3
AviSource("secretofmana.avi")
AddBorders(59, 46, 59, 46)
We know from the maximum fit derivation that the output image will be constrained by height. Dividing our target resolution of 2160 by 448, we get 4.8, so our scale factor is 4x. Corrected width then becomes 512 * (8/7) * 4 = 2340.57 dots, and scaled height becomes 448 * 4 = 1792 pixels. Our width difference is 2880 - 2340.57 = 539.43 dots, and our height difference is 2160 - 1792 = 368 pixels. Scaling back to native to get borders, we have for width (539.43 * (7/8)) / 4 = 118 pixels, and for height we have 368 / 4 = 92 pixels. 
# Resolution 2
AviSource("secretofmana.avi")
AddBorders(12, 8, 12, 8)
We know from the maximum fit derivation that the output image will be constrained by height. Dividing our target resolution of 2160 by 224, we get 9.6, so our scale factor is 9x. Corrected width then becomes 512 * (4/7) * 9 = 2633.14 dots, and scaled height becomes 224 * 9 = 2016 pixels. Our width difference is 2880 - 2633.14 = 246.86 dots, and our height difference is 2160 - 2016 = 144 pixels. Scaling back to native to get borders, we have for width (246.86 * (7/8)) / 9 = 24 pixels, and for height we have 144 / 4 = 16 pixels.
Active Area
# Resolution 1
AviSource("secretofmana.avi")
AddBorders(12, 16, 12, 16)
Active area width is 280 pixels by 480 lines. Stretching to 4:3 achieves a correct PAR. 
# Resolutions 2/3
AviSource("secretofmana.avi")
AddBorders(24, 16, 24, 16)
Active area width is 10.74Mhz * 52.148μs ~= 560 pixels[1], by 480 lines. Stretching to 4:3 achieves a correct PAR.

PAL

Same as NES.

References

[1] https://pineight.com/mw/?title=Dot_clock_rates
[2] https://console5.com/techwiki/images/a/ad/AY-3-8900.pdf
[3] https://atariage.com/forums/topic/240543-what-can-an-intellivision-do/?tab=comments#comment-3278143
[4] https://github.com/TASEmulators/BizHawk/issues/2670
[5] http://hitmen.c02.at/temp/palstuff
[6] https://retrocomputing.stackexchange.com/questions/7128/visible-resolution-of-c64-video-output-including-borders
[7] https://pineight.com/mw/index.php?title=50_Hz_dot_clock_rates
[8] https://wiki.nesdev.com/w/index.php/Overscan
[9] https://problemkaputt.de/2k6specs.htm
[10] https://atariage.com/forums/topic/169128-what-is-the-atari-2600-screen-resolution
[11] https://dustlayer.com/c64-architecture/2013/5/7/hardware-basics-part-1-tick-tock-know-your-clock
[12] https://wiki.superfamicom.org/registers#setini-screen-modevideo-select-638
[13] https://wiki.superfamicom.org/backgrounds#mode-5-216
HomePages/Zinfidel/PixelAspectRatio last edited by on 1/1/2022 6:14 PM
Page History Latest diff List referrers View Source