HDMI Forum Rejects Open-Source HDMI 2.1 Driver Support Sought by AMD
phoronix.com
phoronix.com
I’d be willing to pay up to $199 for such a box if it has an open API to input overlay text and icons.
I hope it's not just FAANGs and blessed hardware OEMs...but it also sounds likely it must be, you can't let just anyone in if you're worried about the specs leaking...but then again that sounds weird too, in that, they used to provide the spec more openly until 2.1?
Now that may not help you, as the devices that do SDI overlays run in the $1k range, but maybe something is out there like a ATEM SDI https://www.blackmagicdesign.com/products/atemsdi
Might be worth a try to check how hard BMD has locked down the FPGA bitstream.
All dumb shit, but you know we were kids.
In general, audio and video production have never been cheaper or more accessible. There's no conspiracy of The Man keeping people down.
The simplest useful app would be: watching a movie together with friends, have them type their comments on their phones and display them on my TV, in a lower third. The chat part is trivial but how to get that from a server to the video stream? Maybe there’s a simple way to do it using a device like the Mini Pro but when I search I do t see it.
That feels like such an obvious thing to say that I hesitated even saying it, but then I started thinking about how funny it is. A solution to HDMI being so locked down is to buy a $20-ish computer, that does all the things a computer can do, so that we can feed the TV the video stream we want. Over HDMI.
Given that it's so easy to circumvent now, I wonder why anyone even bothers with HDMI any more, aside from inertia.
You use one of the many apps that can output your text, set it to output the background as green or whatever.
Then you can use the Atem to do one video stream inside the other, picture in picture, you can customize the size of the picture in the picture.
You can also have ot chroma key out the green (or whatever) from the text app, so it will only display the text, and the background will be the main video stream.
Bam.
This is what twitch streamers do all day using OBS and twitch chat. Hang out with their followers and watch/react to YouTube videos and read chat comments.
Is the GP commenter suggesting that they'd like to have people in remote locations each load a copy of their DVD into a player at the same time so they can comment on it together? If so, then yeah, you need a capture card I guess, but the notion of doing that seems a bit bonkers.
I was looking into what would be necessary to build a HDMI switch that allowed for seamless switching of video between different inputs, and basically there was no hardware for it. The closest chips that I could find was Analog Devices' ADV7626 and Lattice's SiI9777S.
Lattice CP9777 might be worth having a look at if you can understand anything about the datasheet :)
There are HDMI splitters which silently strip HDCP to output to two screens at once - they don't advertise this feature but they do it anyway in order to function. In order to achieve the overlay you'd just need one of these and then a non-HDCP-aware overlay apparatus before the display.
https://www.reddit.com/r/VIDEOENGINEERING/comments/xme482/hd...
Will run you $1K though. Corsair/Elgato has some solutions in your price range but the devil is in the details of precisely what you're trying to accomplish.
Yes, it's not pixel perfect. Thing is, the people who buys 38-in-1 do not care about pixel perfect picture. They just want an affordable way to spend an hour and half with their family.
Can be played Android-type boxes or even on phones / tablets
Essentially sneaker-net but for watchable media.
Not something you will see in much of in NA or Europe but very common in Asia and Africa where bandwidth /internet and more important, electricity, is relatively expensive.
The 90 minutes with your family comment is spot on.
in NA and Europe, this is mostly because folks don't have access to continuous internet. You are in back-country or don't have service or whatever.
In the Africa / Asia case, its because you don't have internet and / or power.
Most of the time, this media is viewed off TVs running on batteries, charged by solar, off an USB port. The electricity budget (because battery) says you get "90" mins of TV a day (not exactly 90: the power is shared between lights, charging phones, would be be more time but because electricity is limited, "TV time" is limited).
So those "90" minutes are family time, we all watch the same thing together.
Point being, in that world, Cam or SD of whatever works, no need for HD, or UHD or 4k or 8k - it is completely worthless. The screens that the content is being watched on are 720p most of the time.
Something like this (edit replaced original link with a new one that explains what is happening better)
https://www.npr.org/sections/goatsandsoda/2021/11/10/1052926...
I think the last time I saw a 9-in-1 DVD on sale there is somewhere around... 2018 probably?
However, I suspect that isn't the real holdup here since DisplayPort also fully supports HDCP
https://fahrplan.events.ccc.de/congress/2011/Fahrplan/events... (Slides and long write up)
His 28C3 talk https://www.youtube.com/watch?v=37SBMyGoCAU
I don't think this behavior is customizable.. (but maybe with some hacking).
It's a mechanism to force you to pay a licensing fee to manufacture hdmi devices.
It's why display ports are the way to go.
Also i love that DP-plugs have that latch thing so the cable always stays attached
The latest version of DisplayPort has a bandwidth of 80 Gbit/s, and you get drivers on day 1.
https://www.amazon.com/Cable-Matters-DisplayPort-Adapter-Res...
https://tomverbeure.github.io/2018/04/23/Color3-HDMI-RX-to-H...
Right now it’s just a proof of concept (check out the video with a moving overlay rectangle and the red 8 that is converted into a partially green 8), but it wouldn’t take a whole lot of work to add support for subtitles.
There are still some of these boxes for sale on Amazon, but supply is limited.
Unfortunately, it never materialized. Bunnie is a hero and his work is liberating. I could never get the NeTV stable enough to go into commercial production and the NeTV2 is excellent but a little too expensive.
And at this point that's one of the several (many?) protocols that runs over a USB-C cable, right?
HDMI is not packet-based and so when it uses USB-C it takes over the entire cable (alt-mode)
This is part of why DP is $$$ compared to HDMI. I would love to see DP start eating HDMI's lunch after this and the absolute shit show that was the HDMI 2.0 roll out but cheaper to implement is almost certainly going to be the driving factor when it comes to consumer grade TV / Displays and no console or other set top box maker is going to bother putting display port on their device if nobody's got a TV that can use it.
Why is that more expensive?
In terms of complexity, implementing DP vs HDMI 2.1 is not materially different. They both have fixed rate links, packets, Reed-Solomon forward error correction, DSC, etc.
But IIRC DP is royalty free, and HDMI is not.
You can check that there in this presentation (https://www.vesa.org/wp-content/uploads/2011/01/ICCE-Present...), page 32 and 33.
The majority of DP traffic is still brute force video data, interspersed with heavily packetized secondary data.
Over the years, I've spent many hours wading through DisplayPort data debug traces, and I've always wondered what people were smoking when they called it 'packetized like Ethernet'. It's just not true. (And FWIW: even old HDMI can transport secondary data packets just the way you can with DP. It's how audio-over-HDMI is done...)
"ARC" seems to be "Audio over HDMI using CEC for discovery and control", which (if you've bothered to run CEC over the DisplayPort AUX channel) you get the rest automatically with DisplayPort.
However, because both CEC and ARC are HDMI standards, you bet your biscuits that the HDMI Consortium will bar anyone who wants to use HDMI ports on their devices from shipping official firm/software that does the braindead-simple thing of running CEC over DP AUX, and having ARC-compatible firm/software.
As is nearly always the case (and when it's not, it's not for long) DisplayPort is totally capable of everything HDMI is, but the HDMI Consortium stands in the way of having commercially-distributed DisplayPort "home theater" products that are compatible with the nice-to-have HDMI features.
Like you point out, there's no technical reason DisplayPort cannot provide similar features. The issue is the lack of any standards for them built into the DisplayPort specification. Some of these features, like CEC, are 20 years old and could easily be improved upon in an ecosystem that doesn't have to worry about backwards compatibility.
Ah, okay.
Well, DisplayPort handles EDID, DDC/CI, E-DDC & friends... that's the CEC-equivalents handled. VESA does have standards for remote control of displays... it turns out that that's a thing that people want to be able to do.
> The issue is the lack of any standards for them built into the DisplayPort specification.
Nah. DisplayPort already supports everything (or just about everything) CEC can do.
The reason you don't see this stuff often making its way into TVs is because the HDMI Consortium gets in the way of folks who want to add DP ports to their TVs. The reason you don't see explicit support for HDMI Consortium protocols such as CEC in VESA standards is -again- because the HDMI Consortium gets in the way of folks who want to add DP ports to their TVs... so why bother? (Especially when actually supporting the protocol is trivial... squirt exactly what you'd send over the HDMI cable over the DP AUX channel, instead.)
If it was actually politically possible to have DP ports on TVs, then you'd see some of the more esoteric aspects of CEC (like manipulating a TV tuner) be quickly standardized into the VESA equivalents... assuming that VESA didn't just say "Oh yeah, y'all just go talk CEC to these new DP-equipped TVs. You already know how.".
[1] While the physical TOSLINK cable is able to support higher channel counts via ADAT[2], I'm not aware of any TVs with ADAT support.
Similarly, while 192 kHz / 24-bit TOSLINK support is common in pro audio and audiophile gear, the standard only requires 48 kHz / 20-bit. I imagine most TVs output 48 kHz / 20-bit, if only for the sake of configuration simplicity: TOSLINK is strictly unidirectional, so automatically negotiating format support beyond mandatory minima is impossible.
Great news! DisplayPort supports:
> 1–8 channels, 16 or 24-bit linear PCM; 32–192 kHz sampling rate; maximum bitrate 36,864 kbit/s (4,608 kB/s)
eARC lets your TV pass those along to your compatible receiver even if the TV itself can't make heads or tails of the format.
No, I think you're wrong about that.
> DisplayPort v1.2 also adds new audio enhancements including the following: — Audio Copy Protection and category codes — High definition audio formats such as Dolby MAT, DTS HD, all Blu-Ray formats, and the DRA standard from China — Synchronization assist between audio and video, multiple audio channels, and multiple audio sink devices using Global Time Code (GTC)
MAT claims to require an Atmos-capable decoder, so that sure seems like Atmos to me. I dunno what DTS HD, but that sounds like a souped-up DTS. Also take note of the "High definition audio formats such as" statement... that list of formats is incomplete.
The quote comes from: <https://vesa.org/press/vesa%C2%AE-introduces-displayporttm-v...>
DisplayPort Multi Stream Transport (MST) serves that role. Given that you'd only be passing along the audio data, rather than the video data, you could save money by putting the slowest available hardware (only BRR-capable) into the receiver.
Or, the TV could "just" pass along the audio stream to any plugged-in receiver. You don't gotta have a standard for that... just a standardized way to ask the TV to do it (assuming that you want to control the behavior and not have the conditional be "Is there a receiver plugged in? Pass along the audio and don't send it to the TV speakers.").
I think the biggest difference in DP vs HDMI cost is simply scale - there's probably orders of magnitude more HDMI chips sold than DP.
What does this exactly mean? I have an USB-C 4x1 Hub with HDMI that works at the same time as using 2 x USB-A 3.0, 1 x USB-C. Thanks!
Pretty much noone used HDMI Alt Mode on USB-C and is now deprecated IIRC.
AFAIK, when HDMI is used over USB-C, it's actually DisplayPort over USB-C; while a HDMI alt mode was specified, nobody actually implemented it, everyone instead implemented the DisplayPort alt mode and then used a DP-to-HDMI converter chip whenever an HDMI output was required.
> DisplayPort is packet-based and can be multiplexed with other USB-C traffic through a hub
That's the case only for USB4 (and AFAIK earlier Thunderbolt 3). Other USB-C ports with DisplayPort alt mode simply use some of the USB 3.x pairs for raw DisplayPort, and whenever the use of all four USB 3.x pairs is required for DisplayPort due to the target resolution, then only USB 2.x can be available (USB 2.x has its own dedicated pair in the cable).
Back in the Thunderbolt 3 era, it was up to each motherboard manufacturer to decide how many pairs they routed to USB alt-mode, so it's not necessarily a safe bet to depend on it working.
So, in one specific example, 4k60 over USB alt-mode DisplayPort is not supported on Apple's $4999 iMac Pro, as USB alt-mode is only assigned two pairs; however, 4k60 over Thunderbolt DisplayPort is supported, as Thunderbolt is assigned four pairs. The only way to get 4k60 out of that device is to use a Thunderbolt-only DisplayPort adapter, that has no USB mode at all.
This was resolved by USB 4 and Thunderbolt 4 both incorporating a more modern DSC (display stream compression), among other things as described above, but your mileage will vary much more wildly with USB 3.
HDMI Alt Mode also was a thing, but is now deprecated.
USB4 will push 120GBit/s. This will be enough for 8k 120hz/4k 240hz but not much more. This will probably be enough for high end consumer displays and GPUs for a decade out or so.
Its packet-based nature is not relevant for DisplayPort Alt Mode, by the way, because it gets dedicated pins. Sometimes enough for two lanes, sometimes enough for four. It's hilariously consumer-unfriendly. Only Thunderbolt leverages the packet stuff and can transport up to eight lanes worth of DisplayPort.
macOS does not support MST.
Who is supposed to get this? I don't know.
Not that it would be a complete solution for me since I'm limited to DP 1.4.
I have been looking for a display port -> hdmi adapter with vrr support for a while.AFAIK, nothing on the market currently supports it, including the cable from cablemod mentioned by OP
FWIW I also didn't realise this until just now. I've been running my desktop at 4k@120hz recently for the buttery smooth neovide, but have been noticing that text rendering, especially syntax-highlighted text, looks awful. I'd seen the same oled panel render text way better in WSL/Windows (both using a custom pixel geometry[0] via Mactype, but also without), so I spent more time than I'm willing to admit to wrapping my head around custom pixel layouts and hinting in freetype. But no, turns out it was this all along.
If you want to see the effect of 420 vs 444 chroma subsampling on text rendering, this writeup[1] has some great test images and is well worth a read. Also, if you happen to have an LG OLED panel, you can get a little debug window that confirms your signal format and refresh rate, by pressing the green button on the remote 7-8 times.
[0]: https://github.com/snowie2000/mactype/issues/720 [1]: https://www.rtings.com/tv/learn/chroma-subsampling
I immediately noticed there was something wrong. I agree it's terrible for desktop use. I would probably also have blamed freetype if it only happened on Linux, though.
I disagree. Gaming can involve lots of (colored) text too. And besides, if you have invested in a 4k@120Hz monitor are you really going to accept chroma subsampling even for non-text content?
I hate how the connection just magically switches to chroma subsampling (and/or DSC with newer connection standards) instead of that being something you have to explicitly enable. Well with my montor (and AMD card limited to HDMI 2.0 due the BS in TFA) it at least defaults to 60 Hz but there is no indication what the consequences of setting it to 120 Hz are.
You're not even told that your connection has been downgraded by any OS I have tried. Absurd that you have to result to these test patterns.
You are free to send me a couple grant for my birthday to buy a new equivalent TV with display port connectors. Except you can't even do that because such a TV does not exist.
If that's the case, someone needs to either leak the spec or reverse engineer the driver. One or the other will happen eventually.
This pretty much locks any media players into proprietary drivers.
It’s powered by this chipset afaik which supports vrr and hdr. https://www.connect.synaptics.com/spyder
It is also a USB-C to HDMI adapter, not a pure DP adapter. I think only the 20-series of Nvidia GPUs and maybe some of the 5000-series AMD GPUs have DP capable USB-C outputs. And apparently the M1/M2 Macs that the first article is about.
CableMatters is a good brand so if anyone could do it it'd be them, but it appears it's not quite there yet. Maybe when DP 2.0 becomes more common on GPUs it'll be a solved issue.
Based on my experience, this doesn't matter. I have a video card with no USB-C outputs. I go from full-sized DisplayPort to a female <-> female DisplayPort coupler, to this [0] bidirectional DP <-> USB-C cable, which plugs into my monitor. It works great and even does 4K 60FPS uncompressed HDR no problem.
I see no reason why you'd be unable to then slap on a female <-> female USB-C coupler and then that USB-C -> HDMI adapter.
(There's also no reason you couldn't cut out the first DP cable and coupler and plug the DP <-> USB-C cable directly into the video card. I just have very long (fiber-optic) DP cables that the second cable plugs into.)
What do you mean by 'fixed timing'? The fact that the transmission data rate is proportional to the pixel clock?
We're talking HDMI 2.1 here, which uses FRL (fixed rate link) and thus has pixel clock decoupled from the pixel clock just like for DP, with data split into packets. There's not a lot of difference between DP and HDMI in terms of functionality and complexity.
Indeed, 2.1 seems similar to DP. It would require quite a bit more logic to do that.
I wonder how many TVs support that?
I had a problem with Windows and AMD drivers where in this configuration the integrated GPU would run full throttle despite not doing anything serious, making the system run hot.
I "solved" it by using the DisplayPort - 10°C difference on the CPU and, more importantly, no throttling.
https://hackaday.com/2023/07/11/displayport-a-better-video-i...
I am writing this in Linux, while looking at a Dell monitor connected through DisplayPort, and my loudspeakers are connected to an audio output of the monitor.
Yes there are DisplayPort standards that can reach that, but in practice all the top end GPUs have only the old DisplayPort 1.4 version. That means the only choices are to use HDMI 2.1 or to use video compression over DisplayPort 1.4.
I will say that VESA has been very successful with their Display Stream Compression (DSC). Not that the algorithm is something special, but in terms of marketing. You never see monitor reviewers talk about the fact that using DSC will give you artifacts. VESA markets this compression as visually lossless, which every non-expert explains as actually lossless. In reality the losslessness is defined in the standard as when all the observers fail to correctly identify the reference image more than 75% of the trials. Beyond that, like with any compression, it will fail at high entropy images. Take for example this 2017 study titled Large Scale Subjective Evaluation of Display Stream Compression [1] which found that performance on some images was not visually lossless, however, those images were challenging images with high entropy.
--
[1] https://www.researchgate.net/publication/317425815_Large_Sca...
(DSC also has a great property of making the image delivery significantly more resilient to cable issues and thus much more reliable for most people using high res monitors.)
No, I use HDMI 2.1 without DSC.
Otherwise though, yes I have very good vision and work with images professionally. I do spot artifacts when they are there.
I get it that not everyone needs perfect images. I mean, people watching YouTube certainly won't be able to tell if there is an additional artifact on top of the low bitrate video they're watching.
I'm sure they wouldn't make such a move lightly, but is there something fundamental here about the laws or specifications that prevents them from doing this?
Note that the latest VESA specs are also restricted.
FWIW, it's easily possible to sniff the control channel of an HDMI or DP connection. At that point one could attempt to reverse engineer the enabling features.
In the emulator scene, there is a set of documents that describe, at deep and intimate levels, the inner workings of the N64, released by a disgruntled SGI employee somewhere on USENET. It is common knowledge that reading those documents taints you from working on basically any graphics or game related source for the rest of your life.
This doesn't just apply for leaked things. There's people who've worked on the Deep Parts of Windows, MacOS, etc. that they are basically barred from making contributions to certain open source projects (e.g. Wine, AsahiLinux) as anything they do would likely involve secrets that are tainted with knowledge from their former employer.
Every graphics, emulator, game engine, and embedded guru on the planet has watched the Gigaleaks out of nintendo with caution, as they now have to be VERY careful where some things come from. If someone reads code from The Gigaleak, then contributes code to an emulator, the emulator may be tainted.
This came to a head when the PowerVR SGX drivers were leaked ( https://www.phoronix.com/news/MTg0NTQ ) and several developers eyes were burned as a result.
This came to a head when the PowerVR SGX drivers were leaked
...and some far-East modding communities managed to make unofficial Windows 9x and XP drivers using that. They will of course not tell you who they really are.
Wild arse guess, but it's probably a) as close to absolute control as they can get, and b) security (of some variety) through obscurity
Probably makes it tricky to get HDMI forum's blessing for any future devices. AFAIK, the hdmi standards are public-ish so anybody can create a device that is HDMI compatible but you're only allowed to put "HDMI" on the packaging / marketing material with the forum's blessing.
Flipper × Raspberry Pi did exactly that just a couple days ago: https://blog.flipper.net/introducing-video-game-module-power...
> Video Out port: DVI-D signal in 640х480 px, 60 Hz. The port supports a well-known video standard that we can't name due to copyright limitations :shush: The first letter is H, and the last one is I.
At Worse: Get sued for breaking NDA, lose, pay a metric fuck ton in damages, and get kicked out of the forum and can never support HDMI products going forward.
But yeah even if the patch some how was made public, and it wasn't nuked out of orbit, ongoing support and bug fixes would be a pain in the ass. (Because as an example, no one from AMD would be allowed to touch the "patch code")
<edit> If AMD's planned patch was leaked for example, as AMD had not officially released it, its not yet "open source" and because of that, not yet public, and I'm sure there will be a clause in the terms that state that AMD would have to go on the offensive to get their code removed from any public repos. </edit>
When it comes to lawfare, The Forum wouldn't even have to be in the right (in a legal sense), just have a big enough war chest to make everyone else's life a pain in the ass!
The patent pools around approximately all the codecs used for media delivery are heavily cross-licensed. That includes HDMI and HDCP, but also h.264 and h.265. Most likely AMD can't legally use hardware decoding or encoding of any popular codecs at that point. Good luck with game video, streaming, or playing media discs.
So it would cost AMD - for example - their entire PlayStation/XBox business. At a minimum.
But I guess I learnt something new today.
I'm sure people said similar things when indoor bathrooms were a new thing, but there's always some luddite who says "we never needed those things before!"
The fact that you are comparing a larger television to having indoor plumbing shows a lack of perspective or good-faith argument on your part.
I recognize the choice isn't palatable to the likes of many, but ultimately there is a choice being made. The choice of convenience and entertainment over principles of privacy and ownership.
All I'm saying is that there are still choices, they aren't perfect.
It's certainly true that majority of TV manufacturers don't actually pay royalties/licensing fees to the Consortium.
Here we see the proof that a private consortium is forcing one of its member to restrict it's innovation to avoid competitors to the member of the HDMI forum to have access to its technology...
From my understanding, the spirit of those type of industry consortium/forum is to foster industry wide collaboration and innovation while style protecting the IP and patent of the originating companies.
But as usual, even when the companies are well served, the consumer don't have a say on those decisions...
I wish the FTC would investigate what are the economical impact of those type of decision on the consumer and the market in general.
Yes and the correct solution would for the government to start representing their citizens and ensure that their rights aren't being trampled over.
The attitude however, towards someone actively working for free to make your product better and wider-used, is what makes me say this.
The actively working against someone trying to make your stuff work more and give more people the opportunity to use your product, is nothing if not a clear indication of your wish for your product to die.
When you're literally spending more effort working against their own stuff..