One of the more interesting aspects of the DisplayPort standards is how the VESA has the separate but strongly intertwined DisplayPort and Embedded DisplayPort standards. As a result of the standard development process, we see a bit of ping-ponging between the two standards on features. New features get adopted by one sub-standard or the other first, and then after a bit of time show up in the next iteration of the other standard. What would become DisplayPort Adaptive Sync, for example, first started out in Embedded DisplayPort, while the newest bandwidth mode, HBR3, started out on DisplayPort.

After an update for the Embedded DisplayPort standard last year with eDP 1.4a, being announced this week is the next iteration of the DisplayPort standard, bringing it to 1.4. And like the examples above, this is another case where some features are making their way back from eDP to the mainline DP standard, while at the same time new features are coming to the DisplayPort family for the first time. To that end, DP 1.4 is a mix of both old and new, and while also serving as interesting case in highlighting how the two DisplayPort standards differ and why this is necessary.

First off then, despite the updated version number and unlike previous DisplayPort “point updates,” the latest update does not change the physical layer for DisplayPort. HBR3, introduced with DisplayPort 1.3, remains the newest and fastest bandwidth standard for DisplayPort.

Instead what has changed for DisplayPort 1.4 is the DisplayPort feature set, and in a major way. Surprisingly absent in DisplayPort 1.3 was support for the VESA’s Display Stream Compression standard, which uses lossy (“visually lossless”) encoding to cut down on bandwidth needs, allowing for display setups with fewer lanes or at higher resolutions – such as 8K uncompressed – that can’t be carried within the bandwidth limitations of DisplayPort. Rather the first VESA standard to include DSC was last year’s Embedded DisplayPort 1.4a, and now a year later, DisplayPort is finally adding DSC support with the 1.4 standard.

As we’ve since found out, there are a couple of good reasons for why we haven’t seen DSC in the mainline DisplayPort standard until now, and with 1.4 the VESA has finally addressed those issues to allow DSC to be included in the standard. Of particular interest here is support for Forward Error Correction (FEC), which the VESA considers necessary for DSC on external monitors.

From a signal integrity standpoint, as displays are the highest bandwidth external interface on a typical PC, we’ve known that the VESA has been pushing the envelope on external signaling for quite some time now. This is part of the reason vendors are coalescing around USB Type-C, as it’s easier for vendors to all back a single well-developed solution. In the case of HBR3, this means pushing 32.4Gbps over a 4 lane connection, which is easy in a short run inside a laptop measured in centimeters, but it is a greater challenge with DisplayPort cables extending up to 2 meters. Practically speaking, while a solid DP1.3/HBR3 setup shouldn’t see any errors to begin with, the real world error rate – though quite low – is still higher than would be ideal.

For uncompressed images this isn’t an issue; any corruption is limited to a handful of pixels and quickly corrected in the next refresh. However once DSC is brought into the fold, any errors become a much larger problem. An error in a compressed data chunk will cause decoding to fail or make the decoded result very wrong over a large number of pixels, making the error far more noticeable. Consequently DSC requires a high level of reliability, which eDP with its short runs could provide, while DP’s longer runs could not.

The end result is that the combination of DP 1.4 and the recently released DSC 1.2 specification include Forward Error Correction for DSC. Although Forward Error Correction increases bandwidth requirements slightly, the additional, redundant data it carries allows for errors to be corrected, making DSC suitably reliable over DisplayPort connections. This is the key change to DSC and DisplayPort that finally allows DSC to be deployed to external monitors.

Meanwhile at DP 1.4 is also the first DisplayPort standard to incorporate DSC 1.2, it also becomes the first standard to gain DSC 1.2’s other benefits. Along with the aforementioned error resiliency, DSC 1.2 introduces some new functionality specifically for HDR displays. The compression standard now supports 4:2:0 and 4:2:2 color spaces and has added 14-bit and 16-bit per channel color support to the existing 8/10/12-bpc supported bit depths. In this case the VESA has their eye on HDR with displays over 4K, as while DP 1.3/1.4 offers enough bandwidth for HDR at 4K, this is where it tops out.

Display Bandwidth Requirements (RGB/4:4:4 Chroma)
Resolution Minimum DisplayPort Version
1920x1080@60Hz, 8bpc SDR 1.1
3840x2160@60Hz, 8bpc SDR 1.2
3840x2160@60Hz, 10bpc HDR 1.3
5120x2880@60Hz, 8bpc SDR 1.3
5120x2880@60Hz, 10bpc HDR 1.4 w/DSC
7680x4320@60Hz, 8bpc SDR 1.4 w/DSC
7680x4320@60Hz, 10bpc HDR 1.4 w/DSC

