Multimedia
Blogs
Forum
Affordable HD
Whitepapers
Newsletters
Events
Advertisers
Blogcast
MillimeterBonding with bandwidth
Jun 1, 2001 12:00 PM, By Steve Epstein
From analog to digital and between bandwidth and bit rate, the
intersections are few and the numbers are numerous.
Over the years, the term bandwidth has taken on a variety of meanings. From a technical standpoint, bandwidth is the frequency range of a signal. For instance, the bandwidth of many analog audio signals is 20Hz to 20kHz. This bandwidth closely resembles the frequency range associated with human hearing.
In the digital world, bandwidth is typically used to describe the capacity of a channel, measured in bits per second. This is because the number of bits transferred is usually more informative than the frequency range of the signals needed to transfer the bits. Technologies such as signal compression, broadband Internet access, and digital television have brought the subject of bandwidth to the forefront. This article looks at the capacities of various technologies and their tradeoffs, both individually and combined.
Analog bandwidth
Relative to an audio signal, bandwidth is fairly
straightforward. The frequency range used matches the frequencies
sensed by human ears. Video is a bit more complex. The frequencies
sensed by our eyes are in the visible portion of the
electromagnetic spectrum — a 10
To produce an image on a video screen, the screen is scanned by an electron beam from top to bottom and left to right. Video scanning is done at 60Hz (vertical) and 15kHz (horizontal). Each horizontal line is composed of individual frequencies that represent picture details. The smaller the detail, the higher the frequency. In television, a pair of lines (one black and one white) is considered one line of resolution. Thus, if you could see (and count) 720 vertical lines on the screen (360 black lines interwoven with 360 white lines) the resolution would be 360 television lines.
Why all this talk about lines of resolution? It happens that lines of resolution translate very easily to bandwidth. For every 80 lines of resolution, you need about 1MHz of bandwidth.
The channel bandwidth of a broadcast TV signal is 6MHz, and only about 4.2MHz of that is used for video. Therefore, the typical television only needs to reproduce about 330 lines of resolution. A typical computer monitor running at 800×600 can theoretically produce 400 lines of resolution. I say “theoretically” because there are lots of variables to consider such as brightness, screen size, and the image itself. Ambient light on the screen and the use of color rather than monochrome signals will affect apparent resolution. As the lines multiply and shrink, the image will change from obvious black-white pairs of lines to a neutral gray. At that point, the ability of the screen or circuitry to produce additional resolution has been exceeded.
Digital bandwidth
As stated, digital bandwidth tends to be measured as channel
capacity, or bits per second, rather than with frequency ranges.
Just so we are all on the same page, a bit is the smallest piece of
digital information. It is either a binary 1 or a binary 0, the
equivalent of true or false or, in a different context, yes or no.
An eight-bit binary number is in the range of 0-255
(2
The focus on bit rate is due partly to the nature of digital transmission. Depending on the encoding scheme, the number of transitions from high values (say a “1”) to low values (say a “0”) varies. One way to measure frequency is by counting the number of high-low transitions. Many people think that baud rate is the same as bit rate, but that is untrue. Baud rate is the number of symbols, whereas bit rate is the number of bits. One symbol could easily represent four bits or more, making the bit rate quadruple the baud rate.
Though it's really apples and oranges, there are several different ways to compare analog bandwidth to digital bit rates. And because of this, other items like compressed or noncompressed, lossy or lossless compression, as well as quantization and sample rate need to be discussed.
Compression in the digital domain involves a mathematical transformation that reduces the bits needed to represent a signal (or file). It can be lossless (like WinZip) or lossy (like MPEG or JPEG). With lossless compression, an exact representation of the original can be constructed from the uncompressed signal. Lossless compression ratios are typically limited to 2:1 or 3:1. Lossy compression results in a signal that represents the original but as a degraded copy. The amount of degradation depends on several factors including compression ratio, content of the original, and the quality of the compression algorithm. Lossy compression systems can provide quality compression at ratios exceeding 100:1 in some instances.
Quantization is the number of bits used to represent a sample. The more bits used, the more accurately the original signal can be represented. Sampling rate is the number of samples taken per second. Increased sampling rates provide a more accurate representation of the original. As you may have realized, more bits at increased sampling rates creates additional data, which may need to be compressed to transport from point A to point B. This is why an understanding of bandwidth is so important. How the bits are allocated can determine the quality of the signal at the destination.
Crunching the numbers
That said, let's put some real numbers out for comparison. Audio CDs are a good place to start. For CDs, high-quality stereo audio signals are quantized at 16-bits/channel (typically 20-bits to 24-bits/channel for studio use) and sampled at 44.1kHz (48kHz in the world of television. This creates a 1.411Mbps datastream. One could argue that this is roughly equivalent to the 20kHz (double for stereo) bandwidth of an analog audio signal. For digital television, that signal must be compressed to 384Kbps, or about 4:1. For video, the SMPTE 259M specification calls for sampling of three channels (Y, R-Y, and B-Y) at 13.5MHz (Y) or 6.75MHz (R-Y and B-Y). Quantization can be done at either 8 or 10 bits. The resultant datastream is 270Mbps, of which the video portion is 143Mbps. Consumer DV recorders record at 25Mbps or about one-sixth that rate. Obviously some bit rate reduction (commonly, but inaccurately referred to as compression) must occur. The same thing must take place for digital television, as the transmission data rate is only 19.4Mbps.
Moving to the world of computers and networks, we will find the numbers typically much smaller. This is why compression and bit rate reduction techniques are common. For instance, on an Ethernet 10baseT network, the typical throughput is about 1Mbps. A 100baseT network is 10 times that, or about 10Mbps. Compare those numbers with the uncompressed digital video requirement of 270Mbps. Even the aforementioned consumer DV rate is 2.5 times the available bandwidth of 100baseT.
There are several reasons for the reduced network bandwidth. These include network overhead as well as the nature of the traffic involved. On a typical LAN, all the devices share common cabling. That means that only one device at a time can talk. When network utilization is low, this is not a problem. However, as network traffic increases, collisions occur. If this happens, both devices must re-send their packets after a random delay. This immediately doubles the amount of network traffic, increasing the likelihood of another collision. This can snowball and bring network traffic to a halt.
Bandwidth management
So how do you work with video and audio on a computer network? One way is by carefully segmenting the network using switches. (Sounds like routing switchers, doesn't it?). Another way is through the use of IEEE 1394A and its ability to handle asynchronous and isochronous traffic at rates up to 400Mbps (1394B will be able to handle traffic at 800Mbps).
But the best approach is to consider bandwidth a limited resource that must be managed carefully. Consider that today's standard-definition video production facilities can easily handle multiple data streams of 270Mbps. Nevertheless, many are struggling with HDTV's 1.5Gbps data rate. At the same time, many of those 1.5Gbps streams are going to be combined with six (5.1) or so full-bandwidth audio channels and then compressed to less than 19Mbps for broadcast (that leaves a little room for associated data).
To manage bandwidth effectively, you must first understand the requirements. We have already detailed the basics of audio and video signals. Most of today's production equipment can handle full-bandwidth signals at the I/O ports, but may perform some form of compression internally. DV decks are a perfect example, taking in 270Mbps, subsampling and compressing the signal to 25Mbps for recording, and then doing the reverse for playback and output.
What you need to avoid are the numerous passes through the compression engine that are inherent in the production process. The same was true in the analog process; we called it “generation loss” then.
Another consideration is using appropriate capture and production equipment for the intended display. An extreme example is shooting high-definition video in the field and broadcasting it on the Internet to dialup connections. A comparable thing happens when someone scans an 8"×10" image at 300dpi and puts it in a PowerPoint presentation at 2"×2.5". What he should have done was scan the original at 72dpi and at the proper size.
The next time you are asked for help on a project that is outside of your traditional stomping grounds, first consider the final format: Will it be displayed on the Internet? Projected in a large hall? Broadcast as HDTV? Distributed as a CD-ROM? DVD? VHS? All of the above? In many cases, more than one answer applies. If that is true, pick the highest-quality output and base your project on that. When complete, convert as needed.
But let's say you want to capture a live event and put it on the Internet for a wider audience. Starting with the end in mind, let's look at the bandwidth issues: First, what connections will the viewers have? Broadband? 56K? Let's assume they will have both. Inexpensive broadband connections offer up to 1.5Mbps, but might only guarantee a quarter to half of that. So let's use 275Kbps for broadband and 25Kbps for dialup. Together that makes 300Kbps.
Second, how many streams can the server(s) support? If it can't support the required number of streams, then you'll have to add servers or the reduce stream bandwidth. Once you know the size of the output stream, you can determine where it makes sense to do the compression. Choices could include in the server (this will require additional server bandwidth or processing power), before the server, prior to the transmission link, or at the camera. (Remember that the camera is unlikely to be at the same location as the server, so the signal will have to be transmitted from one location to another.)
At this point it may make sense to shoot the event on an inexpensive camera that effectively compresses the signal as part of the capture and take the camera's low-bandwidth output straight to the server. If, however, the signal must also be fed to national television, then a low-quality camera is unacceptable.
Today's mix of quality, bandwidth, and distribution capabilities makes it difficult to provide a one-size-fits-all solution. Many times the best solution is not obvious nor possible with the equipment on hand. For your customer's sake, and for your long-term success, carefully consider the various trade-offs imposed by bandwidth limitations, and choose the solution that makes sense throughout the process.
Steve Epstein, formerly the senior technical editor of Video Systems, is an industry consultant and freelance writer based in the Midwest. He can be reached at tech.editor@worldnet.att.net.
| Analog | |
|---|---|
| Studio-quality video | 10MHz |
| NTSC TV | 4.2MHz |
| Human hearing | 20kHz |
| Analog telephones | 8kHz |
| Digital | |
| SMPTE 259M | 270Mbps |
| T-3 telco line | 44.7Mbps |
| DV recorders | 25Mbps |
| Digital television | 19.4Mbps |
| T-1 telco line | 1.544Mbps |
| CD Audio | 1.411Mbps |
Continue the discussion on “Crosstalk” the Millimeter Forum.
