For some time now the consumer electronics industry has been grappling with how to improve the performance and efficiency of display interfaces, especially in light of more recent increases in display resolution. Through the eras of DVI, LVDS/LDI, HDMI, and DisplayPort, video has been transmitted from source to sink as raw, uncompressed data, a conceptually simple setup that ensures high quality and low latency but requires an enormous amount of bandwidth. The introduction of newer interface standards such as HDMI and DisplayPort have in turn allowed manufacturers to meet those bandwidth requirements so far. But display development is reaching a point where both PC and mobile device manufacturers are concerned about their ability to keep up with the bandwidth requirements of these displays, and their ability to do so at reasonable cost and resource requirements.

In order to address these concerns the PC and mobile device industries – through their respective VESA and MIPI associations – have been working together to create new technologies and standards to handle the expected bandwidth requirements. The focus of that work has been on the VESA's Display Stream Compression (DSC) standard, a descriptively named standard for image compression that has been in development at the VESA since late 2012. With that in mind, the VESA and MIPI have announced today that DSC development has been completed and version 1.0 of the DSC standard has been ratified, with both organizations adopting it for future display interface standards.

As alluded to by the name, DSC is an image compression standard designed to reduce the amount of data that needs to be transmitted. With DisplayPort 1.2 already pushing 20Gbps and 1.3 set to increase that to over 30Gbps, display interfaces are already the highest bandwidth interfaces in a modern computer, creating practical limits on how much further they can be improved. With limited headroom for increasing interface bandwidth, DSC tackles the issue from the other end of the problem by reducing the amount of bandwidth required in the first place through compression.

Since DSC is meant to be used at the final transmission stage, DSC itself is designed to be “visually lossless”. That is to say that it’s intended to be very high quality and should be unnoticeable to users across wide variety of content, including photos/video, subpixel text, and potentially problematic patterns. But with that said visually lossless is not the same as mathematically lossless, so while DSC is a high quality codec it’s still mathematically a lossy codec.

In terms of design and implementation DSC is a fixed rate codec, an obvious choice to ensure that the bandwidth requirements for a display stream are equally fixed and a link is never faced with the possibility of running out of bandwidth. Hand-in-hand with the fixed rate requirement, the VESA’s standard calls for visually lossless compression with as little as 8 bits/pixel, which would represent a 66% bandwidth savings over today’s uncompressed 24 bits/pixel display streams. And while 24bit color is the most common format for consumer devices, DSC is also intended work with higher color depths, including 30bit and 36bit (presumably at higher DSC bitrates), allowing it to be used even with deep color displays.

We won’t get too much into the workings of the DSC algorithm itself – the VESA has a brief but insightful whitepaper on the subject – but it’s interesting to point out the unusual requirements the VESA has needed to meet with DSC. Image and video compression is a well-researched field, but most codecs (like JPEG and H.264) are designed around offline encoding for distribution, rather than real-time encoding as part of a display standard. DSC on the other hand needed to be computationally cheap (to make implementation cheap) and low latency, all the while still offering significant compression ratios and doing so with minimal image quality losses. The end result is an interesting algorithm that uses a combination of delta pulse code modulation and indexed color history to achieve the fast compression and decompression required.

Moving on, with the ratification of the DSC 1.0 standard, both the VESA and MIPI will be adopting it for some of their respective standards. On the VESA side, eDP 1.4 will be the first VESA standard to include it, while we also expect DSC’s inclusion in the forthcoming DisplayPort 1.3. MIPI in turn will be including DSC in their Display Serial Interface (DSI) 1.2 specification for mobile devices.

With the above in mind, it’s interesting how both groups ended up at the same standard despite their significant differences in goals. The VESA is primarily concerned with driving ultra high resolutions such as 8K@60Hz, which would require over 50Gbps of uncompressed video and something not even DisplayPort 1.3 would be able to achieve. MIPI on the other hand is not concerned about resolutions as much as they are concerned about power and cost requirements; a DisplayPort-like interface could supply mobile devices with plenty of bandwidth, but high bitrate interfaces are expensive to implement and are typically very power hungry, both on an absolute basis and a per-bit basis.