While on the subject of HDR, DP 1.4 also includes some HDR functionality of its own. The other major addition for the 1.4 standard is support for HDR static metadata, specifically the CTA 861.3 standard already used in other products and standards such as HDMI 2.0a. While the full details of what it takes to implement HDR are beyond the scope of this article, HDR static metadata is specifically focused on recorded media, such as Ultra HD Blu-Ray, which use static metadata to pass along the necessary HDR information to displays. This also improves DP/HDMI interoperability, as it allows DP-to-HDMI adapters to pass along that metadata.

The last new feature being introduced with DP 1.4 is updating the audio formats supported by the DisplayPort standard. As with the video portion of the standard, this is focused on functionality since the physical layer (and available bandwidth) haven’t changed. The VESA specifically notes that this latest update adds support for items such as 32 audio channel configurations, and while they don’t say its name, this sounds like the underpinnings for supporting decoded Dolby Atmos audio.

Wrapping things up, like previous DisplayPort specification announcements, we’re expecting some significant lag time between today’s announcement of the DisplayPort 1.4 standard and when this functionality shows up in shipping products, as manufacturers still need to develop controllers implementing the standard. As it stands we still haven’t seen any DisplayPort 1.3 equipment hit the market yet (this despite being introduced in 2014), so it’s likely that DisplayPort 1.4 is some time off. Meanwhile as DSC is always a hot topic in our comment section, so far we haven’t heard anything about plans for monitors to actually implement it. Most likely we won’t see anything until monitors with resolutions over 5K hit the market, as the primary focus of DSC for external monitors is for ultra-high resolution monitors coupled with HDR. It's here where the uncompressed bandwidth requirements become well in excess of what DisplayPort could provide.

Comments Locked


View All Comments

  • HollyDOL - Thursday, March 3, 2016 - link

    Sorry, but no. I hear what I hear. Fail of MP3 to reproduce well is especially noticable with big orchestra recordings, organ, violin, breath instruments and in an extent piano. Use an AXB test and see yourself. Even with good guitar recordings you can hear the artist touching the strings and pressing accords which tends to vanish with MP3. Don't expect to hear any difference with general pop music and such. The better quality of original recording and the better the equipment used, the more significant the difference gets.
  • xenol - Thursday, March 3, 2016 - link

    The thing is, with proper compression, you have to be actively trying to listen for the differences. Some of which are sometimes produced in your head because you come in with bias. Have you listened to a singer and heard the lyrics one way, then the moment you saw what the lyrics are supposed to be, you hear it that way? Someone else I had a discussion about this with said in one of his favorite songs (made some time in the 80s), he always knew there was a subtle grunting, but when people were actively listening to the same song in 24-bit 192KHz audio, they suddenly started "hearing" that grunting, even though it was always there to begin with.

    I also seriously doubt that most people in the world actively pay attention to the music they listen to when they're playing it.
  • iwod - Thursday, March 3, 2016 - link

    It is exactly this reason, we are lossy compressing everything already and then we get another lossy display connection.
  • ddriver - Thursday, March 3, 2016 - link

    The lossy content would have already cut the detail that could potentially be lost. It won't get any worse.
  • skrewler2 - Thursday, March 10, 2016 - link

    that'd be pretty sweet if it worked that way huh?
  • BurntMyBacon - Monday, March 7, 2016 - link

    @ddriver: "I know, such a shock, because it is not like 99.99% of the images, videos and even textures in games aren't using lossy compression ;)"

    Have you ever recompressed a lossy image in a different lossy format? It may not work out as well as you hope. Try encoding a file in MPEG2 and then reencoding it into H.264. You may note that it works better in some scenes than others. These formats aren't even very different.
  • mczak - Wednesday, March 2, 2016 - link

    SuperMHL looks fairly similar to me. Same signaling, albeit using 6 6Gbps lanes instead of 4 8Gbps ones. Nearly same color compression too (using DSC 1.1 instead of 1.2). Maybe the 6Gbps lanes are the reason they get away without using FEC.
    Though I'm not quite sure I buy the argument FEC is needed just due to DSC. HDCP isn't error tolerant neither.
  • mukiex - Wednesday, March 2, 2016 - link

    One thing the MHL consortium didn't really mention is that SuperMHL is *not* actually lossless for the 8K/120hz setups. The first SuperMHL chips on the market are "perceptually lossless" (e.g. lossy) at 4K:
  • jann5s - Wednesday, March 2, 2016 - link

    Just in time for Polaris and Pascal? or just too late?
  • xthetenth - Wednesday, March 2, 2016 - link

    Very doubtful, the hardware's already designed for those two.

Log in

Don't have an account? Sign up now