Broadcast IT infrastructures
Oct 1, 2010 12:00 PM, By Mark Warner
File-based workflows face internal traffic choices and external bandwidth limitations.
Cowles California Media employed Advanced Broadcast Solutions to develop a plan and budget for the integration of two facilities (KION and KCOY) into a central operation that can be manned by a small staff.
From direct attached storage (DAS) and network attached storage (NAS) to storage area networks (SANs) and beyond, broadcasters have a variety of choices for IT plant infrastructure. Each approach has its advantages and disadvantages, but each solution must handle large files with low latency — and no excuses. Broadcasters do not have the luxury of latency often encountered on the Internet. Whether it is a live shot from across town or footage for an upcoming package, a station's IT infrastructure has to deliver every frame every time.
The move to an IT-based infrastructure for broadcast facilities coincides with the continuing trend toward file-based content acquisition. Tape is still a dominant media for acquisition, but its days are numbered. File-based workflows that begin with acquisition and continue through distribution are becoming the norm.
When it comes to designing a plant, it's about creating a workflow first and then developing an IT system that will accommodate that workflow. Before you start building a digital pipeline, you need to know what you're going to do with it. What will the file format be? What compression will you use? Will collaborative storage for active projects be separate from play-to-air servers? How will you archive? Who will need to access the archive? Once you've established an operational plan for how you will use and manage the data, an assessment of the necessary bandwidth can be made.
Prioritizing packets
Developing a broadcast IT infrastructure in a facility requires familiarity with specific layers of the Open Systems Interconnect (OSI) model. While a complete discussion of OSI is beyond the scope of this article, understanding how to elevate the priority of the broadcast packets within your network is necessary to create a working broadcast system. Three elements of the network are particularly important: virtual local area networks (VLANs), Internet Group Management Protocol (IGMP) and quality of service (QoS).
Figure 1. A network that doesn’t separate business traffic (low time sensitivity) from broadcast traffic (high time sensitivity) can lead to slow file transfers to playout servers.
Select figure to enlarge.
VLANs are needed to isolate the critical broadcast traffic from traffic that is not time critical. VLANs allow segmenting of the physical LAN into multiple virtual networks, which gives the ability to isolate business networks into their own groups. However, VLANs cannot communicate directly with each other, so they must transit through the core IP router or a bridging device to allow cross communication.
Next is the IGMP, which separates the multicast packets into their own domains. IGMP is used to isolate talkative protocols into their own groups. Think of this as being able to separate high-traffic broadcast multicast packets from everyday point-to-point office system unicast packets.
Network success or failure is totally dependent on the proper load management and programming of the core IP router. QoS can limit the bandwidth needs of traffic and prioritize known IP addresses, such as the connection between the traffic server and automation client. It also allows prioritization between application types such as FTP or RTSP. Generally, QoS is set in the core IP router, though some advanced managed switches have the ability to prioritize traffic to and from the core router.
Based on the total available bandwidth of the network, QoS is used to limit the amount of bandwidth available to noncritical systems so that critical systems always have instantaneous bandwidth available for their needs. Not properly configuring QoS will potentially starve the video receiving devices and will cause macroblocking, dropped frames, total loss of video, etc.
Off-the-shelf hardware?
To save money, some broadcasters have built IT infrastructures around commercial off-the-shelf (COTS) equipment. Generally, these systems don't perform as well as IT systems specifically engineered for the bandwidth-heavy requirements of broadcast applications. However, the initial difference in costs can be dramatic, attracting some broadcasters to accept performance from a COTS system that is “good enough.”
Figure 2. Separate business and broadcast IT systems are the ideal configuration for a broadcast facility, but they must be able to communicate over a gateway.
Select figure to enlarge.
Are the upfront savings worth the potential problems and slower performance? Think of a plant's IT network as a sort of interstate highway system for data (specifically video and audio footage, as well as graphics, animations and additional materials). A COTS solution can get data from one location to another, but data will be stuck in the slow lane dotted with all kinds of potholes, some of which are large enough to delay or even stop traffic.
Generally speaking, IT managers are accustomed to handling typical business IT traffic, but they don't necessarily understand the need for prioritizing video assets. For example, as a cost-cutting measure, some IT departments will share one network between the business and video production departments of a broadcast facility. We've even seen IT departments try to configure the video department's needs as a subnet on a house intranet. The results aren't pretty. Video files require significant bandwidth and, depending on your workflow, very high bit rates. Sharing an IT system between business and video production users can slow down file transfers, which means moving content to the play-to-air servers can be delayed significantly. (See Figure 1.)
For example, let's say a broadcast newsroom operation has made a commitment to a particular NLE solution, such as Apple Final Cut Pro, and has also invested in a compatible centralized storage server, such as Apple Xsan. Problems can develop when attempting to transfer files to a commercial-grade play-to-air server. COTS hardware is not necessarily tested and certified to handle the network loading required for HD video. Large files can stall in transit and create bottlenecks for other traffic.
Although traditional IT systems were not designed for the demands of video transport, some enterprise-class systems are getting closer to providing solutions that offer legitimate competition to traditional broadcast equipment manufacturers. Eventually, the limitations of video transport over traditional NAS and SAN systems will be eliminated, and the market will be condensed. At this time, though, systems designed specifically for broadcast applications are the better choice.
Some on-air servers can even be partitioned to serve as a collaborative server, which eliminates transport between servers in the facility. This type of solution is more expensive initially, but broadcasters will be able to provide finished packages on the air faster with no worries about bottlenecks in the system.
Reliability is another important reason to avoid COTS solutions. With daily newscasts and a constant flow of video for editing, broadcasters don't have the luxury of downtime. Video servers specifically designed for the broadcast industry are more reliable and certified for longer mean times between failures (MTBF).
Continue on next page
| Want to use this article? Click here for options! |  |
