VESA and MIPI Announce Display Stream Compression Standardby Ryan Smith on April 22, 2014 8:45 PM EST
- Posted in
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|
|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.
Post Your CommentPlease log in or sign up to comment.
View All Comments
nathanddrews - Tuesday, April 22, 2014 - linkNOoooooooooooooooooo!!!!!
nathanddrews - Tuesday, April 22, 2014 - linkSorry, I just had to get that out. We already have to deal with bad compression on our media, I don't want it on my display.
kpb321 - Tuesday, April 22, 2014 - linkLossy compression was unavoidable. It's impossible to even guarantee any compression with a mathematically lossless compression system let alone a constant bit rate. Hopefully the compression will be controllable and only required at the highest resolutions and refresh rates and uncompressed will be the default any time it is possible.
mavere - Tuesday, April 22, 2014 - linkAt 8 bpp, the encoder would need to be hilariously terrible for anyone to even have a chance of seeing a picture artifact.
Seriously, the buffer zone is massive. The main engineering challenge here is latency, not coding "quality".
nathanddrews - Wednesday, April 23, 2014 - linkWho wants 8bpp? I thought we were moving to 10bpp...
psychobriggsy - Wednesday, April 23, 2014 - linkI believe that the compression will compress up to 36 bits per pixel (12 bits per pixel colour component) down to 8 bits (or maybe the 8 bits is for the 24-bit source, and 36-bit sources will require 12 bits, this detail isn't available in the article). In effect, bandwidth requirements go down to 1/3 or even 1/4 of what they were before.
Other (slower) lossy compression algorithms actually get down to under 1 bit per pixel, so having 8x the data to work with will mean that any loss in the resulting image will be imperceptible (hopefully). This is what @mavere was getting at.
nathanddrews - Wednesday, April 23, 2014 - linkGot it, thanks for clarifying.
sully213 - Friday, April 25, 2014 - link....you bastard!
MikeMurphy - Tuesday, April 22, 2014 - linkI find it amazing that an old-school VGA cable can drive a 1920x1200 display at 60hz. Analogue, but still crystal clear.
I hope the industry develops a really good cable technology (ie. fiber) that can drive such displays. Compression should be optional.
Gigaplex - Tuesday, April 22, 2014 - linkI've seen a VGA cable drive a 1920x1200 display at 60Hz. It is not crystal clear.