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.

58 thoughts on “Reverse Engineering an HDMI Extender

    1. This device will give you a lossy capture; since HDMI data rate is substantially higher than ethernet cable is good for; even the extender boxes that use a proprietary non-IP link generally require two good-quality ethernet cables to ‘transparently’ extend an HDMI run(that sort of extender is quite useful when wiring up projectors and such, since plenum rated cat6 is relatively cheap in any length you want, because of the GigE market; while HDMI cables that won’t fail intermittently from some sources on a 50-meter run are deeply noncheap; but the use of ethernet cables does not imply routability or even the most basic compliance with ethernet; you buy the two boxes from the vendor, they do whatever they want on the 8 twisted pairs; that’s it).

      This one uses a real, honest, IP link; so it definitely isn’t going to match HDMI data rates(even HDMI v.1 is good for up to 4.95GB/s; and this device is using an RTL8201, which is a 10/100 ethernet chip); and it is using MJPEG compression, which isn’t terribly sophisticated, so the results will likely be lossier than, say, an H.264 DVD/BD rip; but yes, HDCP won’t stop you from getting the MJPEG stream

    1. The dirty little not-so-secret is that HDCP can, at best, only verify that both devices have duly licensed HDCP keys; purchased from the licensing body( or purchased from someone who licensed HDCP and incorporated it into their chipset/product/etc.

      The only thing preventing a device with a valid HDCP key from doing a successful handshake with the content source; and then merrily passing unencrypted output to the user is the fact that the HDCP license agreement forbids licensees from making products that do that(and, although this option doesn’t seem to have been exercised, HDCP is designed to make it possible to revoke blocks of keys to lock out noncompliant devices).

      In practice, Random Chinese OEM doesn’t give a damn; so they can just purchase an IC that has a legitimate HDCP key; and an unencrypted signal output that is supposed to, say, go directly to a TV’s panel driver over a short, internal, link; and simply ignore the licensing rules by instead passing the HDCP-free signal on. A lot of ‘HDMI extenders’ and ‘HDMI splitters’ do just this, as a little value-add (just as, in the bad old days of Macrovision, ‘video stabilizers’ would improve your video signal’s stability and…incidentally…strip the macrovision).

      Actual cryptographic attacks on HDCP are more complex(though I believe that at least the earlier revisions have been fully broken); but simply ignoring the license agreement is relatively easy; and even 100% legitimate manufacturers need to make parts that take an encrypted signal and emit a decrypted one(if only to drive the LCD display and speakers; the viewer can’t decrypt it in their head); so there is always silicon that can be used to produce strippers by anyone far enough away from lawyers.

    1. 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.

      1. 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

      2. 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

      3. “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.

      4. 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.

  1. 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.

    1. 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.

      1. 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

        1. 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.

          1. 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.

          2. 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.

          3. 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.

          4. 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.

      2. 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!

        1. 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….

    1. 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.

        1. I don’t think you have to worry about the HDCP key for this device being revoked. My understanding is that HDCP is to prevent capture of raw uncompressed video. Since this device is clearly put out highly compressed MJPEG, it’s not breaking the rules. It has to highly compressing the video. Otherwise you’d need a much fatter pipe than regular ethernet. Anyway, my understanding is that HDCP has long since been cracked already. So, it’s a moot point.

      1. Sorry to wake an old thread, but I’ve been working on my implementation of this off and on for a while. Nearly have a fully featured OSX client in python, though it should be usable in linux too.

        I can decode known HDCP sources (Pay TV), and the quality doesn’t appear too bad. Enough to placeshift from 1080i source to my 1360×768 HTPC in the bedroom and not notice loss of quality, or show windowed 1080p content on my Retina MBP. End to end latency at the moment appears to be around 3-5 seconds with my implementation, and I’m working on integrating with TVHeadend ( and then to XBMC. I can’t accurately measure framerate at this stage so no comment there, but I’m currently working on a variable audio delay to resync audio and video – something the author or those commenting recognises as an issue.

        Once I have a solution I’m not ashamed of, I’ll post to the author’s blog

  2. 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).

  3. 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

  4. > “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.

  5. 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.

    1. 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.

  6. 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.

    1. 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.

  7. Great post! I am more than happy with mpeg4/2 quality so this hack, even with lossy quality is awesome!

    BTW, what about $70 android boxes with HDMI input (Tronsmart Pavo M9 4K, UGOOS UT3+ TV, etc).. is there any reason an open source server (like tvheadend) couldn’t be ported to do the same thing (stream hdmi video over ethernet)? Granted you would still need an external HD/ATSC tuner..

    I’ve seen commercial solutions, but they are all much more expensive than the $70 extender boxes:
    dvblink, vdr, , hdhomerun, tablo, eyetv, slingboxm2 / Slingbox PRO-HD SB300-100, nextpvr, tivo roamio) etc

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