Speedway

Talk:DisplayPort

Inaccurate feature comparison with HDMI

Hey there, I just stumbled on this in the article. The article states:

HDMI can accept longer maximum cable length than DisplayPort (30 meters vs 15 meters).

While this seems fine at first glance, the comparison is inaccurate or "not fair". If we assume that with "maximum cable length" we are talking about the specifications of each, we have the following:

Now the question is should this point be removed entirely or clarified to include this disparity? Mihawk90 (talk) 11:19, 2 July 2023 (UTC)[reply]

Yes, this bullet point should be removed. As you pointed out, neither standard specifies a "maximum length" nor would it make any sense to do so, as there is no such fixed value.  — Glenwing (talk) 16:15, 2 July 2023 (UTC)[reply]
Done, thank you for the reply. Mihawk90 (talk) 10:25, 3 July 2023 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

Questionable details about the physical layer

In the table on the right there under “Electrical” are some voltages and currents specified with unclear meaning. DisplayPort doesn’t use 3.3 V for its signals. It uses differential signaling where the exact voltages aren’t specified, but the voltages (both the common mode bias and the differential voltage) should always stay way below 3.3 V. The DisplayPort connector has one supply pin though to power e. g. a DP to HDMI adapter. This pin supplies up to 0.5 A at 3.3 V. So this entry in the table could be renamed e. g. to supply voltage to make it correct. Additionally it is unclear to me, what the “Max. voltage” and “Max. current” entries mean. The latter could mean the supply current of the aforementioned pin, but then this should probably be stated explicitly. I don’t know of any voltage value that should reach 16 V, so this entry makes no sense to me. It should either be clarified or removed if there is no such voltage.

Another problem in this article is that at multiple places it talks about DP to HDMI adapters having to convert the signals from 3.3 V to 5 V. This is wrong as neither DisplayPort uses logic levels of 3.3 V (see above) nor does HDMI use 5 V logic levels. They both use differential signaling where the exact differential voltages aren’t specified, but are both way below 1 V. --Lukas.fink1 (talk) 21:26, 1 March 2024 (UTC)[reply]

Hi, thanks for the observations. Will review later today. I think DP specifies abs max 2.0V for Vcm and around 1.3V for Vpp, maybe this is where the 3.3V came from? (EDIT: Given the voltage listing as 3.3 V and max current of 0.5 A, this appears likely to be referring to DP_PWR) For the others, 16V etc. I have no guesses. This will need some cleanup. Thanks again for your notes.  — Glenwing (talk) 22:20, 1 March 2024 (UTC)[reply]
I've removed the electrical specifications from the main table since the categories themselves were quite vague and not of much value. I've also rewritten the sentence about dual-mode adapters.  — Glenwing (talk) 05:41, 2 March 2024 (UTC)[reply]
I notice also, many datasheets for DP dual mode level shifting ICs mention 3.3V (from DP_PWR) to 5V (for HDMI DDC) conversion, it seems likely this is the origin of that sentence, and something got lost in translation along the way...  — Glenwing (talk) 06:07, 2 March 2024 (UTC)[reply]
  • Just a comment here that this is another example of the article getting increasingly technical going beyond the scope of an encyclopedia. If the only source out there talking about this "limitation" is a whitepaper resource, such as the VESA Interoperability Guideline, then it probably doesn't have WP:DUE weight for inclusion on Wikipedia. The significance (and translation of what it means) really needs to come from a secondary source. This article is due for an overhaul, which I plan to address in a new thread. --GoneIn60 (talk) 03:28, 4 March 2024 (UTC)[reply]

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)[reply]

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)[reply]


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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

https://vesa.org/about-displayport/  — Glenwing (talk) 08:50, 4 February 2025 (UTC)[reply]
Quelle: https://en.wikipedia.org/wiki/Talk:DisplayPort