File-based workflow
Jul 1, 2010 9:59 AM, By John Luff
Human factors affect the adoption of new technologies.
In this second installment on aspects of file-based workflow, the topic turns to the human factors affecting implementation and how to implement software systems in hardware-based broadcast solutions. (Check out the first part of this article series, "File-based workflow: Bits and bytes made into programs," in the April issue of Broadcast Engineering.) Make no mistake, the differences are substantial, and the learning curve is steep.
There are aspects of file-based workflow that make it quite different from analog or tape-based workflows at the every level. It is important to note that the business itself is also affected directly by the decision to move to new technology. But in this case, the business systems, which previously could often work with paper-based approaches, can no longer avoid being tightly integrated with the new technology.
PBS solution
Figure 1. In PBS’ Station Services Platform (SSP), files are “pitched” to stations over an IT-based satellite file transfer system. The SSP uses a transcoding engine to deliver the files in a format compatible with a station’s local video server.
A case in point is the implementation of "NRT," non-real-time transfers of content from Alexandria, VA, to affiliated stations, now under way at PBS. (See Figure 1.) Files are "pitched" to the stations over an IT-based satellite file transfer system. Once received, the files are cached on IT servers, a process that is part of PBS’ Station Services Platform (SSP), before they are moved to the station’s video servers. The more interesting part of the technology is the movement of metadata. The metadata — including accurate start of message (SOM), duration and program details like series and episode number — are distributed with the content and then parsed directly to the local traffic system from the SSP. Upon receiving the metadata, traffic has the choice of marking the content for movement to the air server and then sending a "dub list" directly to the SSP, which executes an FTP transfer of the content to the station’s video server. All this happens without any time spent in MCR to find and mark the content because the metadata flows with the content.
It is important to note that the SSP contains a critical bit of technology that allows seamless interoperation between PBS and all of the stations. The SSP contains a transcoding engine that takes the AMWA AS-03-compliant files and makes them compatible with the station’s local video server. No action is required by the station, and no special versions are needed for each station. This tight integration of several processes — transmission of the file, local cache, transcoding and FTP — constitutes an automated workflow that immediately affects PBS’ business operation in a material way. It saves labor and will eventually enable PBS to cut the amount of satellite bandwidth needed to move real-time content by shifting distribution to non-real-time file transfers.
A consortium including Warner Brothers, CBS and Ascent Media is doing something similar for long-form commercial content in a system it calls "Pitch Blue." Though different in the details, the operation is mostly the same. Content is sent as real-time MPEG streams to a local cache server. No record list is needed. Content destined for each station is simply delivered. This is similar to various commercial delivery services except that the end-to-end workflow was taken into account and no ingest operation is required.
Pitch Blue uses transport stream recorders where PBS is using true file transfer hardware. Both have self-healing capabilities should packets be lost in transmission, and both use terrestrial data paths to make requests for lost packets and allow the distant operators to check the status of content and the health of the transmission system. In both cases, FEC is used to allow some packet errors to be corrected without retransmission requests. Both systems are ultimately backed up by the ability to send the content in real time, live or for local recording by existing methods.
This kind of holistic integration of the file-based approach with existing business operations is important. As the number of streams transmitted increases, it will become harder to run efficient operations using old methods. Adoption of file-based methods is inevitable, in part because the hardware used for tape-based approaches is beginning to disappear slowly. At NAB this year, there was a recorder shown that uses LTO-4 tapes and an internal MPEG-2 encoder to record files directly on tapes which may be directly usable in some archive implementations.
One thing should be clear: File-based workflow is quite distinct from tape-based approaches because it uses an IT infrastructure. This means designing, operating and maintaining the system is an IT issue, with constraints real-time video puts on network topology, bandwidth and security. For instance, a single uncompressed SMPTE 292 (1.485Gb/s) signal requires at least 10GigE. Because television files seldom need more than 440Mb/s, common GigE hardware suffices for faster-than-real-time transfers of files. Because broadcast files are considerably skinnier, the overhead available is more than adequate to move files several times faster than several times real time or to move multiple files over one link at the same time.
Securing content is critical. Systems connected to outside networks, especially ones not locked down tightly, are dangerous at best and should be avoided. It is important to explain to IT designers that all aspects of topology and security need to be vetted before starting a complex file-based workflow system design to avoid discussions about common IT security tactics that don’t work well with real-time video services. In an ideal world, the storage system would be infinite in size and speed and never require upgrading. In reality, economics require tiered storage.
| Want to use this article? Click here for options! |  |
