As media workflow migrate from tape-based systems to digital files, the opportunity exists to change workflow and processes. Changes can improve efficiency and lower costs, and to facilitate this, companies must look at interoperability and metadata.
The pressure to go tapeless is extending to all areas of media production and distribution, and this is just as relevant for TV advertising. When broadcasters first purchased video servers, it was to air commercials, i.e., to avoid the wear and tear of videotape playback. Back then, a server could store an hour or so of video. It wasn’t until the capacity increased that they could also be used for long-form programming.
Part of the advertising distribution chain was the first to go tapeless, but the impetus has flagged. But, why change? Tapeless, file-based operations have many advantages, especially when it comes to improving quality and delivering efficiencies.
Videotape, although proprietary, could be considered interoperable. If a spot was distributed on Digital Betacam, then anyone with a Digital Betacam deck could play it. With the move to files, things have got more complex, with a wide range of wrappers and codecs to consider.
Phone network operators and manufacturers agreed on standards long ago that enabled interoperability: They did this to benefit their businesses. It hasn’t stifled innovation or competition; rather, it makes it easy for users and helps the phone business to thrive. If you were a postcard printer, you may be in trouble, but that’s progress. For phone companies, interoperability enables business.
There are several initiatives, especially from the Advanced Media Workflow Association (AMWA) to create delivery standards based on the SMPTE MXF standards.
One of the goals of any workflow for TV commercials is to air a spot that looks as close as possible to what the agency saw in post production. Another goal is to ensure that the schedule for airing the spot matches the contract. There are time-honored methods for ensuring these goals, but many of the procedures were developed in the days of SD analog broadcasting.
Today a spot may be shown SD, HD or 3-D; 4:3 and 16:9; 720p or 1080i; streamed over the Web; or viewed on a tablet, phone or other mobile device. The old ways are not best suited to these new demands or to controlling costs in the management of the many new formats.
There are two concepts that are key to adapting workflow to this new world. One is the move toward interoperability between the equipment that handles the commercials; the second is the use of metadata to manage the workflow.
The slate and metadata
The accepted way to identify a commercial is by the job slate. This is usually created in post production by making a JPEG file showing the job details, which is then dropped on the timeline as frames of video. This is OK for videotape, but in a tapeless workflow, it would be better if you could read the job details of a file automatically, without needing to view the video.
The second drawback with the slate is that the information is manually keyed in the edit bay, and this can introduce errors, for example, if the editor was handed the job ID scribbled on a napkin or via a garbled cell phone call.
The slate information is part of the metadata that describes the commercial. Some is technical data, like time codes, compression formats, loudness, audio track layout, etc., and the rest is business data, such as the agency name, client and the title of the spot.
All this information or metadata generally travels separately from the video in the journey from an idea at the agency through to the broadcaster or cable operator. The metadata may be stored in asset management or traffic systems, and it may be rekeyed several times. It is no wonder that serious mistakes sometimes happen. Important transmission slots can be missed or the wrong commercial can played out. Rekeying information, and fixing mistakes, all takes time; it’s just another overhead.
The way forward
There is, however, another way. The ID assigned to a commercial by the agency should be unique. It should be carried with job in such a way that is doesn’t need to be reentered at each stage of the process.
The slate information can be wrapped with the video file and travel through the many processes from production to playout. This is more efficient, saves mistakes and saves on cost.
What are the barriers to acceptance? To answer this, we go back to interoperability. The broadcaster needs a video format and metadata that match their systems. That depends on their video servers and traffic systems.
For SD commercials, a popular AV format in SMPTE D-10, also known as Sony IMX. This uses MPEG-2 for video encoding. The metadata can be in any number of house formats and delivered as a separate file. HD commercials are often delivered on tape, originally as D5, but now more likely as HDCAM-SR. If file delivery is used, there are several formats in use. Again, metadata is handled separately.
Aspect ratio and AFD
Take a glance across U.S. networks, and it is possible to see the same commercial displayed full-screen on one and postage stamp on another. Where is the consistency of your message? The move from 4:3 aspect ratio for SD to 16:9 for HD has led to inconsistent handling of the picture aspect.
It sounds easy: Make graphics and important action center-cut protected, and the spot will be handled correctly. But through all the downconversion, cropping and maybe even upconversion, things can still go awry.
Again, there is an answer: an SMPTE standard for signaling data that can be embedded in the video. This data can guide equipment how to correctly display a picture on a 4:3 or 16:9 display. It’s called the active format descriptor (AFD), which even the NAB supports with its AFD Ready Initiative.
Using AFD can ensure that your ad is displayed correctly on HD sets or in SD and on older receivers, but everyone in the chain needs to support AFD. Where there are missing links, human intervention is needed, and that’s where mistakes can creep in.
Tapeless operations leverage modern computer networks to deliver content as files. The many operations of dubbing, QC, physical transport and warehousing are contracted into much simpler processes, and that’s where the efficiencies come in.
Before interoperable workflows can be constructed, there must be agreed standards in place. Right now, there are a number of ad hoc practices, largely driven by what formats are supported by existing equipment: nonlinear editors and video servers.
A number of leading broadcasters and service providers are working with Ad-ID, which is a joint venture of the American Association of Advertising Agencies (4A’s), Association of National Advertisers (ANA) and the AMWA to create a new standard for the distribution of TV commercials that will facilitate more efficient and automated workflows.
As an example, PBS wanted to use fiber networks to deliver programming to its many affiliates. By using non-real-time transfer of programs as files, rather than live satellite broadcast, it hoped to achieve cost savings. However, the affiliates had several makes of video servers to receive the files. PBS wanted to send out one flavor of file to all the affiliates, rather than tailor the files to the specific equipment at each site. In conjunction with the AMWA, the PBS project team developed a constrained version of MXF (AS-03) that, with software upgrades to the servers, meant that a common denominator media file could be distributed to all the affiliates.
A derivative of the AS-03 specification, AS-12, is set to be the model for a universal format for the delivery of commercials as files. It certainly needs some flexibility, to accommodate SD and HD version, for example, but this can be defined by “shims,” which further constrain the specification. To participate in the development of the AS-12 specification for commercial delivery, contact the AMWA.
Future US's leading brands bring the most important, up-to-date information right to your inbox
Thank you for signing up to TV Tech. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.