Talk:HDMI

Does HDMI 2.1 indeed support for 4k 144hz?

The article claims, without providing any source or references, that HDMI 2.1 supports 4k 144hz. The problem is that official hdmi.org website has no such information, it says that HDMI 2.1 supports maximum 120hz at 4k resolution. After a lot of googling and reading tech websites, I think that everyone just *assumed* that HDMI 2.1 will support 4k@144hz solely because it has enough bandwidth for that. But developers of hdmi 2.1 specifications never confirmed that. And since the only HDMI 2.1 monitors currently on the market are TVs with screen refresh rate limited to 120hz, there is no way to verify if HDMI 2.1 can handle anything above it or not. It's also unclear if those few 4k@144hz PC monitors to be released next year (Eve, Acer, ViewSonic, Philips) indeed support uncompressed output through HDMI 2.1, or it will be limited to 4k@120hz and 144hz will be possible only through DSC? Again, after reading all the news reports I think that tech websites *assumed* that these monitors will support uncompressed 4k@144hz through HDMI 2.1 just because it has enough bandwidth for that. But these assumptions were never confirmed by manufacturers of the monitors. Can anybody please further clarify this? 46.172.22.218 (talk) 20:45, 30 November 2020 (UTC)

There is some confusion due to the word "support", which has a special meaning in the HDMI Specification compared to normal casual usage. Running at 4K 144 Hz is fully within the guidelines defined by the HDMI Specification. Nothing about 4K 144 Hz is out of spec and there is no restriction on running at 4K 144 Hz. It is therefore possible to run at 4K 144 Hz using the HDMI interface. If that's what you mean by "support" then yes, HDMI 2.1 supports 4K 144 Hz. HDMI allows any arbitrary video format, as long as it is within the restrictions of the HDMI Specification, such as the maximum aggregate bit rate of 48 Gbit/s. This is established in section 6 of the HDMI specification, the very first sentence of the video section of the HDMI Specification. HDMI does not need some kind of special "support" for every particular format in order to run it. As long as it is within the bandwidth limit, it is allowed, so it is just a matter of math. 4K 144 Hz is therefore possible over HDMI.

There is a list of "Supported Formats" in the HDMI Specification. These are common formats that the HDMI Specification explicitly defines all the timing parameters for (via the CTA-861 standard). The purpose of these formats is explained in Section 6; they are to ensure interoperability for common formats, so that if two device supports 1080p 60 Hz for example, they will support the exact same timings and therefore are guaranteed to work with each other without any unexpected out-of-range errors or anything like that. In the HDMI Specification, "Supported Formats" refer to formats with explicitly defined timings. In no way is the HDMI Specification restricted to only transmitting "Supported Formats"; as explained in Section 6, any arbitrary format is allowed. The Supported Formats list is only to aide interoperability between products with these common TV formats. People who don't understand the Specification will often point to this table saying "look, XYZ format isn't in the supported formats table, therefore HDMI doesn't support it!" without understanding that "support" has a non-normal meaning in the HDMI Specification. So it is technically true that HDMI does not "support" these formats, but as mentioned, the HDMI Specification has a special meaning for the term "supporting" a format, which does not mean what people usually mean.

If you examine the list you will also note that 1080p 144 Hz is also not a Supported Format. 2560 × 1440 is also not a Supported Format, neither is 1366 × 768. Yet clearly there are many monitors on the market that run at these formats over HDMI. Likewise, is 4K 144 Hz a Supported Format? No. But does HDMI 2.1 support running at 4K 144 Hz? Yes. Don't be confused by tables of "Supported Formats"; HDMI is not restricted to only transmitting these formats. Any format within the bandwidth limit is allowed. This is stated by the HDMI Specification in Section 6 and is the reason that 1080p 144 Hz monitors and 1440p monitors with HDMI exist.

Please also note that this only deals with what is permitted by the HDMI Specification. It is possible that products may only support up to 4K 120 Hz. This is because products may have any arbitrary limitations. For example, some 1080p 144 Hz monitors are limited to 60 Hz over HDMI, some are limited to 120 Hz over HDMI, some support 144 Hz over HDMI. So it is entirely possible that upcoming monitors might only support up to 4K 120 Hz over HDMI. This does not prove or disprove anything about what the HDMI Specification allows, only what that product is capable of, because product capabilities are arbitrary. The HDMI Specifications only describes what products are allowed to do, and how to do those things. So you cannot determine what the HDMI Specification supports or does not support by inferring from what products on the market are limited to. GlenwingKyros (talk) 21:37, 30 November 2020 (UTC)

