Turner Broadcasting monitors all on-air functions with display solutions for its all-digital network operations center. Photo courtesy of Barco.
Within the past few years, information technology (IT) equipment and software have become critical components in broadcast systems. Like information systems (IS), IT has its roots in management information systems (MIS). This technology, which was once just a computer in accounting, has become pervasive in content creation, distribution and delivery.
Products in today's broadcast systems are almost 100 percent digital. There is great commonality between the products in computer and communications systems and the products in modern broadcast systems. It doesn't take rocket science to build one; you can do it with the same basic knowledge, practices and skills that engineers use to build traditional broadcast systems.
Building a system
This article is the first of six articles on using IT in broadcast and production environments. The objective of the series is to acquaint engineers and technical managers with IT and show them how they can use it in broadcast engineering and technical operations. The series will cover local network equipment, storage, cabling, inter-facility networks and testing of systems used to create, distribute and deliver content.
Digital technology allows broadcasters to create virtual channels and to compress content to fit within a transmission channel's capacity. These two characteristics impact picture quality and sound fidelity. Knowing what is required at the reception point, the task becomes defining the parameters for an entire system.
On a conceptual level, building an IT system is no different than building a broadcast system. The differences are in the functions, capabilities and limitations of hardware, software and applications hosted on the system. If you are a successful broadcast-system builder, you can handle IT systems. Where appropriate, you can integrate it with network services to reduce operating cost while creating new revenue.
Figure 1. Building an IT system from start to finish involves different levels of risk along the way. Click here to see an enlarged diagram.
Keep in mind three rules of thumb. First, the sole reason someone builds an IT system is because he believes it will make money. Second, great ideas turn into money only after someone builds something. Third, the most important aspect of successfully building a system is risk management. Figure 1 shows the process of building an IT system from start to finish, and the level of risk the builder encounters during the process.
Designing the system
Building a system from start to finish is carried out in two phases: planning and design, followed by construction or implementation. The typical approach to new projects involves working with finance and program planning or news to create a plan, often called a capital appropriation, capital-spending request or something similar.
Figure 2. The effort needed to document a project from concept to completion varies with the project’s size and complexity and changes as the project progresses. Click here to see an enlarged diagram.
Documenting the system
Most organizations have a project-approval process that supports a capital-spending request. Typically, this process runs under a one- or two-page accounting department form. The form is likely to be supplemented by additional pages containing technical and financial details sufficient to convince management to approve the project. The level and content of detail required varies. Expensive projects require a lot of detail and evidence convincing of its value. This phase is considered complete when management signs off on the proposal. This means that the finance and accounting departments recognize the commitment and direction of management and operate accordingly. It also means that the engineering, purchasing and other departments can take the required action to complete the proposed project.
Figure 3. This high-level block diagram shows the architecture of a DTV system and where the proposed project fits within that architecture. Click here to see an enlarged diagram.
The most effective and efficient design starts when someone proposes the project. Even if your organization currently operates similar systems, a certain amount of design must be undertaken before costs can be estimated and a budget prepared. Properly documented, this work can dovetail with construction, test and operational plans.
How many times have you been asked to fix a problem, only to find out that the documentation for the system or component is insufficient, incorrect, out of date or nonexistent? Someone once said that the difference between craftsmanship and engineering is documentation. Moving from a bright idea to operational reality requires a certain level of documentation. At least, there should be a block diagram, a list of system components or a parts list, cable and wiring lists, and a layout of the rack(s) and floor. Some cases may require a technical operations manual that you can use to describe system software, utilities and application software. Supplementing this, of course, are user manuals provided by equipment and software suppliers. Documentation is absolutely necessary to support a capital appropriation request and to front-end design documents.
Figure 4. This functional block diagram of a content-creation system shows the level of detail necessary to support a capital-appropriation request and to front-end design documents. Click here to see an enlarged diagram.
Figure 2 lists the documentation process and requirements for a successful project. It highlights all the activities and work required to document a system build from concept to operational reality. Most importantly, it shows how documentation matures as a project reaches completion. The project's zenith — its most desirable state — is when it is complete and operational. At that point, the documentation turns into a final release that matches the final configuration and normal operational status of the system. Lastly, notice that the documentation effort level varies directly according to the size and complexity of a project. It also increases as the project matures. Ideally, project documentation is most valuable when it is carried out in a seamless fashion from the initial idea through operational reality almost without regard to the state of maturity. Conducted properly, the documentation will support the next great idea when it becomes necessary to upgrade, change or replace the system.
Figure 5. Inter-facility content-transport links are usually provided by telcos, cable networks or other outside service providers. Click here to see an enlarged diagram.
Defining the system
It's important to know where the proposed project fits in the overall architecture of the business. Is the project a part of a national, regional or state-wide network? Perhaps it is a growth facility such as an editing suite or studio production system. High-level block diagrams can offer perspective and clarify where the proposed project fits in the overall architecture. As an example, Figure 3 is a high-level block diagram showing the architecture of a DTV system. It illustrates key components and operational signal flow for all three stages in the signal chain: creation, distribution and delivery. The drawing also illustrates both intra- and inter-facility networks. If the proposed project is a content-creation system, for example, the high-level diagram can highlight that aspect of the architecture.
Figure 4 shows a simple block diagram of a proposed content-creation system. In this particular project, the system uses uncompressed SD and HD video and digital audio, offers digital recording and playback and can compress content for live transmission or feeds across a digital network where the cost of bandwidth is a constraining factor. This is the level of detail typically required to support a capital-appropriation request and to front-end design documents.
Table 1. Displayed is the range of payload bit rates across the program content food chain. Click here to see an enlarged diagram.
If the proposed system or project has not been defined previously, that's task number one. It's imperative to write out a description of the system, accompanied by block diagrams, an equipment list, and rack and floor layouts. Organizing a spreadsheet or database to house wiring lists and circuit IDs round out a documentation package that you can store electronically, print when necessary and easily maintain when changes occur. Documenting exactly what the system will do and the key things it will not do is critical to gaining acceptance by those using it to perform the intended functions.
When proposing to integrate IT into a broadcast or production facility, it's important to consider how the facility will transport the content. This includes investigating topics such as transport modes and media, service providers, traffic levels and bandwidth requirements, and interfaces and standards.
Table 2. Listed above are the characteristics, interfaces and payload bit rates found in DTV systems. Click here to see an enlarged diagram.
Moving content around during the creation process and through distribution and delivery requires some type of vehicle. There are two ways to move content: physically on tapes, disk packs or on other portable media, or virtually through network connections. Content can move within the same facility (intra-facility) or between two or more facilities (inter-facility).
IT considerations
Intra-facility links are typically baseband wire, coax or fiber. Inter-facility links are usually provided by outside vendors, typically telcos, cable or other networking providers. An example of an inter-facility link is the typical STL. (See Figure 5.)
Transporting content
Content coming from the production process is typically digitized. Real-time transmission requires a minimum bitrate of 270Mb/s and can be as high as 1.485Gb/s. Carrying these kinds of signals between two points involves coax, twisted pair, fiber and combinations of various kinds of networks. Distributing and delivering it brings compression into the picture. Table 1 shows the range of bitrates required to carry content payloads in real time. Assuming a network capable of carrying these bitrates, the same transmission channel can be used to transfer files, or move content in non-real time.
Interfaces between system elements are typically standardized. The most common interfaces are covered in SMPTE or AES/EBU standards. Compression is typically MPEG-1, MPEG-2 or MPEG-4. In the United States, ATSC and FCC standards also are applicable. Table 2 shows the characteristics, interfaces and payload bit rates found in DTV systems.
Traffic levels and bandwidth requirements
A key to effectively using IT technology in any broadcast or production environment is to understand where IT can and cannot be used effectively. Some of these aspects will be covered in the next article in March's issue.
Interfaces and standards
Fred Huffman is a systems engineer for the Torino Olympic Broadcast Organization. He is author of “Practical IP and Telecom for Broadcast Engineering and Operations,” published by Focal Press.
