There are many emerging methods to transport audio and video over IP networks and one of those approaches is called AVB (Audio-Video Bridging) or sometimes eAVB (Ethernet AVB).The development of the standard, compliance and other matters is handled by the AVnU Alliance. At Infocomm 2015, we met with them to get an update on the status of video transport.
Overall, there were not a lot of updates to report on the video side.The most aggressive developer, Axon, now has a series of switches and other gear that is AVB compliant for the distribution of uncompressed audio and video in a broadcast environment. Cisco is also developing solutions as we reported on from the SMPTE and CCW conferences last fall. Extreme has a number of AVB compliant switches as well. Barco had a demo at last year’s Infocomm, but it was not showing an update this year.
Company spokesmen explained that AVB is now going to be renamed to Time Sensitive Network (TSN) as this better reflects what it does. It is a synchronization protocol and is different than the SMPTE PTP (ST2059-1) standard, but the differences are beyond the scope of this update. Right now, there seems to be more activity in the automation and control segment and in automotive for the AVB/TSN technology to synchronize multiple devices on the network.
AVB runs over conventional CAT 5/6 or fiber cable but the protocols are different to Ethernet. This means that off-the-shelf networking gear can’t be used today. To implement an AVB solution, there are two options. One is to use an adaptor at each network node to do protocol translation. The other is to add the functionality to IT or broadcast equipment connected to the network, which is what Axon and Extreme have done.
There are four key components to AVB: 1) bandwidth reservation, 2) time synchronization, 3) traffic shaping and 4) configuration.
Bandwidth reservation, for example, allows the user to allocate a percentage of the capacity for the audio and video payload (75% is the default value). Other traffic, which can include data and control signals, is routed on the remaining bandwidth and is unregulated.
In conventional Ethernet networks, there is no concept of time. AVB adds a “grandmaster” timer and a way for devices to exchange timing information for synchronization of multiple streams to deliver video from the source (Talker in AVB parlance) to the sink (Listener) with the same relative timing. Multiple clocks are supported for video and audio, for example, to travel different paths from talker to listener. This is good for sending video at its native rate instead of re-timing it.
Management of the video packets is also different in AVB vs. a standard Ethernet network. In an Ethernet network, the packets are sent in “bursts”, with buffering added to help ensure all packets are delivered. But this adds latency.
In an AVB network, the packets are sent at regular intervals to help ensure that they can pass through the allocated bandwidth without bunching or packet losses. Think of AVB as the dedicated commuter lane on a highway with the cars (packets) spaced at regular intervals. This can result in delivery of video with low latency and low jitter, as long as resources are properly allocated along the full path. AVB reduces this latency to less than 2 ms on a typical seven hop network – a key requirement for many video applications.
AVB also allows the operator to specify a Quality of Service (QoS) level and worse case latency to facilitate the process. Regular traffic can also flow on the network independent of the AVB component (the regular lanes on the highway with stop and go traffic). But to send synchronized audio or video from a talker to a listener using AVB requires all AVB-capable bridges in between.
AVB specifies discovery and configuration methods that establish if a component is AVB capable. When a listener requests a video stream for example, the system will look for AVB compliant components to establish the link. But, if the request would exceed the maximum allocated bandwidth, the request is denied to maintain service for other devices. (CC)