I suppose. But also many devices will resample for some frequencies. The 1366x768 display I know of commonly accept 720p, and display it properly. (Or close enough.) But yes, the article should make it clear that many different formats can go through HDMI. Gah4 (talk) 18:13, 14 June 2022 (UTC)

DSC (all B formats) is NOT lossless!

I wanna add that info in the article, the non-RS is a Youtube video. This was an important info that was not here. I think it is important that in by itself DSC is lossy, even though it should use lossless YCgCo-R! https://www.avsforum.com/threads/hdmi-2-1-chipset-bug-in-dennon-marantz-and-yamaha-receivers.3171161/post-60213663 109.252.90.66 (talk) 11:56, 25 February 2021 (UTC)

“DSC (all B formats) is NOT lossless!” The article never claims that it is. It sounds like you're having a reaction to something that isn't there.

“I wanna add that info in the article, the non-RS is a Youtube video.” I can't understand what you're saying. What is “the non-RS”? What YouTube video? You appear to have linked a forum thread. But DSC being a lossy form of compression isn't some kind of secret, it's on the VESA FAQ page.

“I think it is important that in by itself DSC is lossy, even though it should use lossless YCgCo-R!” Such technical details don't really belong here, this page is about HDMI, not for informing people about DSC. If people want to know more about DSC, they can click the Wikilink, that's what it's there for. GlenwingKyros (talk) 18:08, 25 February 2021 (UTC)

HDMI gets bits from a source to destination. There is no loss in that. If a lossy compression was used, such as for DVD, that happens when creating the DVD. The DVD player creates a digital signal and send it into the HDMI cable. The same signal arrives at the other end and is (usually) displayed. Gah4 (talk) 22:14, 25 February 2021 (UTC)

He's talking about Display Stream Compression (DSC), which is an optional lossy compression (though very low compression ratio) used during transmission over HDMI. GlenwingKyros (talk) 22:53, 25 February 2021 (UTC)

Strange, I though it is obvious that on the forum the video that is used is an embedded Youtube video. "bits from a source to destination. There is no loss in that", common mistake. Almost all video on the planet (all on DVDs, on Blu-rays, on Youtube) is 4:2:0. It will be only lossless if you will actually send the 4:2:0 as in the stream (passthrough) to the 4:2:0 HDMI link. After quantisation, when float is converted to fixed RGB on even YCbCr 4:4:4 8 bit value (or 10, or 12) it is not the same anymore. Just saying. (Though I am only sure about RGB.) 109.252.90.66 (talk) 21:21, 26 February 2021 (UTC)

I think I must have scrolled when the page loaded, I didn't notice it linked to a specific post. GlenwingKyros (talk) 21:40, 26 February 2021 (UTC)

I added that it is lossy. I hope someday we will have like JPEG XL in it lossless mode instead of dumb lossy compression. 109.252.174.242 (talk) 12:19, 25 July 2022 (UTC)

In my edit note I stated this is already mentioned in the article; it actually is not, as I have realized the provided wikilink to Display Stream Compression actually submarines over to the DisplayPort page, not to another section here on the HDMI page. Nonetheless, I don't really see the merit of adding such a short statement like was done in your edit; it doesn't really fit to have a random "it's lossy by the way" when there is otherwise no description of what DSC is at all. If someone wants to know about it, they can click the wikilink where its lossy-ness is described in great detail. If you feel that isn't enough, then we should copy more of that information in this article to get a more expanded description than "it is lossy".  — Glenwing (talk) 16:55, 25 July 2022 (UTC)

"should copy more of that information in this article to get a more expanded description" Yes, please do!! We have some very strange things here, like linux driver of nvidia not doing it: https://github.com/NVIDIA/open-gpu-kernel-modules/discussions/238 and a lot of all people arguing for and against it: https://www.google.com/search?q=dsc+is+lossy 2A00:1370:8184:2478:3C97:DCB5:F08F:1406 (talk) 11:48, 26 July 2022 (UTC)

HDMI to Composite converters

