Reverse Engineering an HDMI Extender


There’s a number of devices out there that extend HDMI over IP. You connect a video source to the transmitter, a display to the receiver, and link the two with a CAT5/5e/6 cable. These cables are much cheaper than HDMI cables, and can run longer distances.

[Daniel] didn’t care about extending HDMI, instead he wanted a low cost HDMI input for his PC. Capture cards are a bit expensive, so he decided to reverse engineer an IP HDMI extender.

After connecting a DVD player and TV, he fired up Wireshark and started sniffing the packets. The device was using IP multicast on two ports. One of these ports had a high bitrate, and contained JPEG headers. It looked like the video stream was raw MJPEG data.

The next step was to write a listener that could sniff the packets and spit the data into a JPEG file. After dealing with some quirks, JPEG images could be saved from the remote device. Some more code was needed to have the computer initiate the streaming, and to extract audio from the second port.

In the end, video capture with the low cost device was possible. [Daniel] also provided a bonus teardown of the device in his writeup.


  1. vonskippy says:

    Clever and a decent write up.

  2. ejonesss says:

    so you mean you can defeat hdcp so you can record from the hdmi port?

  3. pez says:

    Wow, if these extenders work with hdcp signals, then they may offer an easy way to crack hdcp security.

  4. pez says:

    Hah! Two posts on hdcp cracking at almost the same instant

  5. notabena4us says:


  6. BiOzZ says:

    its a good way to capture some video without having to run any complacated encoders! i want to try this!

    • If you don’t think what he did is complicated, why didn’t you do it first? I think his hack is really something for not having any datasheets or diagrams and just reverse engineering it. There are easier ways, they may or may not be cheaper but definitely already proven and easy to use. For proof, see all the TV shows ripped from HDCP digital TV boxes and DTV cards.

      • Anthony says:

        Not to put him down or anything, I think what he did was great and better yet he told everyone about it …

        but watching packets from wireshark and saving them to images seems much easier and “cooler” then dealing with capture cards and encoders

      • Me says:

        “If you don’t think what he did is complicated, ”

        I’m not sure that is what BiOzZ was saying. Copying what someone else has already done is not as complicated as being the one who did it in the first place. Eric Evenchick did the complicated work, now the rest of us can have a simple way to capture video.

      • BiOzZ says:

        i never said what he did was not complicated i just said it does not include any complicated encoders meaning durring a screen capture the CPU is MUCH MUCH under burdened compared to standard screen capture software … i understand and respect very much what he did but its much less complicated WHEN RUNNING than a screen capture software would
        i was looking at the end result not the process he was doing to get to that end result

      • I believe what he meant by “complicated” is how it’s like to prepare a PC-based capture setup. There are performance issues, memory allocation troubles, little know-hows etc. It is sure un-complicated if you could keep those mess into little converters and get clean, standardized output format from them.

  7. omegacs says:

    OK, so if we can get a HDMI+HDCP raw stream converted to IP, what kind of bandwidth is it actually using, and what’s the JPEG quality level? If it’s pushing most of a gigabit, that’s about 3MB per frame at 30FPS. That’s *more* than enough for JPEG to approach indistinguishable from a MPEG-class source. But if it’s only running a fraction of the total cable bandwidth it might not be as good. And unlike MPEG, it won’t get better frame-to-frame.

    OTOH, the IT6604E decoder chip puts out high-speed raw video in YPrPb etc, so one could simply “steal” the chip and remount it with something that can interface to a computer at a high enoug speed, e.g. a Cypress EzUSB FX3. Even better, it looks like the chip itself *might* be available in small quantities on Alibaba.

    • omegacs says:

      OK, so here’s the bad news – you can pretty clearly see a RTL8201 in the pictures, which is *only* 100Mbps. There’s no way you’re going to get decent enough HD video over 100Mbps with MJPEG to make it worth using this as a method to rip anything.

      • rasz says:

        h.264 1080p looks good at 15-20Mbit, thats the bitrate of HD “action cameras”
        mjpeg encoder will probably double that bitrate
        the question is, does it drop frames? and what is the quality? a comparison between this and capture card would be nice

        • omegacs says:

          No, MJPEG is going to be *WAY* more than double the bandwidth of H.264. The only actual *numbers* I can find are from surveillance storage servers, so the source video isn’t comparable to your average Blu-ray, but I’m getting a ratio of about 12:1 on average:

          HD is going to alter that ratio further in favor of H.264, although I suspect the low source qualitity of surveillance footage will actually alter the ratio about the same amount the other way.

          MJPEG has to encode every frame separately, while H.264 uses *decades* of research into encoding the vast majority of the frames as the subtle differences between algorithmically derived combinations of neighboring frames.

          • rasz says:

            not vast,
            one of the chinese action cams I had produces ~17Mbit of h.264, it does I-P-P-I-P-P where I is Intra (basically jpeg) and I is motion compensated delta, that gives 3:1 ratio.

          • omegacs says:

            When you compare MJPEG to what is essentially crippled H.264, then sure, you can claim whatever ratio you want. But it’s irrelevant, because we’re talking about a 100Mbps connection. If you start with a Blu-ray that’s running let’s say 20Mbps of H.264-ish content after B frames and everything else the format allows are used, you WILL be looking at a 10-12x increase in bandwidth for MJPEG to get equivalent quality. That’s 200-240Mbps. Therefore by definition any device that tries to accomplish the same thing in less than 100Mbps is going to have a *radically* reduced overall visual quality when it uses MJPEG.

          • rasz says:

            blah, my reply with a link doesnt show up (not even in moderation queue) :(

            #808 cameras doing 1080p 30Hz need 35Mbit for mjpeg stream

            so 60Hz stream will use up 70Mbps

          • Greenaum says:

            It’s running 2 100mbps links right? So, 200mbps. Or certainly more than 100, or else they’d only need one link. I’d bet they’d get most of the theoretical 100mbps per link, since it’s a 1-way connection between just 2 points.

          • omegacs says:

            Nope, just one port. Look at the inside shots, there’s one controller (RTL8201), one set of magnetics, and one jack.

            Re: “808 camera”, I would expect the input source (tiny camera) to be a combination of too noisy and not detailed enough for JPEG artifacts to matter at the level they would for fully produced content. Here are some examples:

            Security camera:
            Size: 104KB
            Raw bandwidth at 30p: 24.96Mbps

            Size: 439.54KB
            Raw bandwidth at 30p: 105.49Mbps

            Add UDP, Ethernet framing, and inter-frame timing and you’re up to 115-120Mbps equivalent. And that’s using an “unlimited-time” JPEG encoder.

            There’s a simple answer to all of this – I’m going to post a comment on his blog asking for a) actual bandwidth usage numbers, and b) a screengrab or two from a “high-quality” source like a Blu-ray. If the bandwidth is near max and the quality is good enough, I’m likely to go grab me a set of them.

            Just don’t expect to use these to to “pristine” captures of produced content.

      • Me says:

        Oh you spoiled kiddies. I remember how cool I thought I was when I was the first person I knew to watch tv live-streamed over the internet using Real Video and a 28.8k modem. Now some people aren’t interested if it’s anything less than gigabit!

        • Old'un says:

          I recall a couple of projects I was involved in during the mid-90s… Video over a cellular link (160×120 & poor quality, granted), and a demo of the vp1 codec, managing TV quality at under 1Mbps….

  8. So – he said the input was a DVD player; I suspect there was no HDCP involved. These cheap extenders often (usually? always?) simply don’t support HDCP. I’d love to be wrong here, but I wouldn’t get your hopes up…

    • … and, apparently it does decode hdcp, my bad. I wonder if the video he was using had it enabled? To decode hdcp and send it out over the wire unencrypted has got to be violating their license (like I care).

    • omegacs says:

      The HDMI interface chip it’s based on has an HDCP key burned into the silicon, and the product documentation explicitly mentions HDCP. The real question is whether there’s a feature in the processor that encrypts the MJPEG stream if the HDCP flag it set, which would have to be tested against a known-HDCP stream. A quick reading through the datasheet does not indicate that there’s even a way for the IT6604E to notify that HDCP was used, so that seems unlikely. The only reference I see is something about the DDC interface having something to do with HDCP (duh), but it’s unclear whether that means the actual HDCP key negotiation is going on between the IT6604E and the processor over its I2C bus or not. I suspect not, since the chip datasheet says “you don’t have to worry about HDCP because we do it for you and the silicon ships with a key”.

      Now that this first round of work has been done I have no doubt we’ll find out within a day or two what happens as far as known HDCP, from the OP or somebody else.

  9. Doktoreq says:

    After reading article I immediately started looking for one to buy in my country. The cheapest one I found was somewhere around £170 (you can pay 1 month rent for that kind of money). I think I’ll get one of ebay (as usual with electronics).

  10. fartface says:

    Confused as to why he reverse engineered it. HDBaseT is a open and completely documented standard.

  11. Mike Lu says:

    I wonder what the latency is like. Something like that would be perfect for connecting my lab PC to the living room TV (mainly for gaming), but if the lag is too much, it would be unusable.

  12. millers says:

    Surprised no one has mentioned this as a way of pulling colour data from a HDMI signal for use with ambient lighting setups. Seems like it should be easy enough to analyze the current from and use it to control some rgb leds

  13. Hirudinea says:

    Looks like something that should be integrated into the next XBMC release.

  14. alxy says:

    > “After trying few formats for importing I found out, that there is some audio playing when set for Signed 32bit PCM, big-endian, stereo, 48Khz.”

    If it can decode and stream the raw 7.1 multichannel audio content (ie lossless DTS-HD Master Audio, or Dolby TrueHD stream from a BR or cable box), that would be worth it. But looks it only streams 2 channel pcm, or at best 5.1 aac, like most common hdmi->vga converters.

  15. seba k says:

    Reverse engineering Chinese hardware. The irony…

  16. fartface says:

    What a big waste of time and effort. These HDMI extenders don’t convert the signal in anyway, they’re just signal boosters that use the copper wires in the ethernet cables to transmit a HDMI signal. That’s why you need two ethernet cables. The cheaper ones don’t even signal boost.

  17. zibri says:

    More a sniff than a hack but the final quality will be awful for a device that is not cheap at all.

    • dwild says:

      He didn’t included picture, which for me is a good sign that the quality is really bad.
      However the device is actually cheap and break HDCP. My HDMI capture card cost about 130$, add to that 40$ for an HDCP stripper.

      You can order this device for 59,99$ on Amazon :

      I’m not saying the quality is worth that price, but it’s nearly 3 times cheaper, so we can say that it’s cheap.

      It even have the capacity to stream on your network easily (but it will take 1/10 of your network…). You can use it like a Slingbox.

  18. qwerty says:

    How about making use of the other box too by writing a device driver that emulates a video card but instead sends the video through ethernet? This would make possible adding video out to cheap routers, NAS boxes, embedded cards, etc.

    • leftsquarebracket says:

      Already sort of exists:

      The issues you’d run into would be those of space in RAM/FLASH for an entire framebuffer device. If you’re looking for a full windowing desktop or HD video, look elsewhere, because most Linux-based embedded devices are going to lack that dedicated hardware/memory. YMMV, though, since there’s so many different chips out there with varying capabilities.

  19. Simon says:

    Kind of off topic a bit – but I note his use of Python to decode the binary stream. Recently I discovered ‘Construct’ (1) which is a convient way to describe binary protocols with the view to decode and encode… a good thing to have in your tool kit.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 96,670 other followers