One caveat of these dummy plugs is that they don't do HDCP. They handle the typical use case of forcing a specific resolution output for headless machines rather well, but fail for the use case that you need to run something that expects HDCP.
This seems a good place to ask: does anyone know of a good solution like this HDMI dummy plug, but that negotiates HDCP? I need to test video streaming apps that require HDCP to play at full resolution, but it is inconvenient to have a full TV for every test.
The one solution I've found is an HDMI multiviewer, which seems to negotiate HDCP to each port individually.
I use this HDMI splitter. It lets you either set a preprogrammed EDID, or learns an EDID from whatever you plug into HDMI output 1, and then shows up as a connected monitor for as long as the splitter's plugged in without having to connect anything to the outputs. I believe it negotiaties HDCP between the computer/console/whatever and the splitter, then sends the signal to the output monitor without HDCP. https://www.amazon.com/dp/B07VP37KMB
I have a different usecase. I have an embedded system that sends out HDMI. However, its boot screen is something I want to replace by another HDMI stream (a static image would suffice). I specifically don't want to change anything on the embedded system for a thousand reasons I won't go into. How do I cheaply and robustly do this?
Probably not the most elegant solution, but there are many HDMI switchers out there that can be talked to using gpio and/or RS-232. You could use one of those and a Raspi, feed the image in from the Raspi, detect the power of your embedded device via GPIO and then switch over to the other HDMI input. Whether that is a feasible solution mostly depends on other requirements, e.g. regarding power consumption or space.
I used a similar solution once in an AV context and it has been running reliably for years now.
If you want something less hacky Blackmagic has the Atem Mini, a good HDMI switcher that can also store multiple stills and can be switched via ethernet (among other things)
https://www.ti.com/product/TMDS261B
This and an RP2040 to generate the second signal would probably work just fine; see https://learn.adafruit.com/picodvi-arduino-library-video-out... for an example of how to stretch the rp2040 to do HDMI
Aliexpress sells things that claim to terminate hdcp and forward hdmi. Caveat emptor.
I find it crazy that the signal between our monitors and desktop computers is encrypted when these exist.
What's even crazier is that we get the negative of DRM but none of the upside. I have a 4k hdmi 2.0 TV without hdcp 2, so no 4k content without the "splitter". Also any interoperability issue is a "catastrophic" failure (as in at best no content, at worst no hdmi output at all). And yes they do happen, either because of broken software implementation (some TV don't reset their hdcp state machine when switching hdmi source), or just dumb electrical issue (i2c - and cec - have a habit of dying because of leaking charges, and one needs to unplug everything for 10 min to fix it)
That's video DRM for you.
Upside? There is no, and never was, an upside. Not for the user, and not for anyone else. Video DRM literally never worked.
Nonetheless, it exists, and it makes things worse for everyone by existing.
I even occasionally get audio issues on Netflix (AppleTV plugged into Samsung 4k oled tv), which I assume are due to some kind of DRM, though never dug into it. Sometimes when switching inputs (firetv stick / AppleTV stick), or switching content on AppleTV between different apps, the Netflix content audio just stops working. All app UI sounds work correctly, but no audio once you hit play. Toggling the AppleTV audio settings a few times between dolbyAtmos and standard stereo usually brings it back, so I assume it has something to do drm on the audio tracks, but if anyone has other ideas lmk
I used to run into this often with Paramount+. I don't know if it's still an issue or not because I cancelled over it (plus them showing me ads when I pay for premium).
When I worked in music streaming I made these arguments all the time. The labels would agree with us wholeheartedly about how shitty DRM was but said they demanded it because the artists demanded they do "something" to stop the copying.
https://youtu.be/z8K08AcVru0?t=627
I assume it has an upside for whoever invented it since they can sell it to everyone
This is how the world works. If you want to get rich, you can sell something that doesn't work, to rich people who believe it does. That's basically how YCombinator works.
The only direct upside to DRM is for the IP owner.
Yes though for monitors displayport is better anyway and it doesn't do hdcp.
DisplayPort has supported HDCP (as well as its own DRM scheme DPCP) since version 1.1.
I agree that DisplayPort was better for monitors, but HDMI has basically become DisplayPort so these days they're more or less two sides of the same coin. Both use data packets over fixed rate links now.
You may be thinking of HDMI vs DisplayPort over USB-C, because otherwise they couldn't be more different. In any case, HDMI is still heavily patent and royalty encumbered, to the point it is going to be difficult for opensource GPU drivers to support native HDMI 2.1 or higher going on, while DisplayPort is still royalty free.
The situation is so bad Intel has pretty much skipped native HDMI ports in recent chipset graphics to focus on DP only (motherboards can still install off the shelf DP->HDMI converters), while on AMD the newer HDMI features won't be supported at all on Linux.
> You may be thinking of HDMI vs DisplayPort over USB-C, because otherwise they couldn't be more different.
No, I'm referring to how HDMI 2.1 changed basically everything but the connector to become a multi-lane packet based protocol like DisplayPort instead of being a direct descendant of DVI, which itself was basically digital VGA.
I realize the licensing situation is a disaster.
yep, I'm running an hdmi to dp converter to make linux work.
There are others that end up doing the same thing - I believe some of the Decimators do - perhaps this?
https://www.decimator.com/Products/MiniConverters/12G-CROSS/...
Try one of these HDMI splitters that are more or less openly advertised as "HDCP strippers" on Amazon.
I think multiviewer might have been a synonym for that.
I wonder if the chips on these dummy plugs are powerful enough to hack in HDCP support though.
The dummy plugs are literally just a 256-byte eeprom hooked to the I2C lines, there's nothing else inside the shell.
Terminating HDCP is difficult, you’d have to downgrade it to HDCP 1.4 and then have a 1.4 ‘compliant’ (see: device on the end for it to be a dummy monitor. If you need anything newer than HDCP 1.4, it’s likely not possible.
I did a tear down of this Monoprice dongle: https://tomverbeure.github.io/2023/11/26/Monoprice-Blackbird....
It terminates as an HDCP 2.0 endpoint and converts to HDCP 1.4. You’d still need an HDCP 1.4 sink to make it work though.
I'm using the Monoprice multiviewer. It negotiates HDCP without a display attached. Other than being a bit big and expensive, and being unable to strip HDCP, it's a good solution.
I found the same device in generic packaging on AliExpress, but haven't had the chance to order that version, yet.
There are lots of professional SDI converters and such, but they are either $3k+ or "call for price".
That was written by you?
I don't agree with this section:
> The HDCP converter simply announces itself as a final video endpoint… yet still repeats the content to its output port. Without a very expensive HDMI protocol analyzer, we can’t check if the source is tagging the content as type 0 or type 1, but there is no reason now to think that it’s not type 1.
There's no magic in the HDMI protocol that says type 1 vs type 0. Its just another HDCP message over DDC, but it is only sent to repeaters. In this case, since the HDCP Repeater is lying about not being a repeater, it isn't getting sent the StreamID Type information.
You’re probably right.
Great teardown. Can these things remove HDCP altogether? It seems like if it can report that the sink is HDCP2.x then it can do so even if it has no compliance at all right? So that would mean it streams an encrypted stream to something that needs to then still do the decryption? These devices seem like they'd be underpowered to do that in real time at 18 Gb/s.
I assume the silicon can do it, but it’s not exposed to the user, because that would almost certainly be a license violation.