There was some effort to reverse engineer those devices [1] so that one could use for example either transmitters or receivers paired with normal PCs and not just connecting them straight each other. There are also newer models around, though I'm not aware of any reverse engineering efforts so far.
If you want to tinker with them, please leave some writeup of the results. Beware that there are both HDMI over IP and aesthetically very similar, but often cheaper, HDMI over Ethernet cable adapters. The 2nd ones contain no brain and can't do any IP encapsulation, they're essentially just level translators using CATx cable to carry the HDMI signals, and of course aren't compatible with any network devices, switches, etc. For that use, you want HDMI to IP transmitters and receivers, which should be clearly marked as capable of working in a network environment. Check carefully the features before buying, because some among the stupid level translators sold on the usual channels are marked as HDMI over IP, which they clearly are not.
Do you have any insight regarding latency? Intuitively it sounds like HDMI over Ethernet may actually be a tad faster. I’ve also seen HDMI over IP devices marketed specifically as low-latency. I’m asking because I’ve heard a gripe over the technology generally that it’s too high latency to play video games.
squarefoot 773 days ago [-]
There's a short video on the page I linked showing figures around 100ms at 1080p, which seems quite good. The author however suggests newer models to achieve higher frame rates, but I have no knowledge of any reverse engineering wrt those models.
rektide 774 days ago [-]
People are amazing. I love this. Adore it. A thread of various awesome enterprising hackers, searching for truth, and using observability & tools to uncover meaning. Then bend reality to their whims & desires. This is the best human spirit. It's a pity technology so often obstructs rather than builds this human mastery. Alas! Never-the-less, humanity persisted. Against the throws of corporate-controlled limiting tech. Break out that wireshark & conquer in the name of freedom! Become great! Be unbounded.
I have huge respect for the Chromecast ecosystem, but there's so many weird prickly points for it. For a while I had a chromecast plugged in to a computer which then variously resent the output. This looks like a great way to do the same but simpler/dumber. One of the specific flaws of Chromecast is that if you stream a video, it can only go to a single device. Meaning my whole home audio does no good. Something like this could help me work-around that limitation. It's great how absurdly flexible these devices are, but it sucks enormous egg that Chromecast apps will only stream in the first place to signed Chromecast devices; this whole thing should be a non-issue I can software workaround. But a hardware workaround like this is adequate.
Hasz 773 days ago [-]
Wow, 100mS of latency? Surely most of that is in the encode/decode?
For comparison, I see somewhere on the order of 1-10mS of latency streaming over sunlight/moonlight. That’s close enough to “live” to make it feel real.
For watching movies, these are nifty tools, but sunlight/moonlight are a great combo for near-real-time control (ie video games)
jaywalk 774 days ago [-]
I didn't even know HDMI extenders over IP existed! I wouldn't use it for TV/movies, because the re-compressed picture can't look all that great. But I could imagine plenty of uses for something like that!
bobsmooth 774 days ago [-]
You can do HDMI over a lot of things. They all work by encoding the video stream, usually h264, and sending it over the network. Check out HDBaseT which does video, ethernet, USB and power over a single cat5e cable.
blahlabs 773 days ago [-]
Not sure if you gave heard of NDI before? Its a broadcast quality low latency protocol for video/audio over 1Gb links
dylan604 774 days ago [-]
Why do you assume the signal is being recompressed or in any other way manipulating the image?
duskwuff 774 days ago [-]
Well, for one, the fact that it's streaming frames as motion JPEG...
dylan604 774 days ago [-]
Where do you see that? I quickly glanced at the Amazon listing, and saw nothing about this. I could have glanced too quickly and missed it, but it just seems like a totally strange thing for it to do.
mrpippy 774 days ago [-]
It’s in the article
monocasa 774 days ago [-]
Because a 1080p60 video stream is about 3Gb/sec on the wire uncompressed like happens over HDMI. 1920w * 1080h * 3colorbytes * 8bits/byte * 60fps = 2,985,984,000 bits/sec.
metaphor 774 days ago [-]
Much closer to 5 Gbps when you factor in horizontal/vertical blanking + TMDS 8b10b encoding.
monocasa 774 days ago [-]
For sure, I'd simply expect even a simple non-compresing bridge to strip a lot of the 'dead air' and expansion at the physical layer. Just wanted to show that even best case of simply the color value bits leaves you with ten pounds of potatoes to fit into a five pound bag.
mrb 774 days ago [-]
A hypothetical HDMI-to-IP converter would certainly ignore hblank/vblank, and 8b10b encoding is only used on the HDMI link, not Ethernet. So parent's point stands: 1080p60 could be done in 3 Gbit/s.
metaphor 773 days ago [-]
Yes, the parent's objective clarification below was acknowledged. To be fair, the parent's point wasn't to assert a minimum Ethernet bandwidth that it "could be done in", but merely to highlight the incongruence of the grandparent assuming no compression when transmitting a base case payload over 1 Gbps Ethernet PHY.
I agree that the bandwidth overhead of 8b10b can be dismissed in context, but nevertheless disagree that the underlying functional equivalent of HDMI blanking can be entirely ignored given that's where the audio stream is embedded, with a max +/- 2 ms delay relative to video requirement.
To your point, it's unclear in my mind that even a hypothetical 3 Gbps Ethernet PHY would be sufficient in practice to transmit raw 1080p60 + stereo audio without some form of compression given framing and IP stack overhead, which certainly isn't free; i.e. you'd be at 92.7% link saturation in a completely lossless environment just blindly transmitting raw 1080p60 video data without framing or audio or IP encapsulation.
monocasa 773 days ago [-]
Even six channels of cd quality audio are 48,000 samples/sec * 16 bits/sample * 6 channels or 4,608,000 bits/sec, or ~0.15% of a hypothetical 3Gbps PHY. I didn't bring up audio because it's essentially a rounding error in terms of the bandwidth concerns.
mnd999 774 days ago [-]
That’s very doable on a 10gb Ethernet network which is becoming more and more normal.
metaphor 774 days ago [-]
Irrelevant. The hardware under scrutiny is a chinesium HDMI over IP extender with 1 Gbps Ethernet PHY at best.
mnd999 770 days ago [-]
Stupidity with a hint of racism. Nice.
monocasa 774 days ago [-]
It's going to be a while before 10Gb ethernet is available on devices that cost ~$30/pair.
toast0 774 days ago [-]
You're right, but used dual port 10g ethernet cards do go for about $30/each... Of course, that doesn't get you hdmi encode/decode, and not new.
dylan604 774 days ago [-]
Okay, but the original signal is not RAW uncompressed either. It's just a serial signal, so converting that into IP packets is pretty much all I'm assuming this is doing and then converting those back to an HDMI formatted signal on the other end. The only thing different about this unit from others is that it's actually turning them into actual network traffic to connect to an existing network.
monocasa 774 days ago [-]
> Okay, but the original signal is not RAW uncompressed either.
HDMI is in fact the RAW color values, uncompressed. Each of the color channels are serial, but that doesn't really change anything about the raw bitrate.
Clamchop 774 days ago [-]
Just to throw a little more hair-splitting, we're not talking about raw data, either, raw being a term of art for unprocessed or minimally processed data read from a device (like an image sensor). It usually can't be displayed without some interpreting.
HDMI video signal is uncompressed but not raw.
jacquesm 774 days ago [-]
I suspect that just delta compression would reduce the required number of bits considerably.
duskwuff 774 days ago [-]
Lossless compression isn't a good fit for real-time video. Being able to get some compression ratio on a "typical" image means your stream will drop out when the user has an image on screen which doesn't compress well.
belthesar 774 days ago [-]
You can look at the protocol analysis in the post to see that it's sending MJPEG
If you want to tinker with them, please leave some writeup of the results. Beware that there are both HDMI over IP and aesthetically very similar, but often cheaper, HDMI over Ethernet cable adapters. The 2nd ones contain no brain and can't do any IP encapsulation, they're essentially just level translators using CATx cable to carry the HDMI signals, and of course aren't compatible with any network devices, switches, etc. For that use, you want HDMI to IP transmitters and receivers, which should be clearly marked as capable of working in a network environment. Check carefully the features before buying, because some among the stupid level translators sold on the usual channels are marked as HDMI over IP, which they clearly are not.
1 - https://blog.danman.eu/reverse-engineering-lenkeng-hdmi-over...
I have huge respect for the Chromecast ecosystem, but there's so many weird prickly points for it. For a while I had a chromecast plugged in to a computer which then variously resent the output. This looks like a great way to do the same but simpler/dumber. One of the specific flaws of Chromecast is that if you stream a video, it can only go to a single device. Meaning my whole home audio does no good. Something like this could help me work-around that limitation. It's great how absurdly flexible these devices are, but it sucks enormous egg that Chromecast apps will only stream in the first place to signed Chromecast devices; this whole thing should be a non-issue I can software workaround. But a hardware workaround like this is adequate.
For comparison, I see somewhere on the order of 1-10mS of latency streaming over sunlight/moonlight. That’s close enough to “live” to make it feel real.
For watching movies, these are nifty tools, but sunlight/moonlight are a great combo for near-real-time control (ie video games)
I agree that the bandwidth overhead of 8b10b can be dismissed in context, but nevertheless disagree that the underlying functional equivalent of HDMI blanking can be entirely ignored given that's where the audio stream is embedded, with a max +/- 2 ms delay relative to video requirement.
To your point, it's unclear in my mind that even a hypothetical 3 Gbps Ethernet PHY would be sufficient in practice to transmit raw 1080p60 + stereo audio without some form of compression given framing and IP stack overhead, which certainly isn't free; i.e. you'd be at 92.7% link saturation in a completely lossless environment just blindly transmitting raw 1080p60 video data without framing or audio or IP encapsulation.
HDMI is in fact the RAW color values, uncompressed. Each of the color channels are serial, but that doesn't really change anything about the raw bitrate.
HDMI video signal is uncompressed but not raw.