A Producer's Guide to File-Based Digital Video Preservation May 5, 2010 Jonah Volk

A Producer's Guide to File-Based Digital Video Preservation May 5, 2010 Jonah Volk The world of digital video production has undergone a major shift within the past few years. Just as film gave way to analog videotape and analog tape gave way to digital video, more and more production companies have begun shooting on file-based video formats, including Panasonic P2, Sony XDCAM EX and XDCAM HD, and Canon 5D Mark II, to name just a few. With the explosion in popularity of these formats has come a host of new challenges relating to production companies' attempts to save their shot material. While previous generations' efforts could be and often were limited to the storage of physical materials, the introduction of file-based video has introduced a paradigm shift wherein the "materials" to be archived are purely digital. In addition to the issue of storage, metadata has now become crucial to the archival process, even for the staff of small production companies who may not even know what "metadata" is. This paper is designed to be an exploration of these issues, aimed at providing small and medium-sized production companies with the tools, resources and strategies needed to reliably and, where possible, cheaply and easily, ensure that the video they shoot will not be lost. At the heart of this paper is a proposed workflow covering the entirety of the preservation process. Notably, this workflow starts at the very inception of a project; no longer can archival concerns be postponed until a project is finished. Only by integrating preservation into every phase of the production process can production companies be assured that their material will survive. 1

Goals As mentioned earlier, a major goal of this thesis project is to develop a workflow whereby production companies can ensure that their footage shot on file-based cameras will be preserved in both the short and long terms. Before this workflow can be developed, the question must be asked: why is this important? To quote the final report of the Academy of Motion Picture Arts and Sciences ' Blue Ribbon Task Force on Sustainable Digital Preservation and Access: "When making the case for preservation, make the case for use. Without well-articulated demand for preserved information, there will be no future supply." 1 In the production world, this use value of saved footage is clear, given the example of earlier tape and film-based workflows. In the short term, it is critically important for all production companies that shot footage, in any format, be maintained during the production and post-production process. In addition, for many companies, particularly those working with non-fiction materials (documentaries, industrials, etc.), shot footage can have a value well beyond the completion of a project. The rise of digital video and cheap tape stock allowed for frequently high shooting ratios, often leaving hours upon hours of unused footage, which many companies have become accustomed to reusing in related productions or licensing to other parties. When working with videotape, as many companies have been for at least a decade, if not longer, standard archival practice, especially at smaller companies, tends towards minimal effort. Tapes are frequently stored on shelves in an office, and metadata often consists of a 1 Blue Ribbon Task Force on Sustainable Digital Preservation and Access. Sustainable Economics for a Digital Planet: Ensuring Long-Term Access to Digital Information. Academy of Motion Picture Arts and Sciences. 2010: 1-2. <http://brtf.sdsc.edu/biblio/brtf_final_report.pdf>. 2

single spreadsheet, or even just a text document. Nevertheless, this sort of archival strategy has sufficed for many companies, at least in the short term. The switch to file-based formats has changed this situation completely. Where a major disaster would previously have been required to cause the catastrophic loss of shot footage during a production, now this type of loss could be brought about by the failure of a single hard drive, hardly a rare occurrence. What is at stake is the potential loss of hours of irreplaceable footage and, by extension, the waste of large amounts of time and money. However, while the dangers are clear, the solutions are not. Companies like Sony and Panasonic provide little guidance in archival matters, leaving many producers to fend for themselves, developing their own solutions which may or may not be helpful. 2 For an archival solution to be truly successful in this context, it must not only ensure that footage will remain secure and locatable, it must also be relatively cheap and easy to implement; if not, it will remain out of reach to many production companies that need to archive their footage, but lack significant resources to devote to such a project. Finally, it is crucial that any preservation project encompass both the physical storage of the media and the gathering, storage and display of metadata about the media. Regarding the former, data storage should ideally involve multiple copies of all media, kept in geographically separate locations. Especially when using hard drives, drive failure rates are high enough that any file without a backup is in danger of being lost. Regarding metadata, as mentioned earlier, while productions companies typically have 2 Several case studies on the file-based workflows of small production companies can be found in an earlier work by the author of this paper: "The Solid-State of Things: Small- Scale Archival Workflows," available online at http://www.nyu.edu/tisch/preservation/program/student_work/2008fall/08f_1800_volk_a 3a.doc. 3

some intellectual control over tape-based assets tape logs, for example many of these same production companies have been slow to adapt strategies for maintaining metadata about file-based media. Ultimately, unless production companies can account for both aspects of preservation, their data is at risk of being lost. This paper will first cover three common recording formats, followed by a discussion of a case study performed at Broadway Video Digital Media, and concluding with the Producer's Guide, a proposed workflow. Appendices A a glossary of terms and B an overview of some commercial software products may be used as reference throughout. Recording Formats Panasonic P2 Panasonic introduced its P2 format in 2004, based around a line of solid-state recording hardware. The primary storage device is the P2 Card, a solid-state flash memory card consisting of multiple SD Cards connected in a PCMCIA enclosure, seen in Figure 1. At launch, only 2GB P2 cards were available, though recording capacity has been steadily increasing to the point where cards of sizes up to 64GB have now been released. Figure 1: P2 Card Source: http://www.abelcine.com Panasonic sells a wide variety of P2- compatible cameras for the professional production market, including both large shoulder-mounted cameras for large-scale 4

