Video

The Same, But Different

It’s all about the acronyms.

Contrary to what many people think, HDbaseT and AVB are not the same thing. But then again, there’s more confusion than ever about standards these days….

Recently, there was a LinkedIn thread with the intriguing title, “Who loses in the HDBaseT vs. AVB debate?” When I logged in to read it, I couldn’t resist commenting that comparing HDBaseT to AVB (AV Bridging, for those readers who aren’t up to speed) was like comparing apples to oranges, and that any journalist who equated the two had no idea what he or she was talking about.

Here’s why. HDBaseT, which is fast becoming an industry standard, is a signal multiplexing process that combines HDMI video and audio (uncompressed, I should add) with 100BaseT Ethernet and low bitrate RS232 and infrared (IR) command strings.
In other words, all of this stuff is packetized into a stream of data, using custom ASICs, transmitters and receivers. The resulting overstuffed pipe of signals then travels over structured wire (up to 328 feet reliably, if shielded Cat6 cable is used) and is then demodulated and “de-muxed” back into the five original signals.

When HDBaseT first appeared at CES a few years back, the inventor (Valens Semiconductor) promoted the technology as “5 Play”: five common AV signals packed together in one envelope. And the transmission medium of choice was structured wire; more specifically, Cat5e structured wire. Why? Because so many people in our industry were already using it for AV signal extenders and can easily terminate it in the field.
The original target was residential installations, although I don’t know of too many existing homes that have structured wire pulled through their walls. The Valens concept was to preserve the full usable bandwidth of HDMI (about 8Gb/s out of the 10.2Gb/s total streaming rate for version 1.4) and piggyback a few useful things like bidirectional Ethernet and control signals.

Truth be told, Valens could just as easily have used fiberoptic cable to do this instead of structured wire. They could also have opted for coaxial cable! But the wide familiarity with Category wires in our industry, coupled with a general phobia of anything to do with the words “fiber” and “optics” meant that this new format would have a better chance of success if it used wire and connectors that already resided in everyone’s comfort zone.
Summing up: HDBaseT combines HDMI video and audio—uncompressed—with RS232, IR commands (both are serial data strings) and symmetrical 100BaseT Ethernet (although you don’t have to use that part) and extends up to 328 feet as long as you use Cat 6 shielded cable (as we’ve found out).

Now, let’s turn to AV Bridging. The AVB standard was developed by the IEEE to prioritize and organize streams of audio and video over wired TCP/IP networks. To quote from the title page, “This standard defines profiles that select features, options, configurations, defaults, protocols and procedures of bridges, stations and LANs that are necessary to build networks that are capable of transporting time-sensitive audio and/or video data streams.”

When streaming audio over a network, it doesn’t do you any good if the audio packets arrive out of order, or arrive with excessive latency. Hence; the four “core” protocols in the AVB standard (802.1 BA, AS, Qat and Qav): Here are the IEEE designations for each protocol and their definitions:

  • IEEE 802.1 BA: Audio/Video Bridging (AVB) Systems (IEEE Standard for Local and Metropolitan Area Networks)
  • IEEE 802.1 AS: Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks (LANs); a precision time-synchronization protocol
  • IEEE 802.1 Qat: Stream Reservation Protocol (SRP); an end-to-end bandwidth reservation protocol within a bridged LAN
  • IEEE 802.1 Qav: Forwarding and Queuing for Time-Sensitive Streams; AV traffic scheduling enhancements for a mainstream Ethernet and other network switches.
  • Two additional protocols support porting of FireWire to AVB (IEEE 1722) and also extend Real-time Transport Control Protocol (RTCP) for Real-time Transport Protocol (RTP) over AVB networks (IEEE 1733).

OK, enough alphabet soup. RTP is a protocol that is used to stream video and ensures that packets arrive in the right order. Otherwise, you wouldn’t be able to watch internet video reliably. TCP/IP, the most common internet protocol, works more like an “as long as all of the packets get there eventually” system. That’s great for emails and exchanging files, but not so good for streaming video.

Hence, we have RTP. What AVB adds is a process whereby someone sending an audio stream (the “talker”) can request a reservation using Stream Reservation Protocol to ensure enough bandwidth is available all the way through any local networks, switches and servers to the person receiving the file (the “listener”). These protocols work to synchronize all servers and switches in the signal path and get that file through as quickly as possible, with minimal latency.

Make sense? AVB is, from the start, a set of protocols for Ethernet audio traffic, using wired networks only (the wireless standard hasn’t been released yet). AVB can only handle baseband video and audio packet formats, not uncompressed display modes like HDMI and DisplayPort, and it doesn’t support RS232 or IR commands. But AVB does travel over structured wire and optical fiber.

Got that?

  • HDBaseT = Multiplexed AV signals over structured wire.
  • AVB = Ethernet protocols for real-time streaming of video and audio files.

 

All they really have in common is the structured wire part. HDBaseT’s transmission distance is limited currently to 328 feet, but AVB files can easily travel around a campus-sized LAN, or even through longer network paths.

Now, AVB does have some challenges, not the least of which is the bandwidth requirement for sending video files, which are a heck of a lot larger than audio files. HDBaseT transports uncompressed HDMI 1.4 streams, which are typically 4+Gb/s for 1080p/60 video with 8-bit RGB color. Try that over your LAN: It won’t work unless you first convert those video files to a format that can be compressed for greater efficiency, such as AVC H.264, the new HEVC H.265 codec or Google’s royalty-free VP9 codec.

Frankly, you’d be nuts to transmit uncompressed display signals over long distances anyway. With H.265 or VP9 codecs, you could stream a high-quality 1080p/60 video at less than 4Mb/s, which means you could pack plenty of these streams into a 10 Gig Ethernet pipe. It’s easy enough to decode the video streams at the receiving end and convert them back to full-bandwidth HDMI signals, and a much more efficient way to move video around.

Why not just use RTP? From Wikipedia: “…RTP is designed for end-to-end, real-time, transfer of stream data. The protocol provides facilities for jitter compensation and detection of out-of-sequence arrival in data, which are common during transmissions on an IP network. RTP allows data transfer to multiple destinations through IP multicast. RTP is regarded as the primary standard for audio/video transport in IP networks and is used with an associated profile and payload format.” The only thing missing here is some sort of stream and bandwidth reservation request.

So, is AVB reinventing the wheel? Possibly. I’m not a big fan of mixing TCP/IP and RTP AV traffic in the first place, unless the network has lots of speed. And with fast networks, we can already encode MPEG4 and HEVC with IP headers and use RTP through UDG to ensure high QoS. (AAACK! Too many acronyms!)

[button type=”large” color=”white” link=”http://viewer.zmags.com/publication/e5bf9b39#/e5bf9b39/1″ ]Read the Rest of this Issue[/button]

Sound & Communications: March 2021 Digital Edition
Previous ArticleNext Article
Send this to a friend