Talk:DisplayPort

Calculate what Resolution is possible with DSC

How can we calculate, what max. Resolution on (for example) 10bit, 4:4:4 on 8k is possible with DP 2.1 and DSC ? So what maximum compression Ratio can DSC deliver actually?

How far down is it "visually lossless" ? I mean, the more compression, the more visual loss. So would 8K 240Hz be possible with DP2.1 and DSC (10 Bit 4:4:4)? 2A02:1210:8CF9:D100:D9A5:FB86:AC84:9418 (talk) 15:25, 21 February 2024 (UTC)

DSC compresses to some fixed bit rate, so it cannot compress to arbitrarily high ratios. The lowest possible bit rate is 8 bit/px. So with 8 bpc color depth (24 bit/px) this would be 3:1 compression, but if compressing from 10 bpc color (30 bit/px) to 8 bit/px it would be 3.75:1. For calculation simply multiply the data rate of the interface by the compression ratio, then calculate as normal.

 — Glenwing (talk) 08:51, 22 February 2024 (UTC)

and DSC can only use one specific bitrate/pixel or what rates are possible? Because if there is always only one bitrate, then there would also be always the same ratio. So i guess there are different possible bitrate/pixel. So which are they (all)?

And what is the maximum ratio then? Ok, you can't have arbitrarily high ratios, but what ratios can you have? Is 3.75:1 possible? And is it still "visually lossless" on the highest possible ratio?

When you look at the table, then for 10bit native it is 74FPS possible and therefore with a 3.75 ratio the maximum framerate would be 277.5FPS. So 240FPS on 8k 4:4:4 10bit should be possible with DSC? 2A02:1210:940B:1C00:6C8A:30FF:ACF5:B9DF (talk) 13:56, 7 September 2024 (UTC)

The DSC algorithm allows compression down to 6 bits per pixel up to 63.9375 in steps of 1/16 (I mentioned 8 bit/px as the minimum in my previous comment, as this is the lowest VESA recommends to maintain visually lossless quality, but the standard allows down to 6). So if you have 10 bpc (30 bit/px) input and compress down to 8 bit/px, that is 3.75:1. If you choose 7.9375 bit/px instead, it would be a 3.7795:1 ratio.

Theoretically the maximum ratio would be achieved with 16 bpc video (48 bit/px) with compression to 6 bit/px, which is 8:1. But VESA claims it maintains the "visually lossless" quality down to 8 bit/px only and they advertise the "3:1 ratio" heavily, so that's what we use in the table even though the algorithm can go further from a technical perspective. Higher complexity derivatives (VDC-M) can get visually lossless quality down to 6 bit/px, but this hasn't seen wide adoption/marketing yet.

So then for 10 bpc (30 bit/px) input, does it still maintain visually lossless quality down to the same bit rate (8 bit/px, which would not be 3.75:1 ratio), or does it only follow down to the same ratio (3:1, which would be 10 bit/px in this case)? As far as I know this is an open question, I have only seen studies that evaluated it with 8 bpc (24 bit/px) input. VESA never talks about DSC being able to achieve visually lossless encoding at 3.75:1 ratio. My expectation is it is probably still visually lossless down to 8 bit/px simply because the difference between 8 bpc and 10 bpc color depth is so subtle, but right now the article conservatively assumes only 3:1 is possible while maintaining visually lossless quality. Maybe there are newer studies; I haven't checked in a long time. I see an Anandtech article about VDC-M that claims DSC maintains visually lossless quality at 10 bpc -> 8 bit/px (3.75 ratio). I'd like to see the actual study though. https://www.anandtech.com/show/12759/vesa-and-mipi-announce-vdcm11-display-compression-standard-for-mobile

 — Glenwing (talk) 16:09, 7 September 2024 (UTC)

After further checking looks like VESA does claim 10 bpc -> 8 bit/px (3.75:1 ratio) is also visually lossless. I'll go ahead and update the table to account for this.

 — Glenwing (talk) 18:23, 7 September 2024 (UTC)

Technical nature of the article

