The new world of codecs and formats
Aug 1, 2009 12:00 PM, By Paul Turner
File-based workflows require a new set of skills from broadcasters, manufacturers and system designers.
A reference file is made up of the media files themselves, plus a wrapper file that contains metadata and pointers to the media. When an application tries to play the file, it accesses the reference file to discover which essence files to play as part of that clip. (See Figure 2.) This is the file type of choice for editing, language addition, closed-captioning addition, and other applications that modify or add tracks to a clip. No disassembly or reassembly of the file is required. FTP file transfers are more complex, though, as the transferring application must understand exactly which files are pointed to by the reference file in order to ensure that all media necessary for clip playout is transferred as part of the FTP session.
It is, of course, possible to rewrap reference files, converting them from self-contained to reference, QuickTime to MXF and vice versa. This is a less-complicated activity than transcoding the essence and can therefore happen much faster, but it still has implications for the overall latency of the system.
Latency, codecs and file formats
Several broadcast workflows are relatively impervious to system latency considerations, as they include plenty of time to QC, prep and regionalize the material before playout, and then transcode/rewrap content. Other workflows, such as news and sports highlights, demand extremely short end-to-end (shoot-to-show) latencies. Paradoxically, while these are the most likely to benefit from the efficiencies of file-based workflows, they are the least tolerant to the file conversions involved that, by their very nature, slow down the flow of media.
Figure 3. Non-left-to-right files
Select figure to enlarge.
The goal, then, is to minimize the transcode/rewrap stages in these workflows and to make those transcodes as efficient as possible. One simple way of achieving this is to choose the edit codec so that field material can be shot using that codec and then be edited natively on the NLE of choice. Because many playout servers can natively accommodate multiple codecs, a transcode stage can be avoided by careful equipment and codec choice. The downside is that this may limit the total number of channels supported by the playout server — something that should be recognized when the system is designed.
The issue of file structure still remains, however. Low-latency workflows often require the ability to operate on a clip during transfer. Moving a clip from ingest server to editor while it's still being ingested (and making all of the currently ingested material available to the editor on an ongoing basis) is one common example, often referred to as transfer while record. Another example is the need to play out a clip while it is still being transferred to the playout server, or play while transfer. File structure plays an extremely important enabling role in these scenarios.
Many on-disk file formats are written in a non-left-to-right manner in which the header is written to disk and, as material is added to the file, updated constantly to reflect the current state of the file. Such a piece of metadata might be the clip duration. Initially set as part of the first write of the file, the duration is continually updated as material is added. If the clip is considered as a timeline, it is clear that the writing of the file is not left-to-right, as the system is continuously updating the left end of the file. (See Figure 3.) This can be problematic for FTP file transfer. The receiving device will only know the duration of the clip, for example, as identified at the start of the transfer. To resolve this problem, special techniques can be invoked whereby the transmitting system knows that it must keep transmitting new versions of the header part of the file at some regular interval. The receiving system must then integrate that new header information into its own copy of the clip.
Figure 4. Left-to-right files
Select figure to enlarge.
The solution to this dilemma is to use files that are written strictly left-to-right. Once a piece of data is written, it is never rewritten. As much header data as is known to be valid and nonchangeable at the time the clip recording started is stored in the header. A flag is set to indicate that this file has incomplete metadata in the header and that the full, valid metadata will be written at the end of the clip. (See Figure 4.) In this way, the clip can be transmitted as it is being written without any concern that a piece of metadata may be out of date. The receiving system has sufficient information (clip name, etc.) at the start of the clip to initialize the clip in its own database, and material will continue to stream in via the transfer mechanism. Final metadata is provided at the end of the clip when recording has completed.
The success of these transfer-while-record and play-while-transfer operations relies entirely on the performance of the network between the transmitting and receiving devices. Any bottlenecks on the network will at best result in reduced transfer speeds and at worst result in starved codecs, where the playout device has run out of new frames to play because the network can't deliver them quickly enough.
Conclusion
File-based workflows offer enormous efficiency improvements but require a new set of skills from all stakeholders involved in their design. Broadcasters must be aware of the issues involved in the choices they make as part of their system specifications. Manufacturers must recognize the ever-growing palette of codecs from which to choose and, wherever possible, accommodate additional codec formats as appropriate. System designers must learn new skills and understand the pros and cons of each mainstream codec. As new codecs are brought to market, they must apply intelligence and discretion in helping clients choose the formats for their system. Furthermore, the system designer must understand the implications of transcoding stages in the proposed workflow, and of file format choice on the overall latency of a workflow. File-based workflows represent a major advance in the state of the art for broadcast, but there's still no free lunch.
Paul Turner is vice president, broadcast market development, for Omneon.
| Want to use this article? Click here for options! |  |
