Pixels and Erasable Ink - Could I be wrong?

Those of you who follow my musings on the world of professional AV know that I can be skeptical at times. I'm skeptical about AVB. I was skeptical about video over IP. I'm skeptical about the continued value of HDBaseT. What I try not to be is cynical; it's good to start off questioning new assumptions, but it's equally important to balance those questions with an open mind. Technology, after all, is not a static thing. What made sense yesterday might be pure folly tomorrow. With that in mind, I'd like to tell you about two points on which I might be wrong.

AVB - Is it dead yet?
This is a question one of my colleagues asked me last year at the Infocomm trade show. The question had a pleading tone, as if wishing for what increasingly looks like a zombie technology to be put out of its misery. We'd all seen the same proof-of-concept video-over-AVB streaming demo two years running at that point. We saw one major DSP manufacturer choose an audio transport system based on AVB while nearly everyone else chose Audinate's Dante protocol. We saw the major manufacturers of network switches decline to support AVB year after year. In short, we saw a very promising technology losing a format war.

Or did we?

After years wandering down the same dead-end path, the AVNu alliance (the people behind the creation of the AVB standard) finally realized their biggest problem. It's a problem unrelated to bandwidth requirements of low-latency AV transport, unrelated to network traffic shaping, unrelated to questions of layer 2 or layer 3 protocols. It's so simple a problem that we can all understand it, and we all should have seen it sooner.

The problem is the name.

The problem is that the name leads to comparisons like the one I just made with Dante which is, to be honest, a poor comparison.

We've all known for years that AVB is not a streaming technology; it is a suite of IEEE 802.1xx standards for bandwidth reservation and time synchonization over networks. Solving the "lip sync" problem for separate audio and video streams is one application of this technology. It is also of vital importance, for example, in syncing control and sensor signals for electronically controlled manufacturing processes. Whatever transport technologies we use today can be enhanced by access to the tools within AVB, not replaced by them. The debate between AVB and Dante is a bit like saying that you don't believe that a series of new high-speed carpool lanes  would make a difference because you're driving a Prius. It's a non-comparison.

The problem is that the name "AVB" for "Audio Video Bridging" sounds like a transport technology and has been, to a very large extent, marketed as one. What does AVB do? It creates a bridge over which one sends audio and video signals.  Audio manufacturers with AVB compliant products don't help this when they describe "audio over AVB" not "network audio taking advantage of AVB's timing protocols".  I know that AVB is a suite of 802.1xx standards, but when I hear the words "Audio Video Bridging" my brain sees a transport protocol. As is often the case, language informs thought.

To solve this problem, AVB has picked up a new name; TSN or "Time Synchronized Networking". This divorces AVB from the "A" and the "V", aligning the language with what the standard actually is.

So will our future AV over IP systems take advantage of these new protocols? Perhaps - if those are the systems we build. Or perhaps there won't be a large enough volume of networks requiring time synchronization for these tools ever to be widely adopted. Time will tell.

For AV transport, there is another option.

HDBaseT - A Bridge to Itself?
I, and many others, have described HDBaseT as a "bridge technology" between yesterday's point-to-point systems and tomorrow's video over IP systems. In an earlier post I spoke about the value of HDBaseT and what advantages and disadvantages it has over IP video. Most of that is absolutely correct today. It might be the opposite of correct tomorrow.

The bridge is a metaphor

I had the pleasure of a terrific conversation with Micha Risling, marketting director of the HDBaseT alliance. Mr. Risling pointed me to part of the HDBaseT 2.0 specifation I'd admittedly payed too little attention to at the time. Take a moment to look at this image from the HDBaseT alliance website, comparing 1.0 to 2.0.

Does that look familiar to you? It should; it's quite similar to the OSI stack. For years we've thought of HDBaseT as something that looks like an IP network but isn't; it's a point to point transport technology using the same physical topology - but no the same logical topology - as IP.

Or is it?

This layercake looks familiar
(image from HDBaseT.org)

There is, as of the release of the 2.0 spec, no reason that HDBaseT cannot exist in a packet-switched environment similar to any other network, using "HDBaseT switches" more akin to the network switches we know and love than the AV matrix switches of today. Such switches would use an internal addressing scheme, signals would be routable between switches, and the overall scalability problems of current HDBaseT systems would be a thing of the past. The HDBaseT alliance sees their dedicated video network as a better solution than a "converged" network for AV transport. Bandwidth requirements for uncompressed video - especially at resolutions of 4K or beyond - could be, at the very least, challenging to implement on a larger network. HDBaseT is purpose-built for video transport with, they claim, better cross-network optimization than the IP we know and love.

Will all of this come to fruition? I don't know; what I DO know is that the chipset for such an "HDBaseT switch" is in development today, and that we might not be that far from seeing HDBaseT as a packet-switched technology rather than point-to-point as is currently the case.

If HDBaseT has a "language problem", it's the opposite of the problem AVB has; as HDBaseT sounds enough like "100BaseT" (fast ethernet) and "1000BaseT" (gigabit ethernet) to cause confusion, we've all worked very hard to remind ourselves that it is a very different thing with a different logical topology. That it might not be so different after all is, to say the least, jarring.

Will the benefits of HDBaseT switching balance the challenges of deploying and maintaining parallel but separate networks? Will the demands of video on converged networks push us to separate networks anyway? Many questions remain and the devils are, as always, in the details.

Whatever may come, we'll talk about it when it gets here. You can expect to hear me question it, but with an open mind and open eyes.
Time will tell if my initial guesses are proven right or wrong.