productions and electronic news gathering, and handheld cameras (including the popular HVX-200 model) for smaller productions. While many of the first P2-compatible cameras also included tape-recording capabilities, this feature has been phased out in most newer models. P2's initial standard recording codecs were from Panasonic's DVCPRO family; all P2-based cameras were designed to support DVCPRO, DVCPRO50 and DVCPRO HD. In 2007, Panasonic introduced its AVC-Intra codec family and added compatibility to its P2 cameras. AVC-Intra comes in 50Mb/s and 100Mb/s varieties and is based on the MPEG-4 standard, as opposed to DVCPRO, which was based on DV. Whichever codec is being used, P2 utilizes an MXF wrapper. In order to offer greater flexibility to end-users, MXF was designed to have multiple instantiations, called operational patterns; P2 makes use of one titled OP-Atom. OP-Atom is the simplest MXF operational pattern and specifies that each MXF file can contain only a single track of essence: video or audio. As a result, systems that make use of OP-Atom, such as P2, must store video and audio tracks separately, using metadata to link them. In practice, this is seen in the P2 file structure, displayed below in Figure 2, which is created on a P2 card at the time of recording. Specifically, this file structure will be created when first recording to a blank card. A new clip is created every time the camera starts recording; all the clips on a card are located within a single P2 file structure, often referred to as a P2 volume. In the example shown in Figure 2, two clips have been recorded to one card, both of which are contained in a single volume. Each clip is assigned a six-character name which is shared by all elements associated with that clip. The leftmost four characters of the name designate the order in which the clips were shot, with leading 5

zeroes when necessary. Thus, the first clip seen in Figure 2 begins with "0001" and the second with "0002." The final two characters are randomly designated and can be either numbers or letters. P2 File Structure At the top level of the P2 file structure is a folder titled CONTENTS. Within CONTENTS are six sub-folders, titled AUDIO, CLIP, ICON, PROXY, VIDEO and VOICE, as well as a text file: LASTCLIP.TXT. 3 The essence is located in the AUDIO and VIDEO folders, with each video or audio track stored as a separate file, as specified by MXF OP-Atom. For example, in Figure 2, the clip designated 000137 has been stored as a single video track and four separate audio tracks, designated by appending 00, 01, 02, or 03. Each of these MXF files includes a header metadata section, which contains vital metadata related to the Figure 2: P2 File Structure 3 "Final Cut Pro 7 Professional Formats and Workflows: Panasonic P2 Card Format Specifications." Apple Final Cut Pro. <http://documentation.apple.com/en/finalcutpro/professionalformatsandworkflows/index. html#chapter=5%26section=11%26tasks=true>. 6

clip, including clip name, global clip ID, duration, codec, aspect ratio, frame rate and audio bit rate. While the MXF files thus contain all the information needed for playback, in practice it is quite difficult to play these MXF clips if they are removed from the complete file structure. Final Cut Pro (FCP), which does not natively support MXF, features the ability to extract the essence from the appropriate places within the file structure and construct a QuickTime video file; other editing systems include similar tools. The ICON folder contains a thumbnail image file, specifically the first frame of the video, as an 80x60 BMP file. This thumbnail is used as a reference to the clip, in the import mode in Final Cut Pro, for example. The PROXY folder is designed to hold an MPEG-4 proxy video file, which could be used to simplify the import process by having more accessible files readily available. The ability to encode proxies is not built into P2 cameras, but can be obtained by means of a Proxy Encode Card that can be loaded into some, but not all cameras. If used, the encode card allows three levels of proxy quality: 1.5 Mb/s, 768 kb/s and 196 kb/s. 4 The VOICE folder is designed to store an audio recording in WAV format, to be used as a audio memo file. This voice recording can be made by means of a microphone attached to a camera. The CLIP folder stores the clip metadata as an XML file. A full listing of the metadata included in this file can be found in Appendix C. Finally, LASTCLIP.TXT identifies the last clip recorded to that volume. It contains three lines listing, in order, the name of the last clip without any extension, the number 1.0 (the meaning of this number is unclear, but it is probably a firmware version 4 "Panasonic AJYA800G P2 Proxy Encode Card." Full Compass. <http://www.fullcompass.com/product/367565.html>. 7

number) and the number of clips recorded to the card, plus one. In the case of the example above, this file would read: "000279", "1.0", "3". XDCAM EX XDCAM EX is actually the latest version of Sony's XDCAM technology, initially released in 2003, though it bears little resemblance to the earlier generations. The original XDCAM and XDCAM HD formats were designed to record to Sony's Professional Disc, an optical disc format technologically related to Blu-ray. These initial versions recorded Figure 3: SxS Card Source: http://www.abelcine.com using DVCAM or MPEG IMX codecs for standard definition and an MPEG-2 codec, MP@HL, for high definition. In all cases of these earlier XDCAM versions, an MXF wrapper was used. XDCAM EX, released in 2007, records instead to SxS solid state memory cards, seen in Figure 3, which fit the ExpressCard standard. Recently, Sony has also released cameras which record XDCAM EX to SD cards. XDCAM EX uses the MP@HL codec like its predecessor, however, instead of MXF, it uses an MP4 wrapper. 5 5 "Final Cut Pro 7 Professional Formats and Workflows: XDCAM, XDCAM HD, and XDCAM EX Format Specifications." Apple Final Cut Pro. <http://documentation.apple.com/en/finalcutpro/professionalformatsandworkflows/index. html#chapter=8%26section=3>. 8

