15    Web-Based Viewing and Ordering System

This innovative use of Final Cut Pro was designed for a national political campaign. The goal was to streamline the process they used to cut campaign spots with different consultancies around the country. The idea was to replace the traditional process of reviewing footage on videotape (which had to be shipped to different locations) with a web-based viewing and ordering system that integrated smoothly with Final Cut Pro.

Highlighted Concepts and Techniques

Database media-management solution

XML integration

Online review screeners

Challenges

Developing a custom solution from scratch

Overview

On September 26, 1960, John F. Kennedy and Richard Nixon participated in the first-ever televised presidential debate. It is said that those who listened on the radio felt that Nixon had won, but those who watched on TV felt that the winner was Kennedy. Of course, Kennedy won the election, and experts see the debate as a sea change in presidential politics.

Today, there can be no doubt that television is one of the most powerful tools in political campaigns (possibly the most powerful). In each campaign cycle, hundreds of millions of dollars are spent to produce and air campaign commercials (also called spots).

This project began when the executive producer for a national campaign approached a small but innovative postproduction and new-media company to create a system to streamline their postproduction process.

The campaign would be working with several dozen political consultancies in different parts of the country to cut spots appropriate to their regions and specialties. The source footage they would all be using would be stored centrally in Washington, D.C. In past campaigns, the screening process involved a lot of phone calls to discuss what footage was available. This was followed by a VHS screener being made and shipped to the consultancy. Then another conversation about that footage, perhaps another VHS tape with more footage, and finally a high-quality master tape being created and shipped.

Each time a consultancy needed footage for a spot, it involved several phone discussions and several tapes being made and shipped. With many consultancies all around the country, cutting many, many spots, all of this talking and dubbing and shipping added up to a lot of time and money.

The executive producer for the campaign had been working with the studio and with FCP for a while, and she approached the studio with an idea. Could they use Final Cut Pro and the Web to create a system that would replace the screening process of dubbing and shipping with a web site that would allow the consultancies to browse available footage and order it from the central library of footage?

The result was an innovative and cost-effective custom web database. During the campaign, this system paid for itself many times over in the savings on dubbing and shipping, Moreover, the system led to the whole campaign being more agile in its postproduction, enabling it to communicate much more efficiently internally and to respond with new television spots more quickly than they previously could.

Figure 15.1 Web-based viewing and ordering workflow.

Project Roles and Responsibilities

This project required a “hybrid” team, combining elements of a traditional postproduction team with web programmers and a flexible “librarian” role that turned into much more.

Executive Producer—Allison was the executive producer who first conceived the idea. Her position was high in the overall campaign staff, and she was responsible for all of the television production for the campaign, including managing all of the consultancies and the crews who shot the footage. Allison's role was management, and she was always focused on the big picture. She rarely needed to get involved in the production of a specific spot (except maybe to assign it to a particular consultancy and review it when nearly finished). Allison's job was to keep the whole machine functioning efficiently, and she saw a major opportunity for efficiency in the web-based archive.

Postproduction Consultant—Jacob was Allison's main contact at the studio, and the person she first told about her idea for the new system. As an experienced editor on political campaigns, Jacob was familiar with the challenges. In his role as a consultant on the project, Jacob synthesized the needs of the editors, the campaign, and the web programmer. Essentially, he was the glue of the project, understanding the goals at all levels and acting as a communications hub. It would be accurate to call Jacob the producer or project manager; however, it was his deep knowledge of Final Cut Pro and the postproduction process and his ability to communicate this knowledge to all those who needed it that were Jacob's main contributions.

Web Programmer—Max was a web programmer, and led the web team at the studio. He had a lot of experience with web sites and databases, but very little with video at the outset of the project.

Assistant Editor / Librarian / Editor—Yoshi was hired by the studio to do all of the Log and Capture of tapes into the archive, and to run the system once it was set up to facilitate the distribution of footage. The logging and capturing tasks were typical of the assistant editor role. Because his main responsibility was to maintain the footage archive, his initial role was as a “librarian.” As we will see, Yoshi's role evolved. At the end of the campaign, he was also playing the role of a full-fledged editor.

Required Equipment

The equipment listed here (except for the web server) was purchased by the campaign for the sole purpose of this project. A substantial investment, but a cost-effective one, because it saved a lot of money in the long run.

Uncompressed Final Cut Pro System—This was the “library” system, where Yoshi did all of the Log and Capture, received orders from consultancies, and made the uncompressed outputs for final delivery.

Large External High-Speed RAID—An Xserve RAID rated for uncompressed SD video playback was used for uncompressed storage of all the footage in the archive. About midway through the campaign, a second RAID was purchased for more storage space.

Digital Betacam and DV Play/Record Decks—All of the footage arrived as Digital Beta-cam (D-Beta). For outputs, the consultancies had the choice of D-Beta or DV.

Hosting Space on a Secure Web Server—This was provided by the studio as part of the package, and was necessary in order to host the web site that allowed the consultancies to view and order footage.

