In Part 1 of this series, we discussed the benefits of AV-over-IP (AVoIP) as compared to legacy methods for signal distribution. We provided a sample system with three parts:
- Image magnification (IMAG)—putting the presenter in the same space as the display and sound-reinforcement system to make him or her visible and audible in a larger venue.
- On-site signal distribution to other rooms in the same building.
- Sharing AV to remote locations over the internet.
Each portion of the scenario presents unique network-related requirements. IMAG requires fast delivery to minimize disconcerting delays (latency) between the live presenter and the onscreen image. Local distribution outside the live space requires relatively fast delivery, without interfering with other local network traffic. Remote distribution requires a format that is compatible with sharing between networks, and that is recognizable by potentially unknown receiving devices.
Manufacturers float different terms into the market in hopes of clarifying the capabilities of their devices and their potential suitability for various scenarios. The language sometimes creates confusion or fear, unfortunately. In Part 2, we break down technical terminology, take a quick glimpse at some underlying protocols, summarize popular transport methods and set the stage to tie it all back to our sample system. In future installments, we will transition from the academic to the practical.
The OSI Model: Peeling Back The Layers
Frequently, conversations about IP signal distribution include statements related to network “layers.” The Open Systems Interconnection model (OSI model) breaks down networking into seven different layers to describe what happens in any network. Each layer provides various functions in moving data from place to place. Manufacturers commonly ascribe a layer to a product to imply capabilities of the equipment. Data travels from layer to layer, adding or reading additional information to perform the necessary functions. For AV integrators, knowing about layers helps in equipment selection and communicating with network administrators.
The following is a brief overview of OSI layers:
Layer 1: The Physical layer includes cables, connectors and wireless signals responsible for moving electrons, radio waves or light pulses between two points.
Layer 2: The Datalink layer includes network switches. A device described as “Layer 2” typically provides the ability to share data with other devices connected to the same network switch—but not necessarily with remote locations on other networks.
Switches include two general classifications: unmanaged and managed. Unmanaged switches, such as what you might have at home or in a small business, provide minimal configuration options. Plug in your network devices and they just work. Managed switches, on the other hand, are standard in organizations where IT departments require more control of the network.
Every network device in the world has a unique Media Access Control (or MAC) address. MAC, in this case, has nothing to do with a computer brand; rather, it is the unique physical identifier for a specific networked device. Layer 2 switches read the MAC address of connected devices and build an internal lookup table of the address connected to each port. When data arrives for a specific MAC address, the switch knows which port requires the information, minimizing data collisions otherwise caused by blindly sending all data to all ports.
Some managed switches allow you to divide the switch into virtual local area networks (VLANs), which are independent networks connected to the same physical switch, with the data isolated in each VLAN. VLANs might reduce some security concerns and bandwidth issues by keeping AV traffic away from other network data; however, they are not always called for. Establishing VLANs falls under the IT department, rather than under the AV integrator, but it’s an essential tool in some AVoIP deployments.
Layer 3: The Network layer implies the ability to route between (or to) other networks, such as the internet. Some signal-distribution methodologies that self-describe as using Layer 3 do not always provide that ability. The Network layer adds information for data priority. For example, your video must arrive in near real-time, but emails can arrive a few moments later; as such, the email may wait for the video to pass.
Layer 4: The Transport layer provides additional reliability through, for example, the Transport Control Protocol (TCP) and the User Datagram Protocol (UDP). You might have to know if the manufacturer uses TCP or UDP when configuring a system. With TCP, originating devices look for an acknowledgment from the receiving node and resend data until confirmation of receipt. TCP provides reliability, but it increases network traffic as compared to UDP. TCP is preferable when connecting to unreliable networks, such as the internet. UDP provides speed and requires less network overhead than TCP does.
Layers 5 and 6: The Session and Presentation layers, respectively, are not part of AVoIP manufacturers’ marketing speak; therefore, we are not covering them here. (I find them very interesting, though. Send me an email and we can geek out over them together.)
Layer 7: The Application layer includes how you interact with the network devices. Applications might consist of browser-based configuration tools, software or even the front-panel controls on a piece of equipment. Again, the OSI model is just a conceptual description, yet it finds its way into everyday conversation.
Underlying AVoIP Protocols
Standardized protocols within current networking methodologies facilitate AVoIP. Differentiated Services (DiffServ) and Quality of Service (QoS) allow IT managers to flag some traffic as having the right-of-way over other data. For example, the audio clock might require priority over email. Knowing when a methodology recommends applying DiffServ helps in productively communicating with an IT manager. We will expand on DiffServ in a future installment of this series.
If email data arrives in the wrong order, it doesn’t really matter, because your email software can put it back together. That’s not so with real-time audio and video. Real-Time Transport Protocol (RTP) maintains the data sequence by placing a time stamp in a UDP header. Real-Time Streaming Protocol (RTSP) and Real-Time Messaging Protocol (RTMP) work with TCP to the same ends. If streaming out through a content delivery network (CDN), such as YouTube, you will have to know which format it requires.
Over The Catchphrases And Through The Weeds
Codecs encode and decode video for distributing via IP. There is no one “best” codec across all scenarios. The encoding process affects image quality, bandwidth requirements, latency and decoder compatibility. Sometimes, choosing an encoding method offering one benefit might necessitate a trade-off in another. For example, uncompressed, high-quality video—say, 1080p/60 eight-bit color at 4:4:4—requires about 4Gbps (four times the capacity of 1Gbps switches) and a sizable portion of a 10Gbps network that is carrying other traffic. So, we have to compress the signal with a codec. The more that a signal is compressed, the more time the process takes or the more the image suffers—or a combination of both of those.
Do you require signals to be displayed fast enough to facilitate IMAG? Can remote participants see the same image slightly delayed, allowing for higher compression and less bandwidth consumption? The encoding method is clearly an important consideration when designing AVoIP solutions.
First up is H.264, which is one of the most common compression methods. One of the best attributes of H.264 is its ubiquity and compatibility in many applications. H.264 encoders, although often suitable for remote streaming, do not encode fast enough for IMAG applications, however. H.265 encodes faster and with higher compression ratios than H.264. Due to the additional efficiencies, manufacturers position H.265 for use with 4K. Both H.264 and H.265, however, work with HD and ultra-HD video. Growing adoption of H.265 will contribute to future compatibility. For now, H.264 still dominates.
JPEG 2000 typically encodes faster than both H.264 and H.265, but it does not compress the data size as much. As such, JPEG 2000 wins when latency is more critical than reductions in bandwidth are.
H.264 and H.265 use inter-frame compression methods, which means they look at the image across multiple frames of video and then create a single full frame of video, followed by additional data that contains only changes to the original video. JPEG 2000, on the other hand, is an intra-frame method, whereby it compresses the data within each frame and then transmits full frames of compressed images. Because JPEG 2000 sends the entire frame, it provides some additional image reliability if any data loss occurs. In addition to higher bandwidth utilization, decoding JPEG 2000 on a PC instead of a decoder appliance might require more processing power as compared to H.264 or H.265.
So, what does all this mean for you? In simplified and idealized terms, pick your encoder/decoder combination based on speed, image quality and bandwidth requirements. You might have to run multiple encoders to create different signals for different applications (i.e., real-time IMAG, near-real-time local streaming and remote streaming with additional latency). Connect AV sources to the encoders and the encoders to the network. Then, connect decoders at the destinations to the output devices…. But (and there is always a “but”) you should never connect to a network without having a thorough conversation with the customer’s IT department.
In Part 3, we will dig deeper and expand on the earlier-discussed concepts. IT managers are protective of their networks for good reasons. Working with IT people who appear to speak a different language might seem daunting to an AV professional. Mutual apprehension might even be enough to drive each party to separate corners and keep them there. Understanding the concerns of IT people on their terms is vital for working toward the mutual goals of securely and reliably serving end users.