XDCAM EX File Structure As with P2, XDCAM EX's original form consists of a file structure, seen in Figure 4. Unlike P2, however, the essence is contained in a single file, titled 066_0059_01.MP4 in the example. The top-level folder is titled BPAV, and it contains two subfolders, CLPR and TAKR, and two XML files, CUEUP.XML and MEDIAPRO.XML. Of these latter two, CUEUP.XML functions as a reference to the first clip recorded on that card as well as containing some basic metadata about the first clip: UMID, timecode format (drop/non-drop frame) and starting timecode. MEDIAPRO.XML contains information on each of the clips recorded to the card, specifically: UMID, duration, frame rate, aspect ratio, number of audio channels, video and audio codecs, and locations of the MP4, Figure 4: XDCAM EX File Structure XML, PPN and BIM files (described below). It also contains a Properties element, which specifies the recording media type (for example, Professional Memory Card), and an ID number for that piece of physical media. The 9

TAKR folder is often empty, and serves to hold information on clip relations in case of clips spanned across multiple volumes. 6 Inside the CLPR folder are sub-folders for each clip recorded to the card, each of which contains the MP4 essence file, along with SMI, PPN, XML and BIM files. The BIM file is considered the real-time metadata file, which contains timecode and codec information designed to be read by an application during playback and, as such, is not human readable. Its human-readable equivalent is the XML file, or non-real-time metadata file, which contains a variety of descriptive and technical metadata, listed in Appendix D. The SMI, or clip information file is much smaller and contains links to the MP4 and BIM files, information on the audio and video codecs, and the clip's starting and ending timecode values. Finally, the PPN file is a picture pointer file, not human readable, which includes the position of each video frame. This is necessary, because many MPEG-2 codecs, including the one used by XDCAM EX, utilize variable bit rate encoding, meaning that the positions of frames are not as easy to determine as in a file with a constant bit rate. 7 Canon 5D Mark II The Canon 5D Mark II camera, released in 2008, is a digital SLR still camera that also features the ability to shoot video, either SD or 1080p HD. Video is recorded to a 6 "File structures in recording medium." Movie Repair Guide. <http://www.aeroquartet.com/movierepair/files%20structures%20in%20recording%20me dium.html>. Extensible Metadata Platform (XMP) Specification: Part 3, Storage in Files. Adobe Systems. 2008: 36. <http://www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf>. 7 Ibid. 10

CompactFlash card inserted into the camera. The video is encoded with an MPEG4- based codec, ASP@L5, and wrapped as QuickTime. 8 Figure 5: Canon 5D Mark II File Structure Unlike P2 and XDCAM EX, the Canon does not create a complicated file structure; instead, for each clip there is one MOV essence file and an associated THM image file. Clip names, which are shared by the video and THM files consist of the prefix MVI_ followed by a four digit number which is incremented by one for each clip. As with P2 and XDCAM EX, the Canon creates a new clip each time the camera starts recording. While THM files were used in the past by a number of graphics applications as thumbnails for larger images, currently several cameras, including the Canon 5D Mark II and the iphone camera, use them as thumbnails for video. 9 In addition, the THM file contains a great deal of metadata about the video file stored in an Exif header. This includes metadata about the thumbnail itself, but also information about the camera settings focal length, aperture, camera model and serial number, etc. as well as a date and time stamp. While this data is not designed to be imported into an editing system, the Broadway Video Digital Media project, discussed below, involved extracting this THM metadata and integrating it with metadata from other sources. 8 "Canon EOS 5D Mark II." Wikipedia. <http://en.wikipedia.org/wiki/canon_5d_mark_ii>. 9 "THM." FilEXT The File Extension Source." <http://filext.com/fileextension/thm>. 11

