Centralcasting is a product of our time. It fulfills the need to supply many channels and the technology to deliver them nationwide and much further afield. Any centralcast operation must have the storage, playout facilities, asset management and telecommunications to deliver programs on a large scale. With the entire centralcasting program assets at hand, it could expand operations by opening services to new distant markets.
Operating further afield seems attractive, but there are extra costs involved. Getting the video there might involve the expense of multiple satellite hops, and regionalizing the station’s output for advertising, channel branding, time-shift and subtitles adds more cost. Ultimately, centralcasting is about reducing costs by using fewer staff and less technical equipment to service, for example, a whole TV network. The costs of expanding to another region would be looked at carefully and weighed against the potential revenue that is mostly raised from advertising aimed at the new audience.
Increasing competition is squeezing channels’ advertising revenues, and they will be looking to cut costs in all areas, including playout. Such calculations are necessary, but sticking to the centralcasting norm is not. “Our time” is a moving target, and modern technology can change the workflow for the operators and the money for the accountants. To better address areas seen as unprofitable because of costs and low potential viewing numbers, a fresh approach is needed to rebalance the economics in favor of a fully branded service with local content while still running the station as a part of the centralcasting operation.
Distributed storage
The whole ethos of centralcasting revolves around a central store for all programs played out to the network’s stations for each local channel’s schedule. This workflow assumes that the cost of replay, equipment and its operation is high. That was true for VTRs, but today’s computer hard disk players are low-cost and run perfectly unattended. Centralcasters now have their media on central disc-based stores for lower equipment and running costs.
Given the above, it could be better to place some storage at the remote stations and transfer programs and other material prior to transmission time. This then is replayed to air from the local storage according to the station’s schedule. Distributed storage makes possible many changes to the classic centralcast model. Given solid reliability and more automation, the remote can operate unattended to further reduce costs.
Delivery
The traditional centralcaster’s live playout to each supported channel may no longer be required. For file-based media, the replay from the central store no longer needs to be in real time. (See Figure 1.) This opens the door for the use of the Internet as the only link to the remote station. It can be the only delivery medium for content, schedules, control, monitoring, subtitles and even sending local content back to the broadcast center. This link has a worldwide reach and costs a couple hundred euros per month rather than the several thousand a satellite or fiber connection would cost.
Exactly what data speed is required depends on the media format used at the remote location, the amount of new media needed per day, the bit rate chosen for playout and the available Internet capacity. Program data rates for MPEG-4 IBP are typically 4Mb/s to 6Mb/s for SD and 8Mb/s to 12Mb/s for HD (add 50 percent for MPEG-2) — the more the better. Another factor is the rate at which programs are churned; repeating the same material all week requires much less data than changing every day. The Internet provider, the grade of the service (consumer, business, etc.) and the bit rate can be selected according to data transfer volumes and budgets.
System design
There are any number of possibilities for the design of a remote, unattended playout system or edge server. (See Figure 2.) Choices depend on the facilities of the centralcaster and the requirements of the remote broadcast service. A modular equipment design and the integration of many third-party devices are both essential. Having the major elements as standard IT-based platforms helps the wide integration and keeps costs down to IT prices. Even though the system is IT-based, system designers need to understand the needs and technical standards of the broadcast television industry.
Budgets, the security of media and the continuity of output influence the design. Fail-safe features such as error detection in data transfers, RAID-protected storage, redundant power supplies and playout servers complete with automatic switchover all cost more but help to maintain service. Above all, the basic system modules — ingest, playout, storage, on-air graphics and subtitles — must be highly reliable. Otherwise, the idea of remote unattended operation makes no sense.
A typical design includes interfacing with the centralcast traffic system, conversations between the remote station and the central traffic system, sending required media and mechanisms to ensure against data degradation and firewalls at each end of the Internet link to keep the data and media secure. The bulk of the remote station comprises tried-and-tested standard playout solutions complemented with items such as monitoring and Internet communications, as well as software to allow the necessary conversations with the centralcaster.
Workflow
Workflow may start with a daily playlist created in the centralcaster’s traffic system that is integrated with the media asset management (MAM) system. The list is delivered to the remote playout servers and converted, where necessary, to its native format. Error detection algorithms can check that the file matches the original. If using a fully redundant playout, then the list can be sent separately to both and crosschecked. Then, at worst, one server should play to air correctly.
Details of the workflow and file handling will differ according to each broadcaster’s needs, but they might be like the following example. After the remote site has received the daily playlist, it checks for the media required to fulfill the list, searching its local store accordingly. Any content that is missing is flagged, and the system generates a “missing items list,” which is sent back to the MAM. This routine is repeated until all the required media is present in the remote’s storage.
The MAM is responsible for finding and delivering that media. It may exist, but the required video or file format of the remote differs from that used by other centralcast channels, e.g. SD or HD, bit rate, MPEG-2 or MPEG-4. First, the MAM checks for the media available in the correct delivery format. If it is not found, it then searches for the media in any other format, preferably at a higher quality or bit rate than is required by the remote. If something is found, the MAM sends the media for file transcoding and then to the remote for delivery to the playout server or servers. If the media is not available, the MAM generates a capture list for the media to be ingested, transcoded and delivered.
The outputs of any unattended remote playout stations should look every bit as complete and regionalized as those delivered from the centralcast and broadcast via local channels. (See Figure 3.) These may include graphics, from the basic channel ID bug/logo to multilayer on-air graphics; text rolls and crawls; live updates such as SMS-to-screen, voting and gaming; and displays driven from live databases, such as financial information, traffic, etc. Typically, such graphics are delivered within a template, simplifying live operation to the addition of text or pictures to complete the unique presentation. Such activities can be scheduled in the traffic system, and any new designs can be downloaded as required.
Subtitles and closed captions can be prepared at the centralcast or independently and sent to the remote playout, which will associate the text in sync with the relevant program material.
For confirmation of playout, the server can produce as-run logs that are returned to the traffic system for reconciliation and billing. Compliance recording can also be performed and the results streamed back to the centralcast, if required.
Traffic management is a further housekeeping requirement at the remote. On the input side, this automatically moves the media arriving on the local file transfer server to the playout servers’ hard disk drives. Another automated routine is the removal of “old” media from that same server. By scanning daily playlists and local drives, it can delete media not required for, say, seven days hence. If the media is required later, it can still be copied again from the file transfer server or MAM. Purging a list of items from both the file transfer server and playout servers can be commanded by the centralcaster.
Monitoring and control
Remote monitoring is imperative, especially where channels cannot be viewed by a backhaul feed. The status of the playout and graphics servers can be monitored, and the resulting data can be sent back to the centralcast to raise any necessary alarms. All the remote servers are also connected to a VPN, accessible from anywhere according to the firewall’s rules. Remote video and audio monitoring via the Internet can also be devised as well as monitoring catastrophic failure of the main and redundant playout servers.
Protection
Various levels of protection can be applied to suit. Redundancy of servers and power supplies is common. The Internet connections go via a firewall and file transfer server and can include a file transfer system agent to accelerate transfers, as well as using multiple Internet paths and so allowing checking validity of files. On the playout side, a smart switch can be added to monitor the main video and audio output, and it can automatically switch to the backup in the event of a failure.
Advertising
Although global brands may be relevant, most advertising time will be occupied by more local commercials. For commercials, two playback approaches can be used. (See Figure 4.) One involves opting out of the program feed and inserting the region’s local commercials from a local player, cued by tones. The other approach avoids the opt-out by including the commercials within the playlist.
Reducing costs
Remote playout systems that run unattended using Internet connections introduce many new opportunities for lowering the cost of centralcasting. They are an economical way to extend services to viewers anywhere around the world, complete with local branding, and they can reduce dependency on fixed live-video links. In all cases, distributed storage and servers open the door for new ways to run centralcasting. Each application will differ, at least in detail, so modular scalable systems and detailed system design are just as essential as reliability.
Don Ash is director of sales at PlayBox Technology.
