AV and IT are converging, but how well does each side know the other? Perhaps nowhere is this lack of mutual understanding more evident than in their respective knowledge gaps on video. In the first feature in a two-part series, we take a high-level look at the ways the two sides approach this crucial subject.
Related: The Technology Manager's Guide to the State of AV Over IP
Gaps in Knowledge
First, we’ll analyze the IT group. Most members of the IT staff have little knowledge of the various video types that are on their network. Mention SRT, SDVoE, or NDI and you rarely get a response. Nearly all have no awareness of the standards that describe the transport of video over IP networks. Likewise, they have not heard of SMPTE or VSF. In a recent interview of the IT staff of a major university, the only term from the list of protocol and standards bodies that the group recognized was NDI. Yet, they are standards driven. Their dominant standards come from the IETF, IEEE, and Cisco. Most of these standards are not about video. Yet, they recognize that the dominant data type on their network is video. Almost all IT network managers are aware that packet loss and jitter can affect video. But few could describe the different effect these two parameters have on ABR video versus IPTV. Also, they rarely consider the impact of latency on the delivery of video. IT cares about latency and loss because they affect TCP throughput. Plus, TCP carries ninety percent or more of their business traffic.
Let us turn our attention to the AV group. They do not realize how important it is to monitor traffic flows on the network. They have little knowledge of the tools that IT uses to monitor those flows. Such tools have been in use for decades. Companies that make monitoring and troubleshooting tools like Viavi and Netscout are not discussed on the AV show floor. AV pays little attention to buffering the packet flows unless the discussion is about the receiver’s buffer. IT is primarily concerned with network buffers. (See this issue’s Byte-Sized Lesson.)
Contrasting Concerns
What factors of the network are of primary concern to IT? There are at least three. First, will the traffic be bursty like adaptive bitrate or a constant, high-volume stream like IPTV? Bursty traffic hurts TCP applications. High-volume streams do not share well with other high-volume applications. Second, if a new application such as a video server comes on the network, how will its network transmissions affect other existing traffic? Will the video disrupt VoIP calls? Will they slow responses to cloud access applications such as Office 365? Will database queries and responses be slowed? Even in a car dealership, there will be significant dissatisfaction if the parts database queries slow down due to the deployment of a new streaming server. Also, does this new application need a separate network or at least a separate VLAN? If it needs to be segregated into a separate VLAN, should routing between that VLAN and the rest of the network be permitted?
Turning now to the AV concerns, what do we see as their primary focus? We will base this on the discussions that happen in magazines like this one and what you often hear on the floor at trade shows like InfoComm. Most are discussions and debates about three concerns: output quality, the necessary network infrastructure for each audio or video type, and video characteristics. The latter includes color, bit depth, and luma and color sampling method. In discussions with many IT departments, I have never heard one of these factors mentioned.
Standards, Standards, Standards
So, because both AV and IT claim to be standards-based, can we find common ground there? Not in this case. We mentioned previously that each group has little knowledge of the other’s standards. This is understandable. The AV standards come in two forms. One form, usually called dejure standards, comes from the Video Services Forum, SMPTE, the MPEG group, or IEEE. Defacto standards come from Audinate, NewTek, Wowza, Haivision, and other manufacturers. The IT group depends on the IEEE, IETF, TIA, and defacto standards from Cisco. Note that the IEEE is the only standards body to which both adhere. The problem is that they follow different IEEE standards. Even within the 802.1 family that specifies AVB, the IT industry uses the part that specifies VLANs. In a discussion with the university IT department of a major university, not one person on the call had ever heard of IEEE AVB or TSN.
What tools are available that could help AV and IT understand the video traffic on their networks? There are three types and they have varying functionality relative to audio or video. Protocol analysis tools, often called sniffers, are capable of capturing packets and decoding or dissecting them. They interpret the fields in each packet and describe their meaning in a user-friendly manner. In the IT environment they have been used for decades and include products like Wireshark, which is free, and Viavi Observer, which can cost thousands of dollars. Typically, these tools also include functions such as listing the address of network devices, showing the level of activity of the devices, and providing many graphs that help describe the network traffic flows. They will report bandwidth use, loss, jitter for certain traffic types, and detailed analysis of TCP sessions. Unfortunately, many are weak in the analysis of video. Most of the typical IT tools see RTP as the potential indication of video. However, they do not recognize ABR, IPTV, SRT, SDVoE, NDI, NVS, or other video flows. Surprisingly, the one exception is Wireshark. It can dissect both MPEG Transport video and SMPTE 2110 streams.
Some tools are focused primarily on monitoring the flows and assessing the quality of the output. They also vary considerably in price and functionality. Some that are cost-free monitor a single stream. Others, whose price can easily reach thousands of dollars, can monitor many streams and let you observe the videos on a Hollywood-squares screen. TSReader, a free products from Telestream, can be costly.
The third family of tools is called network emulators. These are designed to allow the emulation of a real network in a lab or the emulation of a network segment added to a real network. For example, they could be used for pre-deployment testing in a lab setting. The user could simulate a connection between their video server and the playout device. They could also add elements with varying loss, jitter, and latency characteristics. Products in this family come from PacketStorm Communications, ITrinegy, Netropy, and others. They also vary significantly in price, based to a great extent on their capabilities. For example, some of these tools can take real traffic from a network and retransmit it in a lab setting over an emulated network. This is an important feature if you are developing a new transport method. With some, you can play the stream through your emulated path, change the characteristic of the path, add competing traffic, and play it again. You can even add real playout devices to see what the user experience will be like under each scenario.
The next part in this series will discuss the different areas that are involved heavily in video transport: broadcast, pro AV, and enterprise distribution. We will address the standards for each of the groups and the potential role for pro AV to act as a bridge between the broadcasters and the enterprise users. Also, we will thoroughly inquire into the tools manufactured for each group to emulate, analyze, monitor, and troubleshoot video flows.
