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.
At the LDS Church in Salt Lake City, UT, broadcast engineer David Gabbitas works on an Omneon Spectrum media server system. Photo courtesy IRI.
It's widely understood that file-based operations inherently are more efficient. A closer look at the typical workflow, however, reveals that while file-based processing, storage and movement of media offers opportunities for streamlining operations, it takes back some of that efficiency by forcing system designers and manufacturers to deal with the huge, growing range of individual codecs used by the different systems and areas of production, preparation and distribution that make up any broadcast workflow.
For decades, baseband analog video and audio were the well-specified, documented and accepted standards among broadcasters for material exchange. As a result, getting media from point A to point B was a straightforward and understood proposition. Little, if any, thought was given to what happened to video within a processing box; it was completely isolated and its internal format irrelevant. As long as a system could accept and output video and audio in the accepted format, it could serve as an island of processing within the larger workflow. The initial move to digital video and audio did nothing to change this. As long as the processor provided adequate picture quality and the required input and output formats, the internal codec was of little interest to the system designer. The transition to file-based workflows is changing all of that.
File-based workflows: New considerations
Notable efficiencies can be gained by passing material from one processor to another in compressed form. System latency can be significantly reduced as, given a specific transfer bandwidth, compressed media can transfer at many times faster than real time. End-to-end picture quality can also be improved by avoiding multiple decompress/transfer/compress stages as media passes through the workflow — at least in theory!
Unfortunately, this last point leads to new concerns for the system designer and equipment manufacturer. Because no single codec is optimal for all of the processes in the system, the system designer must now understand the pros and cons of each of the codecs involved in the various processors that make up the signal path, not only to decide intelligently which codecs should be used at each step, but also to understand the number of transcodes/rewraps that may be necessary to convert files throughout the various steps in the workflow — even if these transcodes/rewraps occur internal to an individual manufacturer's equipment.
Compression: Not “one size fits all”
No single codec is perfectly suited to all workflow tasks. Consider, for example, two basic stages in a broadcast workflow: editing and playout.
Figure 1. Self-contained file
Select figure to enlarge.
Editing is a creative process in which individual elements are stitched together to tell or modify a story. The ability to cut between takes on any frame boundary is a prerequisite of this stage, and intraframe (I-frame) compression is the method of choice, regardless of whether the compression engine is DV, DVCPRO HD or I-frame MPEG-based.
Playout is much more a mechanical exercise. Finished material is transferred to the playout server and played out at the right time under automation control. Playout servers are generally multichannel devices that use high-performance disk drive systems. Because of the high cost of the storage systems, it is desirable to store as much material as possible on those drives while giving multiple channels simultaneous access to that material. As a consequence, interframe (long-GOP) compression is the method of choice, again regardless of the compression engine.
There is an obvious conflict. Two different (though related) compression techniques are being used, and each is optimal for its workflow stage, but not for the other. So, the designer has two choices: decide on a single format and accept suboptimal performance in one operation, or use both codecs with a transcode stage sitting between them.
Figure 2. Reference file
Select figure to enlarge.
The first approach usually resolves to the use of I-frame compression on the playout server. Most manufacturers support this model, but the penalty is slower transfer between stages (as the files are physically larger) and a reduction in storage efficiency on the playout server. The second approach allows each stage to be maximally efficient and, depending on the location of the transcode (pre- or post-transfer), can improve transfer efficiency. This model, however, also adds a latency penalty to the overall workflow based on the time taken to transcode any particular clip.
Clearly the broadcaster, system designer and equipment manufacturers all need to be aware of the pros and cons to each codec and transcoder in order to specify and deliver the most efficient design. Broadcasters need to understand where any compromises may be, system designers need a comprehensive understanding of codecs and latencies, and equipment manufacturers need to design their equipment to give broadcasters and designers the greatest range of choices when creating a system. This is a never-ending activity, as there is no shortage of new codecs being announced every year.
Wrapper and file structure
Like compression technique, both the wrapper and basic file structure have significant implications for efficient media transfer, and these must be carefully considered as part of the system design and file-based workflow. The first question should be whether to use self-contained files or reference files — both supported in QuickTime and MXF — at any particular stage.
A self-contained file includes both the essence and the metadata, so there is a single entity to be transferred from one location to another. (See Figure 1.) Self-contained files are perfect for content distribution and remote playout scenarios because of the simple transfer mechanism required. However, because they need to be disassembled prior to manipulation, they are not so appropriate if any kind of media processing is required at either end of the transfer. Reference files are more appropriate for that part of the workflow.
| Want to use this article? Click here for options! |  |