Execution

Initial Setup

Essentially, this project was a custom software and hardware solution. The solution was created to support a unique postproduction workflow, but the process of building the system itself resembled software development more than postproduction.

The first step was to bring together all of the key team members and stakeholders in a series of meetings meant to define the project technically. This was an interesting process, because unlike most of the studio's projects, it involved both the video and web teams. In general, these two groups did not understand each other's work particularly well.

As mentioned above, Jacob was a key player in this project because of his deep understanding of the editing process for political campaigns. It also helped that Allison was a true executive who knew how to delegate. She understood that Jacob's knowledge of the campaign's technical needs for postproduction was far superior to her own.

The process of defining the solution quickly became a two-person conversation between Jacob and Max. It was Jacob's job to describe the postproduction needs of the client, and the technical workings of FCP, to Max. It was Max's job to figure out what would be possible with the web-archive system, and how to accomplish it.

Their work together produced a scope document for Allison to review and sign off on. This document defined all of the specific objectives of the project, as well as, on a basic level, how it would function for the users. This was divided into two basic sections: the functionality for the librarian and the functionality for the web user. The specifications included:

Library system functional requirements:

• System can capture and store uncompressed video.
• Process includes a controlled vocabulary for logging and metadata. This is a strict system that will be used for searching keywords in the web-based archive.
• The process of compressing and uploading video, thumbnails, and metadata to the web system will be automated.
• The system will receive orders for footage by email, and the process for fulfilling these orders on tape will be as automated as possible.

Web user functional requirements:

• Users can search for clips based on a defined set of keywords.
• Users can view clips online as low-resolution QuickTime files.
• Users can fill a shopping cart and order the clips they want as full-quality sources from the library.
• The final uncompressed footage will not be transferred via the Internet; it will be shipped to a location of the user's choice on the format (D-Beta or DV) that they request.
• The system has no e-commerce functionality. Although it utilizes a “shopping cart,” no money changes hands—all users are working for the same campaign.
• Users gain access to the secure web site by creating a login profile that is authorized at the library location.

Once these parameters were defined, Max and Jacob really got to work. Max needed to create the software to power the web system and integrate with Final Cut Pro, and Jacob needed to purchase the equipment (on behalf of the campaign) and set up the hardware for the library FCP system.

Most of Jacob's job at this stage was pretty straightforward. He had set up uncompressed FCP systems before, and there was nothing terribly special about this one. They did decide to use an Xserve RAID for media storage. (RAIDs are discussed in detail in Chapter 5.) This was important in order to have plenty of drive space to store the uncompressed version of all of the archive footage.

Max's job was a little more complex. He had worked on a lot of data-driven web sites before, including search and shopping cart functionality, but a lot of the video and Final Cut Pro stuff was new to him. Final Cut Pro's XML compatibility was the key to the work that Max needed to do.

XML is discussed some in Chapter 13; however, it may be easier to get a grasp on its power in the context of this project. Max was already familiar with XML as a key technology underlying the movement toward standards-based web programming. He understood that XML is fundamentally about structuring data. In his own web-programming world, XML-based languages such as XHTML (a new version of HTML, based on an XML foundation) and SMIL (Synchronous Multimedia Interchange Language) were already helping to standardize the wild world of the Web. (XHTML has since become the main standard for web pages; SMIL has not really caught on for multimedia applications.)

The meaning of extensibility (remember, XML stands for eXtensible Markup Language) is that XML can be customized to represent virtually any type of data. In FCP version 4, Apple made the program XML compliant, meaning that the data contained in an FCP project could be written as and read as an XML document.

Max knows just what this XML compliance means—he can manipulate FCP projects (in XML form) with the same programming languages that he uses to work with any other data and incorporate it into web sites. His software needs to take an XML document exported from FCP and extract the relevant data (the keywords entered during Log and Capture and timecode information), and then use that data in the web application for searching for clips. As we will see, Max's software is also able to create FCP projects in XML to facilitate the fulfillment of orders.

So, Jacob builds an editing system, and Max builds some software, but there is still the step of integrating these two things. This process involves a few elements:

• Defining a controlled vocabulary for the metadata (what words to put in the logging fields for the librarian, and what the search terms will be for the web user).
• Designing the procedure that the librarian will follow to place new content on the web site (exporting XML, exporting video and image files, and uploading).
• Designing the procedure for the librarian to fulfill orders.

Of course, this integration is based largely on how Max designed the new software. Designing these procedures, properly documenting them, and training the librarian are also important. We are going to discuss each of these aspects briefly.

The Controlled Vocabulary

We have discussed controlled vocabularies before, and the basic idea is to define the way in which a project will use language as metadata. For this project, the controlled vocabulary is all the more important, because it will become the keywords that users will search with on the Web. It is decided that the web system will not support an open search with a search box. All searching will be done via a pulldown with the predefined keywords.

