Wednesday, November 6, 2013

HDBaseT Interoperability Follies

Welcome back to any AV followers who faded away last month while I was posting all fiction all the time. The stories and poems won't entirely go away but we'll start moving into a little better balance between pixels and ink for the nonce. Today I'd like to share a moment to discuss everyone's  favorite transport mechanism, HDBaseT.

For those not in the know, the HDBaseT alliance have defined HDBaseT as a technology for transport of video, audio, power, ethernet, and control over standard category cable. As a point-to-point (as opposed to routable) signals, HDBaseT cannot be routed with standard network switches. With offerings branded by major techm manufacturers (ie, Crestron's "Digital Media" and AMX "Enova" it has become a defacto standard for commercial systems.

Or has it?

The idea of a "standard" is that it should be manufacturer-agnostic. The HDMI output on a Sony Blu-ray player, for example, will work on the input of a Sharp LCD panel as well as it would on a Sony. Is that the case with HDBaseT? Is it, in other words, really a "standard"? The HDBaseT website does boast, in a large banner, that it is "The standard of the future", but the remainder of their text is much more cautious, referring to HDBaseT "technology" or "specifications". Can one grab an HDBaseT transmitter from one manufacturer and receiver from another and expect them  to work together? In an ideal world, the answer would be yes. Those of us who have wrestled with HDCP, EDID, or other HDMI-inspired headaches knows one thing for sure: this is not an ideal world.

For the sake of my own curiosity I tried a little experiment. I had access to transmitters from three major manufacturers: Crestron Digital Media, AMX DXLink, and Extron XTP. The latter is not, to the best of my knowledge, HDBaseT certified, so I'd not expect interoperability from it. The others are, so I would. Is that what happened? Not quite.

The AMX receiver gave me a "green screen of doom" when I tried to connect the Crestron or Extron transmitter to it. This is apparently an HDCP handshake error (as opposed to HDCP noncompliance, which would give a red screen of doom. Doom is the consistent part). This possibly has to do with how AMX handles HDCP authentication, which treats the receiver as a source rather than a repeater. This is nifty in that it bypasses the key limit in some sources (in other words you can run a single Blu-ray player to as many displays as you have outputs for, regardless of its key limit), but might make the receiver more picky in what it looks for from the source side.

This was a fairly disappointing result in that it left the non-HDBaseT certified Extron XTP as my only other receiver. IT might not be "certified", but it does use the same technology as HDBaseT transport solutions. Somewhat to my surprise the Crestron and AMX transmitters both sent HDCP protected content to the Extron XTP receiver. So much for certification.

What does this mean in practical terms? Not all that much. What it highlights is just how similar these devices are. Even in terms of form-factor you get a great deal of similarity between product lines; everyone has a standalone receiver about an inch or so deep to fit behind a flatpanel (or in a wall box), a similarly shaped standalone transmitter, a two-gang wall-mount transmitter,  and modular matrix frames sized from 8x8 up to 32x32 or larger. There's no real practical reason to step out of a single manufacturer's ecosystem other than to prove that you can. Now that we've done so, even that is gone.
A selection of transmitters and receivers

So how does one choose? We're the same place we were back when we did "Switcher-Wars" last year. Do you need Crestron's full audio and USB breakaway? AMX's smaller form-factor and better energy efficiency? Does an end-user with limited programming expertise want to be able to make equipment substitutions and other programming changes through Extron's Global Configurator or AMX's Rapid Project Maker? Is there an existing implementation of a remote-control and asset management system (Crestron Fusion, AMX RMS, Extron Global Viewer) into which you'd like your new system to tie? We've reached a point at which not only are the differences more subtle, but many of them won't even appear on a spec sheet.

The real take away here - for those who didn't realize it already - is confirmation  that the technology is very much the same. In fact, it's the same to the point that if one files off the serial numbers one would have a hard time even telling one apart from another. What this really means is that the best manufacturers aren't just selling the technology; they're selling a solution, including an ecosystem to fit around it and the thought they put in to some of the details that one might miss on a spec sheet.


  1. Thanks for the post. However, sorry to say, but your assumptions of HDBaseT being a standard and your test are simply two totally different things! ;-)
    Matter of fact is: HDBaseT is nothing more than a system bringing Ethernet and HDMI (ok and some power) over a CAT cable.
    1. Transporting HDMI:
    HDBaseT takes a HDMI signal and instead of routing it onto a HDMI connector it gets fed into the HDbaseT transmitter. On the other end it gets "decoded" to the point that it looks IDENTICAL as the signal would come from an HDMI input connector. The good news is, that implementation is very easy for all those manufacturer of endpoints (TV, Proj., etc.) because they dont need to change anything; it simply does not matter if the signal is going in/out via a physical HDMI connector or a HDBaseT chipset.
    However, this implies that HDBaseT has *ZERO* to do with HDCP, EDID, etc. as it is simply a "different cable".
    The reason why your tests failed is simply because maufacturer of intelligent SYSTEMS like Cretron's DigitalMedia do quite a lot of stuff before/after the HD-BaseT *transport* like HDCP key handling, EDID management, etc.
    2. Ethernet
    Basically the same with the Ethernet channel. It gets merged into the HDMI signal on one end and extracted on the other end; to the outside world it is transparent; again HDBaseT is just a "different cable"
    Now there is a new HDBaseT LIGHT out now in the market, which simply does not transmit Ethernet at all. I guess many manufacturers simply dont want to use the features but bring down the price even more. Welcome to the consumer world! ;-)
    Long story short: There is much more going on in a receiver/transmitter than a HDMI to HDBaseT conversion.
    Or would you have imagined, that for example there is a fully managed and VLAN capeable LAN switch built into every Crestron DM receiver? I assume other guys do have similar functionality in order to make all those system functionality possible, which is simply impossible with plain vanilla HDMI.
    Without this, it is simply a different HDMI cable! And we all know how good of a standard it is even when we get rid of the connector! ;-)
    Conclusion: Hookup a HDBaseT projector from Panasonic or so to a DM and you will see, that HDBaseT indeed works but dont be fooled by the marketing lingo, that HDBaseT does anything beyond transmitting LAN+HDMI over the same cable.

  2. Very good points, Harald, and I didn't look at Ethernet or control (as I likely should have).

    There've been mixed success in implenting control via HDBaseT in endpoints using the Valens chipset. See Gary Kayye's editorial here:

    I can draw a little bit of a parallel with CEC control, in which manufacturers are reluctant to use "standard" command sequences in order to preserve a certain synergy within their product line. The problem becomes that this isn't a natural synergy in similar products working together but an artificial one caused by deliberately sabotaging cross-manufacturer interoperability.