Over the years, it has been mentioned on numerous occasions, such as here and here, that large portions of this article read like a technical whitepaper or manual. There is a gratuitous use of unexplained jargon and terminology used throughout that only makes sense to an expert or specialist. The first section is "Versions", which goes right into describing features like color space, link layers, Adaptive Sync, etc., which are never explained. Readers with zero knowledge of what these things mean will see this as technical jargon and find it useless. There's plenty more of that scattered throughout the article.

Per WP:TECHNICAL: "An article may disappoint because it is written well above the reading ability of the reader, because it wrongly assumes the reader is familiar with the subject or field..."

As noted in WP:UPFRONT, we need to push the highly technical portions of the article to the bottom and lead with a high-level overview that's easy to understand. A while back, we had an Overview section that followed the lead, which attempted to describe the basics of DisplayPort technology that appealed to a general audience. At some point, this was abolished and partially merged into the lead unnecessarily (which actually violates WP:LEADFOLLOWSBODY). We need to consider reinstating that section to help ease readers into the article. Eventually, I'd like to weed out as much unnecessary technical jargon as possible, but for now, pushing that to the bottom will suffice. If anyone has any thoughts, please weigh in here. I'll give it some time before making any cleanup attempts, thanks. --GoneIn60 (talk) 03:29, 4 March 2024 (UTC)

Forgot to add that during the cleanup phase, interpretations that are only cited to a whitepaper (meaning it provides unsourced analysis of technical specs) will be removed or flagged with a {{citation needed}} tag. Even if correct, these interpretations must be cited to reliable sources that are making that analysis for us. This does two things. First, it removes any doubt that the analysis is not WP:OR. Second, it shows significance that the detail in question qualifies as WP:DUE. --GoneIn60 (talk) 03:37, 4 March 2024 (UTC)

Not approachable

Glenwing, I see that you reverted my edit. The YCbCr article describes YCbCr, Y′CbCr, or Y Pb/Cb Pr/Cr, also written as YCBCR or Y′CBCR as a family of color spaces. Is that description incorrect? Adding to the confusion is that the standards in the "colorspaces" section aren't strictly colorspaces. ITU-R BT.709, for example, is a very broad specification for encoding and signal characteristics that happens to include a color-space definition, for example.

The reference describes the "colorspaces" in this table as "colorimetry specifications". Is that more accurate?

The table isn't too approachable, and I think that also should be fixed. Linking to other wiki articles that explain the concepts being enumerated in the table would be helpful. -- Mikeblas (talk) 02:57, 31 May 2024 (UTC)

Primarily it didn't make sense to have two table sections both called "Color space support". Otherwise I might have just started a discussion here instead. "Color space" is a somewhat nebulous term which is used by different people to mean different things. My view is that YCbCr (YPbPr) is not a color space, it is a color model, like RGB. The page for Color space says:

Since "color space" identifies a particular combination of the color model and the mapping function, the word is often used informally to identify a color model. However, even though identifying a color space automatically identifies the associated color model, this usage is incorrect in a strict sense. For example, although several specific color spaces are based on the RGB color model, there is no such thing as the singular RGB color space.

I tend to agree with this, and the same with respect to YCbCr. I think that referring to YCbCr as a "color space" is incorrect, just as saying "RGB" is a color space is also incorrect. But other people may disagree, like whoever wrote the YCbCr article. But wikipedia reflects whatever is in its sources anyway; garbage in, garbage out. If misuse of a term is widespread outside WP, then it will appear here too. But at least in the context of monitors and video interfaces, "color space" generally refers to actual color spaces like sRGB. Whether you're transmitting in RGB or YCbCr is your pixel format (more correct I think) or color format.

ITU-R BT.709 doesn't give a specific name to just the color space that it defines, so there's no other way to refer to it. But I think it's fairly self explanatory that "ITU-R BT.709 color space" means "the color space defined in the ITU-R BT.709 standard", I don't think there's much risk of someone coming away with another idea of what was meant (I'm not really sure what other way it could be interpreted, honestly). It's in the same way that when someone says "Ultra HD resolution", even if someone was actually familiar with the Ultra HD specification (it defines other parameters like frame rate and video interface/HDMI requirements, not just resolution) it would be apparent that the person meant "the resolution used by the Ultra HD standard" which is 3840×2160. The standard defines other things but I don't think it will lead to any confusion about what is meant by "Ultra HD resolution". Same for "ITU-R BT.709 color space".

