Here’s is a very common query that is made relative to video compression, usually with embedded implementations. There is a vernacular of terms that are often improperly stated or misunderstood and I’d like to help alleviate some of that confusion. As a preface, our own web site is not overly clear on some of these points as well…but we are currently working to change that.
The term bitrate is pretty well established and basically means the number of bits of data that can be transported over some type of networked medium. This medium can be a data bus (e.g. PCI-X), a hardwired connection/protocal (e.g. HDMI), a protocol over a hardwired connection (e.g. HD-SDI over coax, GigE) or a wireless connection (e.g. 802.11, UWB).
Digital video, whether compressed or uncompressed, can be transported over all of these mediums. But in the case of a compressed video form (e.g. JPEG2000, H.264 or MPEG-2) there are two primary processing activities for which the term “throughput” is often applied, that being encoding and decoding (hence the term CODEC). In other words, the video content needs to be compressed (encoded), transported over the networked medium, and then decompressed (decoded) at the target destination. “Throughput” is often applied to mean how fast that encoding or decoding process can occur.
For example, if you use a digital camcorder the first instance of compression is often happening on the camcorder into the DV format. Then it might be transported via Firewire or USB to your computer. Your computer will need to decode it to display the video. On the camcorder there is an embedded processor chip that will compress the video content in “real-time” to a storage medium. The only function of that chip is to encode video, so its “throughput” is fast and it can handle a large amount of content…for example HD content.
In this example, you are not transporting the video in real-time, so the restrictions of the wired interface may not be all that important. It may be annoying to wait while a video downloads from your camera, but Firewire and USB can usually push the content across at or close to real-time. Once its on your computer, there are a number of factors by which the “throughput” moniker could be applied. Some of them will vary depending on the state of various activities on your computer. How fast your hard drive can extract and deliver data can be termed “throughput”. The bus speed of your computer can influence “throughput” as well. And your computer’s processor is probably the biggest determining factor of “throughput”.
I have an Intel dual-core processor on a MacBook Pro. Under certain circumstances I can play HD video content in real time. Other circumstances I cannot…in which case the decoder will begin to drop frames in order to keep pace. It’s important to understand what the various bottlenecks may be and how they could affect your “throughput”. As a consumer, this may affect the quality of your viewing experience. If you are an engineer designing a video capture system, then you need to be able to match the “throughput” of your processes to the desired video specifications of your system.
So let’s use a real-world example. Let’s say your are designing a system that will encode (compress) HD720p video, transport it over an 802.11n wireless network, then decodes the video (decompress) and plays it on a video monitor. The raw uncompressed data contained in HD 720p video feed will result in a bitrate of at least 633 Mbs (this is without audio, video only). This assumes a resolution 1280×720, an RGB color space at 8 bits per plane for 24-bit color, and 30 frames per second. The equation looks like this 1280*720*3*8*30 = 663,553,000 total bits. Divide by 1024 to covert to Kbs and again by 1024 to get Mbs.
To encode that content in real-time, you would need an encoder and processor capable of processing at least 633 Mbs of “throughput”. For a variety of reasons, this benchmark is often stated in terms of MB/s (megabytes instead of megabits) and sometimes in terms of megasamples per second, which is more of an embedded hardware benchmark. If, for example, a vendor states throughput of 100 MB/s this usually means they are capable of handling up to 800 Mbs (100 MB/s * 8 bits/byte) of throughput. In this circumstance, they could easily handle 633 Mbs of data and still have plenty of headroom for things like audio.
The bitrate that is transported via the networked medium is really of function of compression. Let’s say you have an 802.11n wireless connection. Theoretically it can move data at 248 Mbs. However the practical data rate is closer to 75 Mbs. If you have data that, in its raw form, is currently 633 Mbs and you need to move it over a 75 Mbs transport, then you would need to compress at a ratio of 8.44:1 (633 Mbs / 75 Mbs). That is a very feasible solution and the visual result should prove to be quite good. In my next post, I’ll dig further into these concepts and how they apply to JPEG2000 specifically.
Here is an excellent background tutorial on data compression written by Steven W. Smith, Ph.D.: