The mainstay of television programming is the studio production — game shows, magazine shows and talent shows — all based on a multicamera shoot, with a live mix during the production. This mix, plus individual isolated (iso) feeds from the cameras, is recorded for subsequent editing into the final package.
Traditionally, show production involved a complex workflow dictated by the linear nature of tape. Typically three or four VTRs recorded the output of the production switcher and the direct camera feeds. The tape was copied to browse media for shot logging and selection. The same tapes were then ingested for the online edit. And there's no doubt the editor had access to some handwritten notes from a production assistant (PA) to help identify the good and bad takes.
The newsroom example
Most broadcasters have rebuilt their newsrooms with an architecture based on video servers to replace the earlier tape-based production. One of the primary drivers for the change was to accelerate their workflows. While a story is breaking, there is no longer the wait for multiple copies of a source tape to be dubbed. Instead, servers allow the journalists to view incoming feeds within a few seconds of the record starting. And with server architecture, the old problem of several journalists and editors all wanting access to the same tape at the same time disappears. The multiple read access to files inherently supports collaboration and parallel workflows.
News has been the area with the most pressing demand for collaborative nonlinear workflows, but many broadcasters are finding that the same technology can be used for everything from multicamera episodic shows to live studio productions like reality and game shows.
Many studio operations, including multicamera shoots, and live shows are now finding they can also benefit when they free themselves from the constraints imposed by tape. Producers look to innovate show formats and to accelerate the speed of production. If post production occurs during production, the show can be turned around faster. If highlights can be cut while a live show is on-air, the close can be enriched with reviews of key moments earlier in the show. Shorter production cycles can also lead to cost-savings.
The key to this shift, just like the newsroom, is to eschew the videotape recorder and in its place adopt the video server. (See Figure 1.)
Acquisition with the video server
The linear workflow becomes transformed with server-based capture. During the studio recording, the production assistant can log takes and scenes with the software control application that is also managing the servers. The metadata can then be embedded into the clips.
Proxies are created as required from the broadcast-resolution clips as a background transcode operation. This means that the entire production crew gets instant access to material as required, which is not possible with videotape.
If the production server acquires using the same codec as the editor, a stage of concatenation is avoided. Ingest becomes a simple file transfer to the NLE. In fast turnaround applications, clips can even be streamed directly to the NLE as they are captured. The editor sees the PA's notes directly in the bins and timeline, inherently linked as metadata.
To summarize, the benefits of the production server include:
- Play while record;
- Multiple, concurrent read access;
- Faster-than-real-time network transfers to third-party equipment;
- Lower operating costs than VTRs; and
- Support for proxy (offline) workflows.
The first newsroom server systems only had to support the lower data rates of SD, typically DV25. With newsgathering migrating to HD, the data rates are increasing. For studio production, the requirement is for a higher picture quality than news with the attendant higher data rates. A studio server should typically support one of the editing codecs, DNxHD or ProRes, both with data rates over 200Mb/s for high-quality recordings, as well as the MPEG and DV formats.
BBC Ingex
In 2004, the BBC research department started some experiments to design and build a file-based acquisition system that would be based on commodity PC workstations. The project was to create a system that could replace VTRs for studio recording and provide automated shot logging. Dubbed Ingex, the project captured SD-SDI from the cameras and production switchers, and created MXF-wrapped DVCPRO50 files for subsequent craft editing.
The ingest workstation used a quad-core PC with four SDI video cards, and could capture and encode four simultaneous streams. Ingex is backed by a commodity NAS server, with 10TB of RAID storage on SATA disks. The start and stop time codes were recorded in a database and embedded in the MXF files. The production assistant could also add notes, naming scenes and takes, as well as comments like good or bad take. The Ingex application could also wrap multiple streams as an AAF file so the editor could drag multicam clip groups directly to bins in the NLE.
This work proved that servers could not only replace VTRs, but could also improve the efficiencies of the production processes with automation and enhanced metadata management.
Transmission servers
Playout servers are a mature technology, but acquisition servers must operate at the higher data rates used in post production, rather than the somewhat lower rates used for a transmission files (typically 20Mb/s to 50Mb/s). For the editing process, popular codecs are 10-bit 4:2:2 with 220Mb/s data rates, which is five times the typical HD playout server data rates. The 10-bit resolution provides the necessary headroom for later color grading to match shots or give a production “look.”
Acquisition to a media server must be as reliable, or better, than videotape before a production company would consider changing its method of recording. The recording hardware platform must have sufficient computing resources to avoid missed frames under all possible conditions. Even with the improvements in CPU power and disk performance since the BBC experiments, HD data rates still require specialist hardware to provide the performance to support simultaneous recording, real-time replay and file transfers to other equipment. Many studio productions will want to process multiple parallel clips for multicam, or just multiple layers on the timeline, both requiring high bandwidth to and from the storage subsystem.
Any media production will also expect VTR-style features, like jog and shuttle, plus the ability to scrub through clips. It is possible to use a powerful workstation with a commodity video card to build your own VTR replacement server, but tweaking the system to meet key operational requirements, like the guarantee that frames will never be dropped, means that with today's hardware it makes more sense to use a proper media production server for studio operation.
The server manufacturers have taken a couple of routes in the design of production servers. One is to base the product on sports production servers. These already support more than is required; studio production doesn't need slo-mo replay of high-speed cameras.
The other approach is to build out the performance of playout servers to support the higher data rates. Future commodity workstations will have the bandwidths to support live acquisition with the absolute reliability that exceeds VTR performance, but shooting expensive talent is not the place to cut costs on technology. Missed shots through equipment malfunction are expensive in studio time.
Processes
The production server, together with the management application, provides not only the means to capture and process the media clips, but also extensive metadata management to aid production staff and to automate operations.
An essential part of capture is to log all the shots as they happen. Slate data, scene name and take number (auto-incrementing if required) can be entered in one place, automatically associated with all the parallel record clips. Recordings can be started, stopped and even aborted from a unitary control interface. This replaces VTR remotes and the PA's notepad. The PA can freely enter notes during a shot automatically tagged with time code for later use by the editor.
Production staff previews shots at will, making selections and annotating. During the logging operation, the notes and markers are automatically linked to the media clips to present to the craft editor. This greatly eases the editor's work, helping the editor avoid mistakes with handwritten notes and linking those notes to tape numbers and time codes.
This seamless interworking with craft editing workstations is where production servers score over VTR-based production and deliver process efficiencies.
Multicam
In multicam recording, several cameras shoot the scene from different angles simultaneously. One popular way of working is to record the live mix from the production switcher, plus iso or sync feeds from the individual cameras. Recording to a multiport server system rather than VTRs means that the separate camera clips are automatically linked to each other, not separate iso tapes to be ingested.
A multicam server can represent a big cost-savings over individual VTRs, and adding another camera channel just requires an extra port on the server. Typical productions need four to six VTRs, which can be replaced with one or two servers.
Time code becomes just control metadata for the system. For the operators, clips are identified by production data, such as take number, scene number and markers.
Summary
The production server is replacing VTRs for fast turnaround shows, especially with multiple cameras. As well as the obvious cost-savings, it offers the production crew the opportunity to improve its operational processes and streamline the interface with post production. As field acquisition moves to file-based media, and studio production moves to disk, we move inevitably to a broadcast production chain where the only tape is data tape.