It is very important to have these words telegraph the content of the footage well. If not, it will be hard to find the desired footage on the web site. It is even more important that the librarian be totally consistent with the use of these keywords in the logging fields. A typo in the logging field might mean that the clip does not show up on a web search.

For this particular controlled vocabulary, recognizable keywords were chosen to represent large areas of content. So, “education” would be used for anything having to do with schools and teachers, or anything even metaphorical for education, such as footage of a child's ABC blocks. All of the central issues of the campaign, and the types of footage used, were given keywords. (Shots with the candidate in them used his last name as the keyword, not initials.)

A clip could have up to three keywords to describe it. So footage of the candidate reading to schoolchildren would have both the “education” and his last name keywords and would show up on a search for either.

Ultimately, a list of only about 100 words was developed to describe all of the footage in broad strokes, and a glossary page was added to the web site. That way, users could read what each keyword included, in case they were having trouble finding what they were looking for.

The Export Process

The way this process was designed, each day the librarian would start a new project on the FCP system. The name of this project would be based on the date. Throughout the day, he would add footage to the library, logging it with the words from the controlled vocabulary, and making new video files on the RAID at uncompressed quality.

At the end of each Log and Capture day, there were only a few steps needed to upload new footage to the library:

Fulfilling Orders

The procedure for fulfilling orders was perhaps the slickest part of the whole system. When a web user placed an order, the system would send an email to the librarian with a new XML project file attached. The email contained two pieces of information: the shipping address of the user placing the order, and their preferred tape format (D-Beta or DV). The XML file contained the information on the clips that the user was ordering.

When the librarian received the email, he opened the XML file in FCP. This FCP project (created by the web system based on the items in the user's shopping cart) had a sequence with all of the clips on it with five seconds of black between each one. The media clips were already linked to the uncompressed files that resided on the RAID. All the librarian needed to do was output this sequence to the desired tape format and ship it.

Using the System

Once the system was set up, there were several days of testing and debugging in a testing environment with a limited amount of footage. Once all of the kinks were worked out, it was time to start ingesting massive amounts of footage, adding it both to the RAID as uncompressed video files and to the web system as compressed QuickTime files so they could be browsed and ordered.

Yoshi was hired at this point, and it was especially important to get someone doing the ingest work who was particularly diligent and careful. Small mistakes in the Log and Capture process could essentially ruin the carefully planned functionality of the system.

There were several months of acquisition and ingest before any of the consultancies signed up and started actually using the system to browse footage. Once they started to use the system, everyone saw its benefit immediately. A process that used to take several days could now be done overnight. The system was saving the campaign money, but more importantly, it was saving them time.

Because he had done all of the Log and Capture, Yoshi was very familiar with all of the footage, and his role in the campaign started to evolve. Although Allison did not originally plan to get involved in the editing of individual spots, she now found that having Yoshi and the edit system at her disposal had some unexpected benefits.

She started going to him to work out ideas for new spots without even working with any of the consultancies. Pretty soon, along with maintaining the archive and fulfilling orders, Yoshi was also cutting original spots. This was an organic evolution of roles, and now Allison had even more flexibility in getting spots produced. She could work with her nationwide team of consultants—who were now cutting spots more efficiently than ever before—or she could turn to Yoshi, who had deep knowledge of the footage available and was quickly proving himself as a talented and creative editor.

Discussion

This project was a staggering success. The campaign won the election, based largely on the power of the spots. The studio had a groundbreaking and profitable project. Yoshi started an exciting career as an editor.

At the time of this project, there were other solutions available, but they were expensive and proprietary. The benefit of a custom solution was that it did exactly what the client wanted, nothing more and nothing less. It is unlikely that any of the proprietary systems would have worked as well, and they definitely would have been more expensive.

In the time since, similar systems have become more common, but mostly they are either still high end, proprietary and expensive, or custom solutions utilizing XML extensibility like this one. However, Final Cut Server is poised to change all of that.

At the time of this writing, Final Cut Server software was not yet available, but it promises to be a solution from Apple to do exactly this kind of thing inexpensively and fully integrated with Final Cut Pro. It seems likely that if faced with the same challenge today, Final Cut Server would be part of the solution. For a case study using Final Cut Server, please go to http://booksite.focalpress.com/Osder/finalcut/.

In general, the power of XML compliance has probably not been as fully exploited as it could be. It is used primarily as an interchange format between software platforms both within and outside Final Cut Studio. However, additional innovative web applications are certainly possible.

Lastly, Yoshi's evolving role is a great example of a happy accident. The editing system and Yoshi's position were both created for the sole purpose of supporting the consultancies that were supposed to cut all of the spots. However, once all of the pieces were in place, and especially because Yoshi was already familiar with the footage, it was an easy jump to have him start editing.

There is a saying that good luck is the residue of good planning, and we feel this can be applied to many workflow situations, including this one. Creative success is built on the foundation of a well-planned workflow. Happy accidents often occur in the context of a good plan and a well-integrated team.