# How do I compute the required bandwidth for a given bitrate of digital TV signal?

In this Encyclopædia Britannica article, there is a paragraph which introduces why video compression was needed to switch from analog to digital television broadcasting. It gives the following example.

For example, the NTSC colour signal is based on 483 lines of 720 picture elements (pixels) each. With eight bits being used to encode the luminance information and another eight bits the chrominance information, an overall transmission rate of 162 million bits per second would be needed for the digitized television signal. This would require a bandwidth of about 80 megahertz—far more capacity than the six megahertz allocated for a channel in the NTSC system.

First, I am not sure how they compute "162 million bits per second" since

$$720 \times 483 \times 2 \times 8 \times 29.97 = 166,757,875$$

and no other standard framerate matches their result. Am I missing something ?

However, my main question is : how do they compute the theoretical required bandwidth of 80MHz ?

Let's admit that their result of 162Mbit/s is correct. If I considered the ideal case of a noiseless channel and computed Nyquist maximum channel capacity using 8 bit samples, I would get

$$B = \frac{C}{2 \log_2(M)} = \frac{162 \times 10^6}{2 \log_2(2^8)} \approx 10.1 \text{MHz}$$

I have tried to reverse-engineer their result using Shannon-Hartley,

$$C = B \log_2(1 + \frac{S}{N}) \implies \frac{S}{N} = 2^{\frac{C}{B}} - 1 = 2^{\frac{162 \times 10^6}{80 \times 10^6}} - 1 \approx 3.0$$

which leads me to think that they used a 5 dB signal-to-noise ratio. Where does it come from ? Did they eyeball it or is there a theoretical way to reproduce their result ?

They use 704 for the horizontal x 480 vertical, which is typical for MPEG-2. That works out to 162Mbit/s. That's their mistake - they're putting the MPEG cart before the horse in computing the raw pixel rate for CCIR656-type format. They should have either computed it based on 720 or explained why they used 704.

Speaking of which... why 704?

Part of the reason 'only' 704 is used is to allow for the left and right edges to be smoothly transitioned from blank to active and back to blank again. This reduces ringing and artifacts at the edges when processing and encoding the signal. Many production houses still use 704 as the ‘safe’ area, especially in DVD authoring (hard to imagine that anyone cares much anymore about that dying format, but here we are) and use fade-up/fade-down at the edges.

It's also possible to synthetically make smoother left/right edges outside of the official CCIR 720-pixel active area and encode the whole 720 - for example, by replicating the leftmost and rightmost pixels. That takes more work. In 1995-ish that 'more work' mattered, not so much anymore.

Another part of the reason for 704 is to make the number of pixels a mod-16 multiple to be compatible with 352x480. Again, relates to filters and again, in 1995-ish that mattered, not so much anymore. (Video CD, anyone?)

And now... bandwidth

For the bandwidth part they're assuming 2 bits/Hz symbol encoding. This is the theoretical maximum using 2-level serial encoding, such as that used on Serial Digital Interface (SDI.) This is an extremely simplistic assumption, given that narrower bandwidth could be used with more bits per symbol.

And it is indeed the case with 8-VSB for ATSC and QAM-64/256 used for cable, which can not only carry compressed SD but also HD, and even carry multiple streams in the same 6MHz legacy channel.

• For completeness: ATSC carries a net bitrate (after error correction) of 19.4MBit/s in a 6MHz channel. 256QAM doubles that to 38.8. Still only enough to get you up to about one 240p stream if you were doing raw 30fps, 8bpc 4:2:2 Commented Apr 24, 2021 at 20:09
• That, and NTSC is limited to well below D1 pixel resolution - 3MHz for luma, less than 1MHz for chroma. Commented Apr 24, 2021 at 22:55

Since it's a completely hypothetical situation, it's difficult to guess how they came up with those numbers.

In fact, the NTSC signal devotes less bandwidth to representing color, and the entire baseband signal can be adequately represented by sampling it at 13.5 MHz with 8-bit samples, for a raw data rate of just 108 Mbps.

And that could be reduced significantly by simply throwing away most of the data in the blanking intervals.

The calculations make little sense, as they have mixed up various different terms together.

NTSC basically means analog composite video signal with of 4.2 MHz video bandwidth, where using System M standard 525 lines is sent every 29.97 Hz with NTSC color encoding. If that is digitized into digital composite video, it is usually sampled at 4x the color subcarrier rate, and using 10-bit SDI in a studio setting makes the bitrate 143.18 Mbps nominal. It would still basically not have pixels, but it would have about 768 samples defined for the active digital video content, but it would include less than 768 samples of active analog video.

Same thing with studio component signal that is sampled at 13.5 MHz to end up with 720 x 483 active digital data. The 720 digital active samples would cover more than the available active analog video has, and it will have only 704 digital samples. However, in studio, this is usually sampled as 720 luminance (brightness) pixels, but only 360 color difference pixels for Cb and 360 color difference pixels for Cr, so due to the 4:2:2 sampling the data rate sent over 10-bit SDI interface is 270 Mbps.

So clearly these will not fit into a 6 MHz channel without some form of compression and modulation.