I have the Amazon Fire TV Stick, and it only supports 16:9. As a result, my current HDMI to Composite converter stretches the image vertically on one of those 4:3 television sets I have.

I’m trying to find an HDMI to Composite converter that letter boxes the 16:9 aspect ratio image to a 4:3 aspect ratio output. At one point, there existed a Hall Research HD2CV, which does this method, but now, only one unit is on eBay, and it is now expensive there, and the entire model of that is out of stock on Amazon.

I’ve also looked at this Yotocap brand, and this BTS/Wiistar brand. The former model says in the description about the image switching function solving the ratio deformation when 16:9 is converted to 4:3, while the latter says in the description that the output is in 4:3 and any non-4:3 screen has the picture cut off.

Has anyone found out what these statements mean? Are there any other models that properly covert 16:9 to 4:3 by letter boxing? I’d truly like to know; thank you in advance! 2601:4C4:4000:A8C0:CC4C:955A:5E62:A780 (talk) 05:02, 14 June 2022 (UTC)

Talk pages are supposed to be for improvement of the article. I tend to give a benefit of the doubt, though, and won't remove your question. Do you believe the article should mention this? As far as I know, HDMI to VGA is commonly available, and includes the DAC inside. As well as I know, it is up to the display device to figure out how to display different aspect ratios. There is often a selector that lets one change it. It seems that in the case of ATSC, that information is not supplied, and so the user has to select it. (That might be worth adding to the article.) Most that I know will put black space around the display, to fit without cutting off the image. Gah4 (talk) 18:19, 14 June 2022 (UTC)

New maximum refresh frequency table

This is regarding the new section added by User:Intg in this edit: [1] which added a new table showing maximum refresh frequencies. I made the following changes:

• Removed 6K resolution, as the title of the section is "Common resolutions" and this is not a common resolution.
• Changed the colors to be less saturated to make it easier to read
• Removed the bottom row (which repeats the header), as the table is not long enough for this to really be necessary anymore
• Added some paragraphs explaining that this table does not show absolute maximum possible.

In any case, I have also commented out the section for the time being. The main reason being that the numbers are not actually correct, as the cited source does not accurately account for everything in FRL transmission. It is missing the following considerations:

• Overhead from FEC, which is mandatory in FRL transmission
• FRL packetization overhead
• RC compression, which is also always used in FRL and changes the size of the blanking intervals

Currently there are not any online calculators that I'm aware of that take these factors into consideration correctly. This is one of the main reasons that the current tables in the article do not list exact numbers for the maximums. The other issue is that listing exact numbers will tend to mislead people into thinking that these are the absolute maximum limits, since not many readers will understand blanking intervals and custom timings that vendors may use if they require slightly pixels more than standardized timings can provide.

I've added a paragraph to explain this which will slightly alleviate the problem, but it is still likely many readers will look at the table without reading the paragraphs above or the footnotes below, which is why I am hesitant to use a table with exact maximum limits listed. Still, the standard tables are getting quite long so I think it's good to explore this newer format, as long as the calculations can be corrected.

By the way, the same problem exists with the similar table added on the DisplayPort page. Again, the cited source calculator does not account for FEC overhead or MST packetization which are both required at all times in UHBR transmission.  — Glenwing (talk) 02:41, 24 June 2022 (UTC)

My notes/questions:

1. I am (obviously) of the opinion that the tables I added did more good than harm in their current form and I would have preferred if you improved it or asked/requested/demanded improvements/corrections instead of removing them. Lets ignore that for now.
2. "The main reason being that the numbers are not actually correct, as the cited source does not accurately account for everything in FRL transmission. It is missing the following considerations[...] By the way, the same problem exists with the similar table added on the DisplayPort page. Again, the cited source calculator does not account for FEC overhead or MST packetization which are both required at all times in UHBR transmission." - thanks for your educated input. I am not expert on this. Do you know a source for the "mathematics" of the 3 bullet points you listed? Maybe the calculator can be improved.
3. "Added some paragraphs explaining that this table does not show absolute maximum possible." Well, they showed the maximum possible according the CVT-R2 specification (except the 3 bullet points the calculator does not account for), or is there a misunderstanding on my side? This does not imply that higher freq. are impossible when using another or a "custom" spec.
4. Both the DP and the HDMI list numbers for "Data rate required". How are these numbers calculated? If there is no Src, do we need to delete these tables too? If there is a Src, can we use it to improve the numbers in the max freq. table? Intg (talk) 08:15, 24 June 2022 (UTC)