Archival Considerations The important thing to realize from an archival standpoint, regarding files of the above formats, is that the complete file structure should always be preserved and saved. Conceptually, it should be considered the equivalent of a master tape; even if the video is transcoded to a different format for editing, the original file structure will still contain the video in its original form with its original metadata, and should thus be considered the key "artifact" for preservation. In considering these formats from an archival perspective, it becomes clear that each of them has both advantages and disadvantages. In all three formats, the fact that essence and metadata are stored separately within the file structure means that the two could potentially become separated or lost. In fact, the MXF OP-Atom file structure of P2 opens the possibility for essence tracks to become separated from one another. In this sense, the other two formats have a clear advantage: their essence exists as a single track that can be played back even if the file structure is broken. And while the relative simplicity of the Canon 5D Mark II files may seem appealing, in practice the lack of a folder structure significantly raises the possibility that the THM file will be lost. Finally, all three formats have the important advantage of storing the bulk of their metadata in a separate file from the essence. While it is important for key technical metadata (aspect ratio, frame rate, codec) and the UMID to be embedded within the essence file, there will always be a limit on the amount and the types of metadata that can be thus embedded. Using a separate metadata file, ideally XML, offers the opportunity to include as much metadata as desired, with no limits on allowed categories. The advantage of XML can be seen in comparison to the Canon 5D Mark II THM-stored metadata, which has much less 12

flexibility due to its use of the Exif template, especially since many Exif metadata categories are tailored to still images rather than video. 13

Case Study: Broadway Video Digital Media-Department of Transportation Project Project Background In 2009, Broadway Video Digital Media (BVDM) was contracted by the New York City Department of Transportation (DOT) to produce a video about the DOT's Green Light for Midtown campaign. The campaign involved the transformation of several lanes of traffic around Times and Herald Squares into pedestrian walkways, and the video was meant to spotlight the positive outcomes of these changes. Beginning September 17 and for approximately the next six weeks, three BVDM crews shot footage of the areas affected by the Green Light program, each using a Canon 5D Mark II camera. The three cameras were referred to as A Camera, B Camera, and 2 nd Unit. A total of approximately 45 hours of video was shot on the three cameras combined. The footage was all shot at 1080p, the highest resolution Figure 6: Original media stored on BVDM's SAN allowed by the camera, creating QuickTimewrapped MPEG-4 files. 14

As mentioned earlier, the primary goal of the project was to produce an edited video that could be used as a promotional tool for the campaign. The video thus produced was approximately five minutes long, and can currently be viewed at the DOT's website: http://www.nyc.gov/html/dot/html/about/broadway.shtml. In addition, a secondary goal of the project was to provide searchable access to the DOT of the unedited footage. It was determined that the best way to accomplish this would be to upload the video to the Broadway Video Digital Library System (DLS) 10, a still-indevelopment online digital asset management system created by David Rice of AudioVisual Preservation Solutions and Mike Castleman of Roasted Vermicelli. The DLS would house proxy videos for each of the clips, along with key metadata. In addition to a basic description of each clip, location and date/time information was particularly import to the DOT, as this could be used for data mining purposes to find out how many cars drove through a certain intersection at a certain time of day, for example. Despite the fact that BVDM knew from the outset of the project that certain categories of metadata would be crucial to the project, few special efforts were made to capture them during the shoot. Paper log notes were recorded while shooting and include information on location and type of shot, and a brief description. However, these records are often vague and proved difficult to match up to specific shots. (See Appendix E for a sample of these hand-written logs.) 10 While BVDM has since changed the name of this service to the Library Access Platform (LAP), this paper will refer to it as DLS, as that was the name being used during this project. More on the DLS/LAP system can be found at: http://www.bvdigitalmedia.com/library-access-platform/lap-system-information/. 15

Once the media was brought back to the office, the original video files were transcoded from the original codec, which was not compatible with Final Cut Pro, to MPEG-2 MP@HL (the same codec used by XDCAM EX), still wrapped as QuickTime. This process was automated using FlipFactory software. The original media files (of which there were approximately 2000), with their associated THM files, were stored across seven volumes on the BVDM SAN (see Figure 6 for one example), while the transcoded media was all located on one volume. Once in FCP, the media began to be logged, first by one of the BVDM staff members who had shot the material, then by the editor who would be working on the project. This logging involved renaming the clips in Final Cut such that the new names might include location information, reel information and some descriptive information, though not necessarily all of these. It is important to note here that changing most metadata fields, including Clip Name, in FCP, does not result in changes to the original media. A particular counter-example (Reel Number) will be discussed below. Some example clip names are "49th_A1_pedestrian_biker_delivery woman" and "54th left turn Boom Up stopped truck" note that there seems to have been no standardized filenaming convention. No information was entered into any other fields in Final Cut during this initial logging phase. Access Project When the DLS-access phase of the project began, the footage had already been shot and logged, and the five-minute video had been edited. At that point, it was clear that there was a great deal of relevant metadata that had either never been captured, or 16

