草榴社区 Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Table of Contents
DSC has enabled the use of high resolution displays in televisions, PC monitors, mobiles, and automotive infotainment systems. It provides a high quality, low latency algorithm to resolve the bottleneck of high bandwidth requirements needed to support the high resolution.
In our previous blog post, 10K Resolution at 120Hz Display: A Reality Today with DSC 1.2 in HDMI 2.1, we presented how VESA (Video Electronics Standards Association) Display Stream Compression(DSC) embraced HDMI 2.1 to achieve 10K resolutions at 120Hz. In it, we also covered the basic principle of DSC with the help of a diagram which involves dividing the entire frame into slices, replacing a video line with a line of chunks, replacing Hactive (uncompressed pixels) with HCactive (compressed tri-bytes) and replacing Hblank (blanking pixels) with HCblank (blanking tri-bytes). We also mention that HCactive is much smaller than Hactive, which results in compression.
In this blog, we will showcase how exactly a frame is divided into slices, how the chunks are formed, and how the DSC model outputs HCactive bytes.
Basic Principle of DSC Explained
Before DSC is applied, the entire frame is divided into a grid of slices. A slice is a set of compressed pixels that forms a rectangle in the horizontal and vertical dimensions. The number of slices and the slice width are determined using a well-defined algorithm. The slices can be encoded and decoded independently by the DSC processor and that’s how the latency involved is reduced to a minimum. A chunk is a portion of the bit stream that comprises a set of data bytes. The number of chunks in a slice is same as the number of lines within a slice..
The series of single chunks for each of the slices in a Video Line is called a “link of chunks”. The total number of bytes in a line of chunks gives the total number of HCactive bytes. HCactive bytes is the output of the DSC 1.2 block, as shown below.
HCactive bytes = (Number of Slices) *ceiling (slice width * (bpp)/8)
HCactive tri-bytes is the number of tri-bytes (groups of three bytes of compressed video data) in each video line of chunks containing compressed pixel data that is intended for display. The final tri-byte in each line of chunks may contain one or two bytes of zero padding.
HCactive tri-bytes = ceiling (HCactive bytes/3)
Now that we have the compressed video data, the value of HCblank, the number of tri-bytes in each video line of chunks containing horizontal blanking period that is not intended for display, is determined.
An Illustrative Example
Consider the example of VIC 200 which has 7680 active pixels in uncompressed video format. Using the table below, let’s see how compression works. In Example #1 and Example #2, the bits per pixel is set to 8.375. In Example #1 we evaluate the compression ratio if we were to divide the entire frame into 8 slices of 960 pixels each. In Example #2 and Example #3, we calculate the compression ratio if we were to divide the entire frame into 12 slices of 640 pixels each. The only difference between Example #2 and Example #3 is the bits per pixel.
In first two examples, we observe that the compression ratio is 2.86, whereas it is 3 in the third example. DSC allows a maximum compression of 3:1. That’s how the effective bandwidth increases from 48 Gbps to 144 Gbps (i.e. 3*48 Gbps).
Looking Ahead
The VESA DSC 1.2 module is integrated in VC VIP for HDMI 2.1 as well as DisplayPort 1.5/1.4 providing a complete solution for verification of high end display designs supporting up to 10K resolution using compressed video. To understand DSC algorithm in detail, please also refer our white paper – Analyzing the Losses in Visually Lossless Compression Algorithms. Stay tuned for more updates on developments in this area to experience the magic of DSC in HDMI. To know more about 草榴社区 display and other VIPs, please visit .
Continue Reading
Blog
2 min read
/
Sep 12, 2024
Industry First Verification IP for Arm AMBA DTI-G