Not opposed to some wikilinking in the table, it can be explored. I should also point out we should be thoughtful about what links where; for example linking the words "color space" to lead specifically to YCbCr (rather than Color space) is a somewhat strange (perhaps WP:SUBMARINE) link.  — Glenwing (talk) 03:17, 31 May 2024 (UTC)

Not sure how to respond, since you think there's "no other way to refer to it" and "don't think there's much risk". I think you're more familiar with the material than most readers, and that familiarity prevents you from seeing the problems here. -- Mikeblas (talk) 15:30, 31 May 2024 (UTC)

You could respond with an alternative way of referring to the color space defined in the ITU-R BT.709 standard other than "the ITU-R BT.709 color space", which would show that my assertion was wrong. Or an explanation of how referring to "the BT.709 color space" could lead to confusion on the basis that BT.709 also contains additional things besides a color space. Above I was expressing my views as they currently stand. I'm open to new considerations, but it would require a convincing argument to be provided.  — Glenwing (talk) 15:41, 31 May 2024 (UTC)

Source for "proprietary" claim

I cannot find any information elsewhere on the internet stating DisplayPort past 1.1a is under NDA, and no source was provided. If the NDA claim is true, a source should be there, if not, the NDA claim and the word "proprietary" should be removed. MyceliaLinn (talk) 03:27, 4 February 2025 (UTC)

https://vesa.org/about-displayport/  — Glenwing (talk) 08:50, 4 February 2025 (UTC)

Proposed summary for technical prose

I've been using Google's Gemini 2.5 Pro Experimental large language model to create summaries for the most popular articles with {{Technical}} templates. This article, DisplayPort, has such a template above the entire article. Here is the paragraph summary at grade 5 reading level which Gemini 2.5 Pro suggested:

DisplayPort is a type of cord and plug used to connect computers to screens like monitors or TVs. It sends both the picture and the sound together through one cable. It's a newer way to connect screens, replacing older plugs like VGA and DVI. DisplayPort helps show very clear pictures and can sometimes carry other computer information too. With a special extra piece called an adapter, some DisplayPort plugs can also work with different cords like HDMI. You can even connect more than one screen to a computer using just one DisplayPort plug sometimes. The plugs come in a regular size and a smaller size called Mini DisplayPort.

While I have read and may have made some modifications to that summary, I am not going to add it to the article because I want other editors to review, revise if appropriate, and add it instead. This is an experiment with a few dozen articles initially to see how these suggestions are received, and after a week or two, I will decide how to proceed. Thank you for your consideration. Cramulator (talk) 12:19, 2 April 2025 (UTC)

I am retracting this and the other LLM-generated suggestions due to clear negative consensus at the Village Pump. I will be posting a thorough postmortem report in mid-April to the source code release page. Thanks to all who commented on the suggestions both negatively and positively, and especially to those editors who have manually addressed the overly technical cleanup issue on six, so far, of the 68 articles where suggestions were posted. Cramulator (talk) 22:11, 4 April 2025 (UTC)

Quite apart from any policy issues, the generated text seems very clunky and uses strange terminology. If I read it I would immediately assume it was AI guff, and inherently untrustworthy. --Ef80 (talk) 18:19, 20 July 2025 (UTC)

@Cramulator: This is one of the worst things I have ever read. It is not only unhelpful but directly and severely problematic on many levels. I see that this effort has already been met with criticism, but I must add my opinion that this is one of the most horrible ideas I have ever seen used on Wikipedia. It's not even worth trying to list out all the reasons this is a bad idea, but one of the main reasons is that you have absolutely no idea what you're talking about. —danhash (talk) 14:20, 21 July 2025 (UTC)

Incorrect citation in the Licencing section

I removed a citation and added the «cn» tag, as the link was to the VESA press archive index.
If people cite press releases, link to the actual release, not an index of releases, forcing the reader to hunt down the relevant article.
It might be on index page 68 when the a user want to see it a few years later. Solbu (talk) 08:06, 13 May 2026 (UTC)