been captured only sporadically and/or inconsistently. Thus, the first step in the process would need to be the entering of this metadata. It was determined that the best place to enter this data would be into the FCP project. The advantages of this method were: first, the clips were already in FCP and could be easily viewed there; second, after each clip was viewed, the metadata could be entered directly and easily into that clip's record; and third, FCP metadata can be easily exported as XML. One potential drawback was that the software offers a limited number of columns that can be used for user data entry, though in this case that turned out not to be a problem as the number of metadata categories needed for the project was also small. The categories that were chosen for data entry were: Camera Angle/Position, Location, Camera Movement, Camera Facing Direction and Reel Number. These categories were selected in consultation with BVDM staff, and were based, to some extent, on categories that had been recorded on the paper logs during the shoot. The first four categories would provide the DOT with the information needed for their data mining purposes. Regarding Reel Number, this metadata category in Final Cut Pro is actually intended for use with tape-based productions, where each tape would be assigned a unique number. In the file-based world, this category is used inconsistently, if at all. For the BVDM project, "reel numbers" were assigned to batches of video coming from a single CompactFlash card. Thus, when all of the video was copied to a hard drive from the first card used by the first camera on the first day of shooting, it was placed in a folder titled A1. The next folder was titled A2, and so on. Footage shot on the second camera was labeled B1, B2, etc. The decision was made to retain this information in Final Cut Pro because these numbers corresponded with the paper logs and would potentially make 17

it easier to match clips to these logs. Because these numbers were used as folder names, it was easy to find and enter this information. It was also decided to enter the Reel Number information into one of the comment fields, rather than into the Reel field. This was done because changes to Reel field are made to the clips themselves, unlike most of the other fields in Final Cut Pro. For an unknown reason, possibly related to some aspect of the file structure of the video clips, this Reel information was all erased from Final Cut Pro on multiple occasions, thus the decision was made to store this metadata elsewhere. Because the data to be entered was not available in a consistent form anywhere, the data entry had to be done manually by a BVDM staffer who would look at each clip, then enter the information by hand into FCP. To facilitate this process, a data entry guide was created, specifying what data was to be entered where and providing controlled vocabularies for each category. This guide can be seen in Appendix F. The data entry process took approximately two weeks, though the staffer was not able to devote all of her time to this project. Another necessary step in the project related to metadata acquisition was the assignment of PBCore elements to each metadata category. When the DLS was being designed, the decision was made to require all metadata categories to be matched with PBCore elements, to allow for greater compatibility with those sectors of the broadcast industry which utilize PBCore. These PBCore assignments are also used to group together certain metadata categories on the DLS website. Once the clip metadata had been entered into Final Cut Pro, an XML file could be exported that would contain both the newly entered information as well as all of the clip technical metadata already in FCP. However, there was still the important cache of Exif 18

metadata contained within the THM file which would need to be joined with the Final Cut metadata. This was accomplished through an application FCPXMLandTHMtoCSV developed by David Rice with further modifications by the author of this thesis. In order to work, the application required that all the THM files be gathered into a single folder because they are so small, they were actually copied so as to not separate them from the media files. The application first created an XML file from each THM containing all the extracted metadata, then ran an XSLT (Extensible Stylesheet Language Transformations) program that pulled specified metadata from the Final Cut XML and THM XML files and combined them into a single comma-separated value (CSV) file, with pre-determined column title and PBCore metadata category rows at the top of the document. This CSV file could then be saved as an Excel file, a sample of which is shown in Figure 7. Figure 7: Sample of DOT Metadata Excel File. At the same time that this was taking place, another BVDM staffer was running the original media clips through FlipFactory to create downscaled MP4 clips to be used as proxies on the Digital Library System. A free utility called CocoThumbX 11 was used to create thumbnail images for each file the 80x60 Canon THMs were too small to be 11 Available online at http://www.stalkingwolf.net/software/cocothumbx/ 19

of use. The proxy video files and new thumbnail images were all then uploaded to a single folder on a BVDM server that could be accessed by the DLS. At this point, a new "condo" the term used to refer to the collection of all clips associated with a given project was created in DLS for the DOT footage. Because the Excel file consists of a single document with each line representing a separate asset, DLS offers a "multi-asset quick import" function, which creates a record for each row in the file, then attaches the matching proxy file and thumbnail based on the filename listed in the document. The metadata listings are given titles based on the first row of the Excel file and they are ordered based on the PBCore categories in the second row of the Excel file. As it turned out, the DLS import process was substantially complicated by the fact that, in at least 100 instances, two clips shared the same name. This duplication was brought about by the fact that multiple cameras were used. Because the cameras all use the same naming convention and no attempt was made to change the automatic naming settings, there was some overlap. This problem was eventually addressed by renaming the B Camera and 2 nd Unit clips that shared names with A Camera clips. Figure 8: DLS Import Window 20

Figure 7: Broadway Video Digital Media Digital Library Service With the metadata and proxies successfully imported into the DLS, the only thing that remained was the archiving of the media. The decision was made to save both the original media, with THM files, and the transcoded edit media. The files were backed up to LTO4 tape using Retrospect software, which would also maintain records of which files had been stored where. As a result, if in the future the DOT decides to license clips 21