1. Yes, I apologize for my rudeness. I didn't fix the numbers myself because then they would no longer agree with the cited source, and I don't have an alternate source for a calculator at the moment. As it happens, I'm working on my own calculator right now due to the lack of a proper one on the internet, but it's not finished at the moment (and I wouldn't be able to self reference anyway). I did make some improvements to your table but I decided to hide it for now because I think it will take a little bit of time to make it completely accurate and I want to avoid misinformation in the mean time while it's being worked on.
2. Fixing the calculation for DisplayPort is fairly straightforward. Right now, the maximum data rate is listed as 77.57 in the calculator, this is to account for 128b/132b line code (80 Gbit/s × 128/132 = 77.57). However, this also needs to be multiplied by 383/384 and then by 16384/16385 for packetization, so the real maximum data rate is around 77.37 Gbit/s. For HDMI it is much more complicated though. With similar corrections, the real maximum data rate is around 41.92 Gbit/s after FEC and FRL packetization, but RC compression also reduces the data rate of the format based on the size of the blanking interval, and when using CVT-RB timing the blanking interval depends on the refresh rate, which complicates things quite a bit in this case. Like I said, I'm working on my own calculator, but I'm not sure what else I can suggest otherwise. I can do manual calculations to fill in the table, but there would be no source for these numbers.
3. Given that the title of the section is "Maximum refresh frequency" and it has a table of refresh frequencies, the natural assumption for most people would be to interpret that as an absolute limit. While it does briefly mention "with CVT-R2 timings", it doesn't explain the significance of that statement, and that's something that won't mean much to people without any explanation. So, I added an explanation to translate the significance of that statement to people who wouldn't otherwise know what that really means, so that issue I think is solved at least as much as we can. Still, many people will not read the paragraphs surrounding the table so there will be some inevitable misinterpretation I think, but there's only so much we can do I guess.
4. That is a straightforward calculation as given in the footnotes of the original table. Source is not required for ordinary mathematical calculations, and in this case the formula is provided, and all of the input numbers are provided (resolution, bpc, and frame rate) so there is no need for a source that actually says that when you plug the given numbers into the given formula, you get this result. The only part of the formula not given is the CVT-R2 timing formula, but that one is wikilinked and I think the source (with formula contained in it) is referenced over on that page, so everything is covered. For calculations like the maximum frequency on the other hand, a source would be needed, because the formula and input variables that result in that number aren't given already on the page.  — Glenwing (talk) 05:35, 25 June 2022 (UTC)

(EDIT: After double-checking, I've made some corrections to the numbers I gave for DisplayPort. For UHBR modes, FEC is already included in the line code overhead (unlike HBR modes) and the MST packetization overhead is also different than it was in HBR modes. The total overhead turns out to be only slightly different than the numbers used by the calculator, so the numbers in the DisplayPort table should be almost the same.)  — Glenwing (talk) 22:35, 29 June 2022 (UTC)

Sometimes there is close enough, commonly noted as Sigfigs. Even more, note that it isn't necessary that WP articles use the exact numbers, just close enough. Within a few percent is likely close enough. Those actually building circuits will need the exact numbers, and know where to get them. There might even be actual tolerance in the standards for values. I suspect, then, that 77Gb/s or even the line speed of 80Gb/s is close enough. Note that line speed is commonly used, for example in 10 or 100 Mb or gigabit Ethernet. One doesn't subtract for preamble, headers, or inter-frame gaps, which reduce the actual throughput. More specifically, it depends on what you mean by data. Gah4 (talk) 00:46, 1 July 2022 (UTC)

I understand, and I wasn't trying to quibble over some decimal places; for DisplayPort I agree the numbers are close enough, the difference between 77.57 and 77.37 is trivial. I had originally thought the overhead was around 7.5% compared to the 3% used by the calculator, which I thought would be worth correcting, but I was wrong about the numbers on that one, so I'm not really worried about DP anymore (although it could use some touch-ups to match the changes I made to the HDMI table—I can do this over the weekend).

For HDMI, the main component of error would normally be the RC compression, which greatly reduces the size of the blanking intervals. For example at 4K 10 bpc with blanking based on CTA-861, the true maximum on 40G FRL would be around 134 Hz compared to 119 Hz with the calculation used here. That's not insignificant I think, and it's also the difference between supporting 120 Hz and not supporting 120 Hz with those settings, which I think is important to get right. I agree people probably aren't too interested in exact numbers, but what most people are interested in is whether it can or can't support these certain "thresholds" of common frequencies; that's why the current tables are formatted the way they are.

However, after continuing to look into this, I realize it really doesn't make too much difference here, because RC compression only operates on the horizontal blanking interval. It makes a big difference with CTA timings as I noted, because they have a large horizontal blanking and smaller vertical blanking, but actually CVT-RB is the opposite, with a very small horizontal blanking and large vertical blanking, so the effect of RC is actually not very much here. So I apologize for the much ado about nothing. But I do still think it's important to have some explanation that these are not absolute maximums, so I think the changes I made were important, even holding aside the calculations.  — Glenwing (talk) 04:10, 1 July 2022 (UTC)

1.3/1.4 support of 1920 × 1080 at 120 Hz

Both chapters indicate that they added support for 1920 × 1080 at 120 Hz. Which one is it? — Preceding unsigned comment added by Anttir717 (talk • contribs) 09:18, 24 July 2022 (UTC)

1920 × 1080 120 Hz is transmittable from HDMI version 1.3 and higher, but it is not a “Supported Format” in this version. Support was added for it in version 1.4 (specifically, the 1920 × 1080 120 Hz timings defined in CTA-861-E were added to the Supported Formats list). "Supported Format" has a special defined meaning in HDMI which does not come across at all in the article (basically it means formats which have timings fully defined in the standard. Being a "Supported Format" is not required in order to transmit however, which is how most people use the word "support"). From a technical standpoint the article is correct as-is, but the wording does need improvement.  — Glenwing (talk) 10:31, 24 July 2022 (UTC)

Move Display Stream Compression section to separate article (partial verbatim copy of same section in DisplayPort article)

As HDMI#Display_Stream_Compression and DisplayPort#Display_Stream_Compression are verbatim copies, but the latter contains additional info about newer HDMI (!) revisions, we already witness

1. Avoidable Duplication
2. Divergence

in these two articles.

Since Display_Stream_Compression already exists, we should just remove all but the first sentence from both HDMI's and DP's DSC sections and put the DP's content on that page. Marcusmueller ettus (talk) 11:42, 3 January 2023 (UTC)

Agreed. I have felt this should be in its own article for a while, but I've never created a new page before.  — Glenwing (talk) 16:05, 3 January 2023 (UTC)

Done the move. Would be great if you could do a quick review of the new article. Marcusmueller ettus (talk) 13:51, 8 January 2023 (UTC)

GA Reassessment

HDMI

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Article (edit | visual edit | history) · Article talk (edit | history) · Watch • Watch article reassessment page • Most recent review

Result: Delisted. More than a week, little movement towards addressing issues. Iazyges Consermonor Opus meum 17:44, 15 October 2023 (UTC)

Per multiple maintenance tags and other issues. Use of lists and tables may be excessive in some areas. The versions section resembles a WP:CHANGELOG at certain points. The applications section needs to be reorganized or rewritten. Thebiguglyalien (talk) 07:34, 24 September 2023 (UTC)

• The Versions section is probably the best-written section on versions of a major technical spec I have ever seen. What is the particular criticism? --{{u|Mark viking}} {Talk} 10:41, 24 September 2023 (UTC)

  Several of the paragraphs are just a literal changelog update, and there are excessive lists and excessive tables. If I were a GA reviewer for this, I would recommend a few paragraphs that briefly describe the main points rather than an extensive list of every version and feature, just like you'd write for any other subject. Thebiguglyalien (talk) 16:01, 24 September 2023 (UTC)

  Thanks. I understand your point of view now, but I do not share it. What you may see as mere temporal snapshots of an alleged single spec, I see as a family of specifications, all under the HDMI umbrella, with a rich and occasionally checkered history. Along with the physical specs, the Versions section + tables represent the heart of the article, the answer to the question, what is HDMI? If I were a GA reviewer, I would be fairly happy with this part of the article. {{u|Mark viking}} {Talk} 20:07, 24 September 2023 (UTC)

Recommendation: Major revisions needed to retain GA status. The topic HDMI is certainly an important one. However, it appears that the article has grown somewhat haphazardly since it first passed the Good Article criteria in 2008 without paying enough attention to being useful to the non-technical reader. There are also some issues that were identified when it failed a Feature Article nomination in 2009 which have not been addressed. Further It has a few issues that editors have identified in the current version which have not been addressed such as information about FRL, Personal computers and one citation needed. There are also many statements which are not sourced, or use low-reputation sources.
A little history. The Good Article review was on 27 June 2008 here. At that time it was 51,666 bytes, ~3500 words, and 91 references The article was fairly tight and passed without any comments.
It was nominated as a Feature Article which was declined 28 November 2009, this version. At that time it was 76,238 bytes, ~4500 words and 141 references.
A key comment at that time was “The main problem is that it is overfull of facts and doesn't explain (to the general reader) how and why…I think the article needs a fairly radical overhaul to make it an engaging read and focus more on getting the point across rather than bare facts.“
The current version as of October 2nd 2023 is 180,638 bytes, ~12,000 words with 225 references. It appears that nothing has been done to remedy the issue identified in 2009. There is a clear issue with too much detail WP:NOTEVERYTHING, WP:NOTGUIDE could also be relevant, and too much detail about updates WP:NOTCHANGELOG. As noted in the earlier FA review, it fails the GA Well-written criteria as it is too technical and needs at least an introduction for a non-technical audience WP:TECHNICAL. There are many cases it seems to go into unnecessary detail WP:SS.
What appears to have happened is that more sections have been added, with no significant rethinking of this as an encyclopedic article. Many sections read as a depository of technical information which should be elsewhere. Examples of this include HDMI#Cables. There are also many sections which have lengthy descriptions which are poorly sourced and whose utility is unclear. For instance in the Blue Ray section the paragraph that starts with “Blu-ray permits” makes many statements without citations whose relevance is unclear.
When I do a quick Google Scholar search I find many refereed articles. However, I do not find many refereed high reputation sources in this article. For certain Press Releases and Blogs are not high reputation and should not be used. A non-exhaustive list of marginal sources is:

• Press Releases: 6, 26, 82, 152, 196
• Trade Magazines: 7, 14
• Blogs or similar: 25, 26, 27
• Manufacturers articles: 8

A few specifics:

The paragraph in History that starts “According to In-Stat” reads like an advertisement, as does the next paragraph. The whole section needs to be edited so it is WP:NPOV

In Compatibility with DVI the paragraph “From a user’s perspective” appears to be a digression. Either condense or make the relevance clearer.

As mentioned above, it is unclear what the relevance of all the technical information in Cables is.

The Extenders section appears to be a digression. Either condense, remove or make the relevance clearer.

The Version section can be compressed, more neutral please. I suspect everything except the latest should only be 2-3 sentences. Details that are in the Main specifications tables should not be duplicated.

The Personal computers section has a lot of old (obsolete) information. I don’t expect that many 2005 vintage computers are still running, or even 2012.

The Relationship with DisplayPort seems to wander without a clear focus. Similarly the MHL section

The two Podcasts from 2009 in the External links are very old, I suggest replacing with something newer.

Ldm1954 (talk) 12:49, 1 October 2023 (UTC)

Recommendation (revised): Remove GA status. Editors are continuing to make minor changes, ignoring the comments here. Ldm1954 (talk) 10:35, 14 October 2023 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Footnote 3 does not support " pixel-repetition scheme"

First timer, be gentle.

https://en.wikipedia.org/wiki/Hdmi#Specifications

I could not find support for the proposition (Specifically the final sentence about 480i Pixel repetition.):

An HDMI connection can either be single-link (type A/C/D) or dual-link (type B) and can have a video pixel rate of 25 MHz to 340 MHz (for a single-link connection) or 25 MHz to 680 MHz (for a dual-link connection). Video formats with rates below 25 MHz (e.g., 13.5 MHz for 480i/NTSC) are transmitted using a pixel-repetition scheme..

Which cites to Footnote 3

"HDMI FAQ". HDMI.org. Archived from the original on February 22, 2018. Retrieved July 9, 2007.

I pulled up the relevant Archive.org (2007-06-27 is what would have been active at the above cited date)link: https://web.archive.org/web/20070627140331/http://www.hdmi.org:80/learningcenter/faq.aspx

And searched for "pixel" and "480" as well as trying to scan the headlines.

I don't think the source document has changed. I wonder if the wikipedia footnote got erroded over time with the paragraph being edited. I don't know how to do the equivalent of "git blame" over the article history; so I've reached a bit of a wall.

Looking at the big HDMI standards document from Footnote 5 https://web.archive.org/web/20070627140331/http://www.hdmi.org:80/learningcenter/faq.aspx

I think we do see support for the proposition:

Video formats with TMDS rates below 25MHz (e.g. 13.5MHz for 480i/NTSC) can be transmitted using a pixel-repetition scheme.

Proposed action: Have the section in question change it's footnote from 3 to 5. — Preceding unsigned comment added by AThomas203 (talk • contribs) 17:48, 13 February 2024 (UTC)

 Done. I concur with your assessment, and made relevant changes. TheFeds 22:53, 14 February 2024 (UTC)

Power carrying capacity

Maybe add to the tabels their power carrying capacity. 5 volts at 300 mA for 1.5 watts. --Wikideas1 (talk) 07:51, 20 February 2024 (UTC)

Short description and lead

Currently the WP:short description for this article says Proprietary interface for transmitting digital audio and video data. It is convoluted and long, does not fit the search suggestion list on desktop Vector 2022 (which is ass btw). Is ”proprietary” really the first thing HDMI needs to be described as? Must it be mentioned at all? It takes up a lot of screen real estate for what I perceive as an in-depth piece of info, especially since there aren’t really that many video interfaces, and proprietary isn’t one of the characteristics people use to distinguish them. I looked into a few other articles on the same subject to see what they had, and this is it:

• Composite video – Analog vido signal format
• DVI – Standard for transmitting digital video to a display
• Displayport – Digital display interface

There is no real consistency, but they are more or less short and concise. Can we come up with something similar for HDMI?
I definitely think that ”Proprietary” should go, it is way too detailed, and something one should have to click into the article to learn.
Is ”data” really necessary? Isn’t DVI data too? When I think of it, VGA and other analogue formats transmit data too, it’s just… analogue. The word ”data” suggests a file format is transmitted or some sort of number output, not actual video and/or audio.
Here are shorter ones:

• interface for transmitting digital audio and video data
• interface for transmitting digital audio and video
• interface for digital audio and video

What do you think? Do you have another suggestion?

———

Likewise I think the lead section could be rewritten, the first paragraph simplified and compressed to accommodate the most important aspects for those who preview an article by hovering a hyperlink.

1. Is ”proprietary” really the first thing that must be mentioned? Can it be moved down a bit, so it is beyond hovering distance?
2. And is ”data” an adequate way to describe it? Again, ”data” suggests it’s a file format transmitter or some sort of number output, not actual video and/or audio, which could be confusing, especially for less technical readers.
3. It can transmit some other data though, most notably device information, controlling and ethernet protocol. Should that be mentioned in the first paragraph, and if yes, should those examples be put there as well?
4. The video signal can be compressed as well, not just audio. Colour limitations in YCbCr is a form of compression, and DCS is definitely a compression in the way most people think.
5. ”Display controller” is a very technical term, could we come up with a better example, like ”video game console” or ”video disc player”?
   
6. Lastly, ”HDMI-compliant” sounds very formal. Is that really necessary to include?

--Mango från yttre rymden (talk) 22:59, 30 April 2024 (UTC)

Cable categories

I am the one who implemented cable categories to the table for Refresh frequency limits for standard video. I have always been under the impression that each formal title represents a category. But almost six weeks ago, I came by here to look at my splendid little table addition ;-) and see what resolutions I possibly could use for a bunch of old cables that might come to my possession. I saw that High speed was added into the 2.0 column. I was certain it was an error, but decided to check it anyway. At first I couldn’t grasp that what I read didn’t correspond to my expectations, perhaps denial, but after a while I couldn’t simply dismiss it. I looked further into categories, and it seemed to me that there are actually only three cable categories, and that Premium high speed is the same thing a regular high speed but with a slightly more comprehensive testing, but not really stricter for the previous test methods. Is that so? Then we should clarify that in the text. Should the columns in the table about frequency limits be merged? --Mango från yttre rymden (talk) 22:59, 30 April 2024 (UTC)