Digitizing analog video is still a giant mess

Aug 30th, 2026 - scudo

Let me get this straight: there is no perfect way to digitize analog video. There is always bound to be some loss. But it has no right to suck this much.

The standard way is not very clear

The preferred (and standardized) way to digitize both 525 and 625-line standard definition analog video (respectively NTSC-like and PAL/SECAM like video systems) is to refer to the ITU's Rec. 601 standard (AKA BT.601 and several other names).

This document specifies how to digitally sample analog video; in particular, it specifies that analog video has to be digitized by sampling the luminance signal 720 times per scan line and sampling the "colour difference" signal 360 times per scan line:


The "colour difference" ITU is talking about are the gamma pre-corrected C_R and C_B chrominance signal; these are the two color components of an analog color video signal, that together with the luminance part compose a "composite" (or baseband!) video signal, which is then modulated with a 13.5 MHz carrier and transmitted over a wire (but not over the air; that requires extra modulation to put the composite video signal into a TV channel to be broadcast).

This way of representing analog video digitally is known as YC_BC_R 4:2:2, because the video information is split up in 3 components: the luminance "Y", the gamma-precorrected blue part of the signal "C_B", and the gamma-precorrected red part of the signal "C_R"¹ , and for every 4 luminosity samples we have 2 blue samples and 2 red samples² .

In all of this, ITU neglected to write down any recommendation for the vertical resolution! This is a huge problem!!

Screen aspect ratio issues

See, analog video (per both NTSC and PAL specifications) has a 4:3 aspect ratio; but the Rec. 601 spec is for both 4:3 and 16:9 widescreen video, and does not give any indication of any difference in sampling rates. This is on purpose to maintain compatibility with how actual widescreen analog video works.

Widescreen analog video works by simply cramping more horizontal information in every scanline; since no CRT screen has a defined horizontal resolution (especially black and white sets)³ , widescreen-compatible sets are capable, if signaled to do so by special V-Blank data, of showing that extra horizontal information by stretching the picture horizontally to achieve a 16:9 screen, while incompatible sets can just ignore that extra information (and do ignore it since they are physically incapable of showing it).

Capture cards ignore that information and don't react accordingly; some cards (like my Brooktree Bt848) have the option of horizontal oversampling to produce a widescreen digital picture; my card in particular can digitize at 960x576, which is almost a 16:10 resolution (it's off by about 0.06).

So, you have to know beforehand if what you are going to digitize is widescreen or not (almost always not) and if your capture card supports horizontal oversampling, and you must remember to not set oversampling where it is not needed or you will get a stretched picture.

Pixel aspect ratio issues

Analog video does not have pixels; but for practical purposes, during video digitizing it does. And it does not have square pixels; by some unsourced claims I have found on the internet (1 and 2), PAL video specifically has a pixel aspect ratio of ⁵⁴/₅₉, or ⁴⁵/₄₈, or ¹¹/₁₀. What? Which one is it? (Side note, SGI says 525-line video uses a pixel aspect ratio of ¹¹/₁₀ and 625-line video uses a pixel aspect ratio of ⁵⁴/₅₉).

The point to bring home is that analog video "pixels" (or more accurately, samples) are (at least it seems for PAL) to be wider than they are tall; this stretch may explain why some digital resolutions don't match a 4:3 aspect ratio when assuming square pixels.

Common resolutions don't match 4:3 aspect ratios when assuming square pixels

There are several resolution that are commonly suggested, and every one of it has its issues:

• 720x576: the most common resolution, also the one used by DVDs and MiniDV tapes; it's a 5:4 picture. It's likely the correct one though, given non-square "wide" pixels.
• 702x576: apparently used by MPEG (unsourced claim); it's a 39:32 picture, fairly close to 4:3.
• 704x576: apparently suggested by ITU (unsourced claim); it's a 11:9 picture, even more square than the previous one.
• 704x480: apparently used by all forms of digital TV (per PCMag), it's a 22:15 picture (slightly widescreen)
• 720x480: apparently popular with DVDs; it's a 3:2 picture, a bit thinner than widescreen. Internet says DVD player software commonly stretches this resolution to a 16:9 aspect ratio.

Also: those 576 pixels of vertical resolution are nowhere to be found in Rec. 601, because that is the number of visible scanlines in a 625-line system (such as PAL); this means that they are too many for NTSC-like system. Oops!

Frame rate and interlacing issues

Deinterlacing suuuuuuucks... just use double Yadif. Good luck with progressive video. Remember: more lines, less fields per second. Progressive scan means half the lines, twice the framerate, and fields are frames, so you don't need to deinterlace.

Conclusion

My personal advice is: digitize in 720x576, digitally stretch to 16:9 if you have widescreen video, deinterlace if you need to, and take care to use the correct framerate for the video standard of your source.

---

¹ We work in luminance, and not in luminosity, because luminance is relative and luminosity is absolute. That is why we need to gamma-correct the red and blue signals; because we need them to be relative and not absolute.

² High-quality analog video storage is digitized in YC_BC_R 4:4:4 to preserve more color information; all this also means that YC_BC_R 4:2:0 video via chroma subsampling is absolutely awesome because it allows us to get rid of the red part of the signal and save on bandwidth and storage.

³ Color CRTs are technically limited by the dot pitch of the shadow mask/aperture grille. Now get out of my house.