from the Green Light project as stock footage, for example potential clients will be able to browse the DLS, searching by location, time of day, or any of the other entered metadata categories, view a proxy clip online, and then purchase the clip, which can be retrieved from the LTO tape and delivered. Lessons Learned While the BVDM project was not, strictly speaking, a preservation project, being focused primarily on access, there are still several lessons that can be taken away from it and applied to file-based digital video preservation projects. First among these is the critical importance of managing metadata throughout the production workflow. As seen in the DOT project, with the location information, for example, putting off metadata issues until later in a project can lead to large amounts of wasted time. While BVDM had the incentive, the time, and the money to deal with these issues eventually, many production companies would simply give up. In contrast, taking simple steps to capture metadata as early as possible and to maintain it throughout the workflow is likely to be significantly more efficient. In addition, the metadata capture methods that were used in the early stages of the DOT project were not always well conceived. While paper logs can be very helpful for quickly capturing descriptive metadata in the field, the DOT logs were less helpful than they could have been because of the lack of clear links between the logs and the footage. A better solution would have been to either create a new entry in the paper log every time the camera was turned on or off to ensure that there would be a one-to-one relationship between log entries and clips. Alternatively, perhaps field logs could have been done on 22

a laptop or cellphone with the inclusion of automatic time stamps that could later be matched up to the footage. Second, the project highlighted the need to properly organize media files. Because file-based workflows generally involve footage being captured on many different memory cards (or other recording devices), it is very easy for the media to become scattered and disorganized. In the case of the BVDM project, the footage was spread over several volumes on the company SAN, and no consistent folder naming scheme was used. As a result, it was challenging to simply locate all of the media a necessity for the project to begin. The project also highlighted the need for checksums or verified copying techniques. Approximately 10-15 video clips had no matching THM files, which were presumably lost when the media was copied at some point. While this loss did not render the video unplayable, losing files from a P2 or XDCAM EX file structure could cause playback problems. It is also possible for an essence file to appear as though it has copied correctly, but to actually be unplayable due to errors introduced while copying. It is for this reason that the use of a program like ShotPut Pro, described in the Products section, is highly recommended. Finally, the BVDM project was, in many ways, far too complicated. In context, this was not necessarily a problem, as the project was serving as a sort of pilot for the DLS infrastructure, and because the company has the resources to support a complicated project. However, this situation highlights the fact that, for a workflow to be truly applicable to smaller production companies, it will have to be much simpler and easier to implement. This simplification can be achieved first by attending to the preservation 23

process at all stages of production. Accomplishing a few tasks at each stage will ultimately be easier than attempting to shoehorn everything in at the end. Second, it will almost always be simpler to use off-the-shelf products. While the DLS may eventually turn into a successful money-making service for BVDM, at the moment it is still buggy and incomplete, and continues to hold up the completion of the DOT project. For companies who do not have the support of a David Rice or a Mike Castleman, it is clearly easier to tailor existing software to meet their needs than to attempt to create something new. 24

A Producer's Guide: Proposed Workflow The workflow proposed here is designed specifically for a company that is shooting on P2 and editing with Final Cut Pro. However, all of the workflow steps are relevant, no matter which recording format or editing software is being used. Pre-Production 1. Determine Metadata A key step when beginning a project is to determine what metadata will ultimately be required. Once the metadata categories to be captured have been identified, each one can be addressed individually, and the appropriate time and method of capture can be determined. Ideally, everything should be captured as early as possible. For example, for the DOT project, this pre-production metadata planning might have resulted in the following conclusions: Location: Automatically capture during production with GPS logger (see section below for more on GPS logging) Reel Number: Manually create as cards are offloaded to drives during production. Use consistent numbering system across multiple cameras. Shooter: Manually enter into camera at the beginning of production. Camera Angle, Movement, Facing Direction: Manually enter into Final Cut during post-production/logging. Description: Manually enter into Final Cut during post-production/logging. 25

Note that the goal here is not to capture everything during pre-production, but to take the time to establish when everything will be captured. The key is not just to identify the metadata categories, but to ensure that they are entered in a consistent fashion, especially if they are being entered manually. While the metadata categories to be captured will vary from project to project, a few stand out as necessities for almost any project: UMID Camera Model & Serial Number Date & Time Description Basic Technical Metadata: frame rate, aspect ratio, bit rate, audio sampling rate Physical location of original media 1A. GPS Logging If location is a desired metadata category to be captured, GPS logging can help the production greatly. There are two primary types of GPS logging strategies: the first relies on a hardware device to embed GPS information within the clip itself either a card that can be installed in a camera or a device that can be attached to the camera. The second uses a device external to the camera to capture GPS information which can be synchronized with the clip at a later point. The types of available built-in or add-on hardware vary greatly from camera to camera. Generally, larger professional cameras will support the addition of a GPS 26

logging card. Certain other cameras allow for add-on GPS logging; for example, a WFT- E2 transmitter device can be attached to a Canon 5D Mark II camera. 12 The device contains a USB port, to which a commercial GPS product can be connected. If a camera does not support GPS logging, or if the budget does not permit the purchase of extra hardware, a separate device can be used. The easiest of these is an iphone with the GPS Log app 13 The app costs only $10, and it allows the user to make a log entry at any time. These entries can include a photo and a text note along with GPS information. These logs are also time stamped and can thus be matched up to the clips at a later point, assuming that the camera and iphone clocks have been pre-synchronized. 2. Acquire Software & Hardware At this point, any hardware and software necessary for the desired workflow should be acquired. Software should be installed as required. Especially important here is the purchase of hard drives (at least two) to be used to hold and back up footage while in the field. 3. Create Freelancer Guide If freelance crews will be used for the project, it is very important to create a guide for them to use, detailing the steps that must be taken in the field to guarantee that the footage will get to the office safely and that metadata is recorded properly. Key points to cover include: 12 "Wireless File Transmitter." Canon Inc. <http://www.canon.co.jp/imaging/wft/wfte2/index.html>. 13 This app can be found at http://gpslogapp.com/. 27

