Implementing JPEG2000 compression

As High Definition video becomes more prevalent in the market, compression has become an important, mandatory step in its transmission due to the sheer quantity of data involved. Most of us are familiar at a high level, if not with the details, of MPEG which is the standard for digital distribution of video. Many may also be familiar with H.264 which aims to replace MPEG in that role. So down in the cubical trenches, when marketing has decided our next big video thing has to ship tomorrow, naturally MPEG (or H.264) is the first place we’ll look. In the case of SD (standard definition), it may be sufficient, but for HD this may be an issue, as real-time, high quality HD MPEG encoding with very low latency is still the province of the high-end rack mount. If that scenario sounds all too real, there is hope. JPEG2000 offers affordable, real-time HD encoding and decoding with very low latency. Below, we’ll try and demystify the issue and then provide some simple examples to get your product out the door faster and with minimum fuss.

About JPEG2000
JPEG2000 is a wavelet-based compression standard. Despite the name, it’s only come into wide use recently. It has no temporal element; it compresses images on a frame by frame basis. This is what gives it the advantage of very low latency without the quality sacrifice you would make with I-frame only MPEG as well as the drawback of poorer performance at ultra-low bandwidths. Precise rate control is also an advantage for constrained channels, as JPEG2000 can take a specific rate target and not exceed it by truncating the data at an optimal point. So if your channel is 10Mbit/s, you can guarantee that you will not exceed that bandwidth.

Figure 1: wavelength decomposition process

JPEG2000 also has interesting features applicable to the transmission of video which are derived from the wavelet transform. The wavelet decomposition process (Figure 1) breaks the image down into resolutions, each half the size of the one above it. Each resolution is broken down into high and low frequency components in both the horizontal and vertical direction. The low pass vertical and low pass horizontal, or "LL" sub band, is the one which is then transformed again to a lower resolution. At the end of the transforms, the LL sub band is basically a thumbnail of the original image which contains all the most important information. The multiple resolutions of the transform give the user the ability to extract and decode a smaller resolution image from the code stream without decompression and scaling. It’s simply a matter of only decoding (or transmitting) the sub bands up to the desired resolution. The fact that the most important information is in the LL sub band implies that in a lossy transmission environment, errors in the other 80% of the code stream will have little visual impact. This reduces the need to sacrifice bandwidth on further error correction, as well as the extra development effort needed to implement it.

In addition to the wavelet transform, the organization of the data in the final code stream of JPEG2000 places data in packets based on sub-bands for each resolution, precinct (location in the image), quality layer, and color component. You can selectively transmit or decode these packets to achieve whatever combination of quality, resolution, number of components, or image area you want all from the same original code stream with no need for decompression before you can work with it. Clearly, there are many video applications that could benefit from these features… but bridging the gap from problem to solution requires more than just a specification on paper.

About the ADV202Figure 2: ADV202, JPEG2000 codec

The ADV202, a System-On-A-Chip JPEG2000 codec (Figure 2) can provide the bridge to this gap. With hardware to do the most compute intensive aspects of the standard, and software to put it all together, the ADV202 provides a complete JPEG2000 codec solution in one chip for SD, or two chips for HD. The ADV202 requires no external memory; just a video interface on one side and a host to program and source/receive compressed data.

For High Definition, two chips are required because the maximum throughput of the video interface on the ADV202 is 65 Msamples/s. 720p and 1080i exceed that, so the components are split with Luminance data going to one ADV202, and Chrominance data going to the other, with both parts running on the 74.25Mhz video clock. One ADV202 can handle a standard definition stream in standard 656 at 27Mhz with the components interleaved.

In a nutshell, the ADV202 produces a JPEG2000 compliant code stream from each part. In the case of HD, there will be one code stream with only luminance, and one with only chrominance. This code stream is produced at full frame rate with slightly over one frame of latency for encode. The decisions an engineer will need to make to get off the blank page include: How to get video in/out of the part? How to get compressed data in/out of the part?