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.

54 thoughts on “Reverse Engineering an HDMI Extender

    1. Defeating HDCP is pretty simple. Go on eBay and search for Chinese HDMI extenders, splitters, etc… This make it really easy to do that as well as send the video feed wherever you want, a la Aereo or a Slingbox.

    2. Yes. Buy a HD-Fury and forever be rid of the evil plague that is HDCP. It’s the only solution that actually works to completely strip all HDCP cleanly.

      1. There’s a capture card on dx, and hdmi splitters or hdmi to component converters on Amazon that will strip all hdcp. No need for that pricey adapter.

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

        1. [Daniel] did the complicated work, all I did was write this article.

          It is rather fortunate that the device uses no compression or encryption though, that could have made the hack quite a bit more difficult.

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

      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:

          http://www.mistralsolutions.com/hs-downloads/tech-briefs/jul09-article-1.html

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

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

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

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

          5. 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:
            Image: blog.use-ip.co.uk/wp-content/uploads/2013/04/20130410_112708.jpg
            Size: 104KB
            Raw bandwidth at 30p: 24.96Mbps

            Movie:
            Image: i.imgur.com/UIp52.jpg
            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.

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

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

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

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

          http://arstechnica.com/tech-policy/2010/09/intel-confirms-the-hdcp-key-is-real-can-now-be-broken-at-will/

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

    1. HDBaseT just allows use of “readily available cables” ie CAT5/6 to transmit (uncompressed) HDMI signalling+control+power. This device transcodes the data and broadcasts over IP.

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

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

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

  7. 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 : http://www.amazon.com/Etekcity-Extender-Adapter-Single-Extension/dp/B0098HU1C8

      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.

  8. 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: http://h-wrt.com/en/doc/video

      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.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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