Field metadata capture requirements entering shooter information into the camera, for example, or making proper use of GPS logging device Ensuring that camera date & time settings are correct Proper technique for offloading footage from memory cards to field hard drives, including proper use of ShotPut Pro or other software Naming convention for folders on field hard drives Never renaming or rearranging original media files or folders Production 4. Set Camera Metadata Cameras generally feature methods for entering metadata before or during shooting that will be carried over to the resulting clips. For example, when working with P2, the P2 CMS software, discussed in Appendix B, includes a Metadata Upload function, seen in Figure 8. This allows for the creation of metadata profiles, saved as.p2 files, which contain all the information entered by the user. Figure 8: P2 CMS Metadata Upload Menu 28

These profiles can be created whenever needed on the day of production, for example, or even before the production begins, assuming that the information is going to remain constant. Once a profile file has been created, it can be saved to an SD card and loaded onto a camera. It is also possible to prepare multiple profiles ahead of time and load them onto a camera, then switch between them while in the field. 5. Field Log Notes Capturing descriptive metadata can save a great deal of time and effort later on in the production process. If a laptop is available in Figure 9: Panasonic HVX-200 (Camera) Metadata Input Screen the field, consider assigning a production assistant to record notes about each shot. If these notes are recorded in Microsoft Excel, the keystroke Control- Shift-; can be used to insert the current time into an adjacent column, ensuring that the logs can be matched up to the footage, even if there is not a direct one-to-one relationship between log entries and clips. If a laptop is not available, every effort should be made to create a separate entry in a paper log every time the camera starts recording to preserve this relationship. 6. Copy to Hard Drive 29

It is crucial that shot footage be transferred from a memory card to a hard drive as soon as the card is taken out of the camera. This is obviously true in situations where cards have to be reused during a shoot. However, even if enough cards are available such that reuse is not necessary this is more likely to be true now that memory cards are available with much more storage - it is still important to back up the footage as soon as possible. This process should be done using ShotPut Pro or a similar program; while the process will take longer than simple dragging and dropping the files, it will ensure that the footage is copied without any bit loss. An ideal scenario would have one crew member, most likely a production assistant, assigned to the task of offloading the footage. The crew member would have a laptop on location, connected to two portable hard drives and a reader for the memory cards being used. As soon as a memory card was removed from the camera, the crew member would insert it into the card reader and run ShotPut Pro, making two identical copies of the footage. After copying, the card could be erased and reused. By creating two duplicates of all original media files, this method would protect against any accidental loss of data, which would be especially devastating at a point when the footage had not yet been ingested into the editing system. Post-Production 7. Ingest The ingest phase can take a number of different forms, depending on the particular workflow being used. The ideal scenario for ingest is one in which the original media can be edited natively, without any need for transcoding or rewrapping; whenever 30

a new set of media is created, it adds an unwanted level of complexity to the project and potentially lowers the quality of the media. In addition, the new media will be removed from its original file structure, thus losing a connection to the original metadata. When working with P2 footage, Final Cut does not offer built-in native support of MXF, but can be achieved by using P2 Flow or Raylight software. For XDCAM EX, while Final Cut can work with the MPEG-2 codec natively using XDCAM Transfer software, the footage must be rewrapped as QuickTime. And Canon 5D Mark II footage must be transcoded before it can be used in Final Cut. At this point in the workflow, rather than ingesting footage directly into Final Cut Pro, it should first be ingested into another program, such as P2 Log Pro or P2 Flow. Adding this step will allow metadata such as UMID and Camera Serial Number to be imported into Final Cut this data would all be lost on a direct FCP import. This stage also offers an opportunity for other metadata to be entered. The advantage to entering metadata at this point, rather than in FCP, is that any metadata changes made in these intermediary programs will also be made in the P2 XML file. 8. Log & Edit Referring back to the first step of the process, this is the phase for manually entering metadata that has not previously been attached to the clip, either automatically or by using camera presets. When logging clips, the Description column in Final Cut, or its equivalent in other software, should be used for a plain-text description of the clip. Other columns can be used as desired, with the Master Comment and Comment fields being particularly useful. Importantly, if a reel number is 31