Display Bandwidth Requirements, 24bpp (Uncompressed)
Resolution Bandwidth Minimum DisplayPort Version
1920x1080@60Hz 3.5Gbps 1.1
2560x1440@60Hz 6.3Gbps 1.1
3840x2160@60Hz (4K) 14Gbps 1.2
7680x4320@60Hz (8K) >50Gbps 1.3 + DSC

DSC in turn solves both of their problems, allowing the VESA to drive ultra high resolutions over DisplayPort while allowing MIPI to drive high resolution mobile displays over low cost, low power interfaces. In fact it’s surprising (and almost paradoxical) that even with the additional manufacturing costs and encode/decode overhead of DSC, that in the end DSC is both cheaper to implement and lower power than a higher bandwidth interface.

Wrapping things up, while DSC enabled devices are still some time off – the fact that the standard was just ratified means new display controllers still need to be designed and built – DSC is something we’re going to have to watch closely. Display compression is not something to be taken lightly due to the potential compromises to both image quality and latency, and while it’s unlikely the average consumer will notice it’s definitely going to catch the eyes of enthusiasts. The VESA and MIPI are going in the right direction by targeting visually lossless compression rather than accepting a significant image quality tradeoff for better bandwidth savings, but it remains to be seen just how lossless/lossy DSC really is. At a fundamental level DSC can never beat the quality of uncompressed display streams, but that doesn’t rule out other tradeoffs that will make compression worth the cost.

Source: VESA

Comments Locked


View All Comments

  • iAPX - Tuesday, April 29, 2014 - link

    DSC use DPCM, and it's hilarious to use this kind of "technology" for high-end monitors. Ghosting, Vertical lines that will change depending on pixels preceding it at each line, it has just no sense on 8K displays for professionnals!

    And on the mobile world, it is a non-sense too to put full HD displays on a smartphone or maybe this year Ultra HD/4K displays on a tablet. Drop the DSC and stay with non-marketing screens resolutions, this is the way to go!

    All this thing to please marketing departments, it's just weird!
  • HisDivineOrder - Wednesday, April 30, 2014 - link

    Wouldn't it be easier and better just to do the obvious and use a new spec to stop transmitting all that, "Make the same screen" over and over the cord instead?

    Just tell the monitor to keep displaying the same image until told otherwise. Boom, tons of savings right there. Imagine the savings on a tablet or a PC. Instead, what we have is a whole series of products built around VGA that continue to send data continuously for the entire screen when it'd be far better just to send the only part of the screen that changed.

    Compression's not needed for that. Better monitors (or converters for existing monitors) are needed for that.

    G-sync/Freesync shows us the way. But that'd involve no big news, right? So instead, VESA makes a mountain of a molehill and makes far more of it than should be, pushing into lossy codecs instead of doing the obvious things first.
  • pr1mal0ne - Wednesday, April 30, 2014 - link

    As a FLAC snob, i am sad i will now have to be a mathematically lossless video snob as well, only here, it looks like i will not get the option. This is understandable for mobile and such, but on a desktop in my home where power and number of cords is not a limitation, i will always want to option of lossless. I hope VESA understands this.
  • sonicmerlin - Saturday, May 3, 2014 - link

    I'm curious how much compression could they achieve with a mathematically lossless codec?
  • simonpschmitt - Friday, May 9, 2014 - link

    @HisDivineOrder: What you are proposing is esentially a rudimentary, losless comression. (and it would be interframe so: lag, RAM, ... see previous posts.)

    @sonicmerlin: The problem with losless is that it has to be adaptive, witch means it could propably get really good compression rates most of the time. But, every losless compression has "perfect storm" data patterns were it can get no compression at all. Or even worse, it adds data.
    When you are bandwidth-constraint you have to guarantee a compression factor to always stay inside the limit. You can't do that with a "perfect storm" pattern so you can't do that with lossless.

    I just hope that for graphical work you can choose a lower refresh rate (i.e. 30Frames/sec) without compression.

Log in

Don't have an account? Sign up now