to be assigned, for example, based on a card numbering system as in the BVDM project, it is best to avoid entering this data into the Reel column in Final Cut, for reasons outlined earlier. Archival 9. Export and Database Ingest For long-term care of metadata records, it is important to be able to export from Final Cut all of the metadata created during earlier stages of the process, as well as all of the log notes made during the post-production process. In the BVDM project, a newlycreated tool was utilized for this purpose to convert a Final Cut XML file to a Excel file that could be imported into the Digital Library System. For more general usage, there is no need to convert the file to Excel; rather, the XML file can be imported directly into a FileMaker Pro database custom-built for this purpose. In order to accomplish this, an XSLT document must first be either created or borrowed to transform the XML file into a workable format for FileMaker. One such document can be found at the website of Kevin Bailey, who created it while working as an assistant editor to Walter Murch: http://homepage.mac.com/knbailey/workflows.html. It is fairly easy to alter an XSLT document to tailor it for the specific needs of a project this task could be done by a tech-savvy staffer or a freelancer hired for a day. (An example of this XSLT document is included in Appendix G, along with instructions on how to modify it.) To summarize this import/export workflow: 32

1. Create/modify XSLT document to include the desired metadata fields to be pulled from Final Cut Pro. 2. In Final Cut Pro, select the bin or bins containing the raw footage. Export as XML. 3. In FileMaker Pro, select Import Records -> XML Data Source from the File menu. 4. Select the XML file from Final Cut Pro and the XSLT file. 5. Map the fields into FileMaker as desired. (See Figure X) This mapping will be saved and can be reused for future imports. Figure 10: FileMaker Pro Field Mapping 10. Long-Term Storage While hard drives are not necessarily the most stable long-term storage medium, they may be, at this point, the most practical solution for many small production companies. Solid-state drives are still too small and too expensive to be useful, and LTO tape generally requires either the purchase of expensive hardware or a reliance on a third 33

party service to encode and decode data. As such, a few rules should always followed to make sure that digital files are preserved: 1. Always maintain at least one backup copy of all material in a geographically separate location. 2. Always save complete original P2 file structures. If there is room, consider saving FCP QuickTime files as well. 3. Keep information in database about the locations of all files, including any backups. Make sure this information is updated if files are moved. 4. Create checksums for all data and save the checksum values in the database. 5. Don t forget changing P2 metadata in P2 Log Pro or P2 Flow changes the original XML file. If any changes are made in this way, a new backup should be created to accurately reflect the new version. 34

Appendix A: Glossary AVC-Intra Family of H.264/MPEG-4-compliant codecs developed by Panasonic for high definition (1080 or 720) recording. Varieties include AVC-Intra 50 (50 Mbit/s) and AVC-Intra 100 (100 Mbit/s). Sources: http://en.wikipedia.org/wiki/avc_intra, ftp://ftp.panasonic.com/pub/panasonic/drivers/pbts/papers/avcintra%20faqs.pdf, ftp://ftp.panasonic.com/pub/panasonic/drivers/pbts/papers/wp_avc-intra.pdf CompactFlash Flash memory card format designed for use in portable electronics. Source: http://en.wikipedia.org/wiki/compact_flash Digital SLR Short for Digital Single-Lens Reflex. A digital still camera making use of a mirror system to allow the user to see through the viewpoint of the lens. Source: http://en.wikipedia.org/wiki/digital_slr DV A digital video recording format, first developed in 1995 and featuring several versions, including Sony's DVCAM and Panasonic's DVCPRO, DVCPRO 50 and DVCPRO HD. Source: http://en.wikipedia.org/wiki/dv Exif Short for Exchangeable image file format. A specification for image files containing a JPEG or TIFF file with additional metadata. Sources: http://en.wikipedia.org/wiki/exif, www.exif.org ExpressCard Developed by the Personal Computer Memory Card International Association as a replacement for the PCMCIA card. Designed as an interface for laptop peripherals, including solid-state memory cards. Sources: http://en.wikipedia.org/wiki/express_card 35

Final Cut Pro (FCP) Non-linear digital video editing software, sold by Apple. Current release version (as of early 2010) is 7. Sources: http://en.wikipedia.org/wiki/final_cut_pro, http://www.apple.com/finalcutstudio/finalcutpro/ LTO Short for Linear Tape-Open. A magnetic data tape format. The current version is LTO- 4, which holds 800GB. LTO-5 is scheduled for release in 2010. Sources: http://en.wikipedia.org/wiki/linear_tape-open, MPEG-2 A proprietary codec standard for audiovisual materials. MPEG-2 is controlled by the MPEG Licensing Authority (MPEG-LA). A wide variety of MPEG-2 codecs are available; applications include the DVD-Video standard. Source: http://en.wikipedia.org/wiki/mpeg-2 MPEG-4 A proprietary codec and wrapper standard for audiovisual materials. MPEG-4 is controlled by the MPEG Licensing Authority (MPEG-LA).A wide variety of MPEG-4 codecs are available, including H.264. Source: http://en.wikipedia.org/wiki/mpeg-4 MXF Short for Material Exchange Format. MXF is an open-source container format standard for audiovisual material. Operational patterns include OP-Atom, which specifies that each file can only hold one track of essence, and OP-1a, which allows multiple essence tracks in a single file. Sources: http://en.wikipedia.org/wiki/mxf, http://www.mxf.info/ P2 Short for Professional Plug-In. A file-based recording format developed by Panasonic in 2004. See pages 4-8. 36