Good morning. Today, basically, as Brett said, we're going to talk about how to get data in and out of Final Cut Pro. And really, this discussion is focused a lot on project data formats and media data formats, how to make everything tie together so that you can actually not only work with Final Cut Pro and Apple's other professional applications, but also build a set of tools that other people in the industry will find useful to actually get production done and do things like high-end Hollywood films and television production.

Certainly, and also various strategies for extending sort of directly Apple's professional applications. We're going to talk a lot about specific project formats and media formats and again, sort of what type of tools and some examples of some things, solutions you might actually be able to build using these things with your software. Like to start off talking about project data and sort of begin the discussion with what is project data. It's sort of used different terms in the industry. It's avid for things like compositions, final cut projects and sequences. If you go into a compositing application, it might be a composite. Or if you go into Shake, it might be a Shake script. And really what the key thing here is this is the data that your users or our users spend the most time creating. Certainly they'll capture media assets, they'll get stills from the Photoshop artists, they'll get music from their audio person.

But they'll spend the most time in software aligning these elements, putting them together, applying effects. And so this is what everyone focuses on. a certain perspective when you go out into the industry and talk about putting new tools in people's hands, they get very emotional about this. They're spending this time creating this and they want to make sure that they can keep it, they can use it, and that they can move it around if they need to. Of course, since this is certainly the thing that people spend the most time on, it's also the most unique between different applications. And so it's traditionally been very difficult.

There are some very basic formats that have been around for a very long time. More attempts in this direction have been made in the last few years, but it's not an easy process. And certainly a lot of the work we've been doing for the last year or two has been to try and make this process easier. Thank you.

So we can talk about some legacy formats that some of you may or may not be familiar with. And a lot of these formats were designed like 15 to 20 years ago and originated with a lot of hardware-based systems, things where you would have a project, you would have your show you're putting together, and it would be, of all things, a floppy disk. Not quite back to paper tape days, but still pretty primitive.

And sort of the lowest common denominator here is what a lot of people call batch lists. And really what a batch list boils down to is if I have a bunch of source footage, like on a videotape, I'm going to have someone, the assistant editor, maybe the DP for the day, sit down with a tape deck and basically shuttle through that footage and write down the time, sort of the time codes of the particular pieces of media, the particular clips that we're going to want to use in our production. And just indexed by time code. And when sort of this move off of pads of paper in a digital realm, It's really just a delimited text file.

So you'll have some time codes, some name, maybe an identifier for the source tape. And it's just stored in a plain text file on disk. The users actually love this. And if you talk to film editors today or television editors, they still use them all the time, because it's just a text file. They can pull up TextEdit. They can pull up Word. They can pull up Microsoft Excel and change these numbers. And they're very comfortable with that, because they control exactly what's in there. And because it's a tabulated text file, it's very easy to generate, very easy to parse. So pretty much any modern non-linear editor, at least in the prosumer and professional space, will support these. But they're very limited. Here's a very basic example of a batch list. And it's talking about before just a tabulated text file with a first line with a header with all this information on it. You see clip name, time code, and real identification. And sort of moving beyond just identifying pieces of media that one might work with, you move to an EDL. Again, this is designed for hardware-based systems of the past, where you'd have a huge bank of tape machines on one side, a record deck on the other, and monitors. And you sort of queue everything up so that it would record at the same time. And just basic edits, sort of an event-based model with times and effect identifiers.

Although it's limited, sort of two tracks of video, four tracks of audio, a lot of this based on sort of switcher technology of the day. And sort of like batch lists, a lot of users out in the field love this stuff to this day, because you can open one up in a text editor, and if you train your eye, you know exactly what to look for. So if I put together an hour-long show, and it's just not going out to tape correctly, I can open it up and fix it. It's a bit more difficult than a simple batch list to parse, however, because there's a lot of data in there, and there's also a lot of different formats. Sort of everything started with one or two de facto standards about 20 years ago, but now you've got maybe about a dozen different formats for different manufacturers' gear, different tweaks for different hardware, and even different effects processing gear. Here's a very simple EDL. And as you compare the batch list, It's kind of frightening. An awful lot of time codes there, comments for effect IDs, things like you compare a dissolve with a D and a wipe with a W012. Not very friendly to parse to understand.

So sort of moving on, Batchless and EDL sort of got more contemporary formats. And certainly 10 years ago, beginning of the nonlinear digital revolution with Avid, everyone saw that these formats really were lacking in a lot of ways. And so more contemporary formats were created to go in their place and sort of address a lot of capabilities of modern systems, things like, well, you can go beyond two layers of video or you actually want to get down to effect parameters. You might want to be doing things like throwing a Gaussian blur where you're keyframing the amount of the blur over time or doing that fuzz filter where you're fuzzing someone's frame out. But unfortunately, due to a lot of these efforts started, these formats were generally binary formats.

So you'd have some structured storage model, and you would encode all this in binary because it was cheap and it was small. But at a disadvantage of now a user or even a power user or a developer can't directly look at it. So you introduce a lot of library requirements. And it's pretty complicated to generate.

So if you look at some examples we'll talk about in a moment, There will be sort of a small set of tools out there to work with these files, but really not a community of large general tools to do things. Sort of the best-known example of a contemporary format would be OMF, Object Media Format from Avid, created when they actually tried to unify sort of audio and video products about seven or eight years ago now. It was based around some Apple standards at the time, OpenDoc and Bento, and actually sort of describes for two models sort of what they term a composition-only OMF file, basically just a description of your edit, your effects, and the elements within, versus a combined format where you actually store your media all in one container. Really big file, really hard to move around. Of course, at this point, it's more or less abandoned.

And part of that was Avid's move to more of a cross-platform system and some issues with basically bringing Bento libraries on different platforms. And really where it's used today a lot is in audio post-production systems, in that you'll have Pro Tools, one of the most popular non-linear audio editors today that actually still use that format.

Moving forward from OMF, in order to address this situation, the Advanced Authoring Forum was founded four or five years ago by a consortium of companies, including Avid and Microsoft and Adobe. And basically they tried to take the lessons from OMF and build a new format that still was based around a binary container format, this time Microsoft Structured Storage, but actually have it more be of an industry standard format so that you could take media and projects between different applications and different systems.

Unfortunately, it was sort of a mixed success in that while a lot of the basics, a lot of the elements that would be sort of the equivalent of an EDL made it into the public specification, a lot of things really didn't. And those are all the really interesting things today, things like layering information, compositing information, filters and effects. A lot of this is sort of termed as black metadata by people using AAF and where sort of one company will define their own little black box inside of this open specification, so you really can't get to it. And of course, a lot of companies do support the general version of the AAF standard, Avid, Quantel. And Apple actually joined the advanced authoring forum last year and is working on AAF tools using the efforts of AutomaticDoc.

So moving on sort of the future, there's been a lot of movement, especially with the open source move the last few years, toward more open formats. AAF and OMF are really interesting, but because of a lot of the issues, it's sort of very difficult to join the club of working with them. It might be a lot of effort to use binary formats. There might be library issues depending on the platform and the whole black metadata problem. And sort of the key concept of a lot of these formats has been open access, fully documented data, everything open, no real issues with data access. And also trying sort of getting back to the capabilities of batch lists and EDLs where a technical user could open one up and see what's inside of it and actually make changes or simply have some faith that this project that they spent a month creating will actually be useful in another year if they move their media to a different system. And also of course trying to minimize platform and library requirements. And to address this, we've actually come up with a format we're calling XML Interchange Format, working on it for the last two years. And we introduced it and announced it with Final Cut Pro 4. Just uses XML. Everyone loves XML. It's easy to parse. You can use it in pretty much any platform. And it's relatively self-documenting. And there are a lot of tools out there to use it. And power users can open the thing up in text editor or even a structured XML editor and make changes to the data. For our XML Interchange Format, we've gone to a lot of effort to sort of try and make it a superset of all formats. The goal is really to expose all of the functionality inside of Final Cut Pro, sort of no black data, no weird undocumented little hooks, and just open everything up. And a lot of this was the goal of trying to be able to base other formats behind XML. So working with Automatic Duck, we have import and export support to AAF, but going through XML in the middle. Since XML is a superset of what's at least publicly available in AAF today, then it's relatively trivial to do the translation and then bring that in Final Cut Pro. The one issue that RxML format does not address is the issue of embedded media transport. So the idea that I could have one Mondo file, which certainly is easier to move around today than it was seven or eight years ago, but one container with my media and my composition information in sort of one box. And we really didn't feel that that was an important issue right now. Certainly there are a lot of different workflows. That model does not necessarily meet everyone's needs. And it also tends to make the cross-platform, cross-application issue much more difficult. Different hardware, different software may have different requirements for streaming data or moving data around, and trying to sort of encapsulate it in one standard can be rather difficult.

And here's a very basic example of an XML file. It's similar to something that might have been defined, that would have been defined in the Batch List example earlier. As you can see, it's content-based. So the XML, so the various keys are things that, if one was familiar with an online editor, they'd be familiar with a clip or a name or a duration. And sort of multiple formats as well. So if you look at time code definition, sort of have both frame count and frame rate along with additional string defining that data. Now, of course, Apple's not alone in... Oh, excuse me. There's actually one slide that was missing. Actually, at the moment, what I'd like to do is invite Harry Plate up to the stage to show off tools that Automatic Deck has been building with us to support AAF inside of Final Cut Pro. Very good.

Okay, thank you, David. Thank you. Okay, make sure we're looking at the same story here. First of all, Automatic Duck came on the scene here just a couple years ago. My son and partner is a video editor and got sick and tired of messing around with EDLs as he would move his sequences and compositions from an Avid into After Effects. And that was the product that we initially started out developing. What I've got here, well, let's see, in fact, we wanna delete that cuz I wanna import the Chrysler example.

Underneath literally the import menu, you'll see a pick that allows us to bring up a dialog that allows you to select. In this case, I'm going to grab a Chrysler example and an AAF file. Again, this was a short commercial piece that was done a long time ago. This process opens an AAF file, parses it, now goes off and searches for footage. By the way, this footage now is represented by OMF files, this entire sequence being created by an Avid symphony. I think it was about two years ago, it's been one of our favorite examples to test things. So it's fairly straightforward.

We create an XML, the XML now is being read by Final Cut. And we should see a Chrysler example now up here in that project window. And we'll open that up. And sure enough, here's all that metadata. We had a couple of audio clips. Let's make this thing look a little more attractive. We'll fit it, show you some more, some more information. There's markers, dissolves, video, etc. And this is something that when we did this manually some years ago, this took an editor four hours to reconstruct in order to get all of the time codes, etc, done correctly. So fairly straightforward, again, you open an AF file through the magic of Microsoft Com and a binary library. You may or may not succeed in getting everything, but it's a challenge. You track down all the metadata, you track down all the media, you open up OMF files. We reconstruct QuickTime reference movies so that we don't move any video. So the reference movies are very fast.

And then ultimately Final Cut is able to import that. An entire description, of course, is passed via XML. The opposite case is fairly straightforward. I can take that same example and I can turn around and export it. And we'll just drop that thing out there. And now we take that XML. Well, let's see, we better replace that. We don't want that one anymore.

I'm going to read a little bit more. reconstruct an AF file based on that XML description. Fairly straightforward. This case it comes back and says, hey, wait a minute, you've got some effects there that we can't represent in AF. And that's fine. Our documentation will fully tell you exactly what you're doing wrong. Nope, so let's see, I grabbed the wrong one, but we don't need Internet Explorer. But we do want After Effects. And we'll find a side of After Effects as soon as I close down that.

It's a simple import process yet again. And I can grab that Chrysler example, import it. And it's the same process now in the Adobe After Effects world where you open up this file, parse it, grabbing all of the media references as necessary, using them directly in the case from Final Cut because we already have the QuickTime movies. And we create a composition, again, just a different nomenclature, no longer a sequence as in the Final Cut world, but something slightly different.

Now, a timeline in the Final Cut world is quite different. They show layers each on a separate horizontal row versus the timeline that you might be used to inside a Final Cut. But nonetheless, people like to finish inside of After Effects for a variety of reasons, whether it be the effects, the color correction, or whatever. But again, I emphasize, XML is under the covers. And the ability now to get into Final Cut, of course, we've had customers for a long time crying for that kind of capability. So it gives Final Cut now a tremendous edge now in the complete workflow of any post production facility. That's it. Back to you.

Thank you, Harry. It's a very powerful example of these sorts of tools. But sort of talk about maybe what other people have done in the industry surrounding XML, because certainly it's not a new format. It's not a new idea. Actually, excuse me, wrong slide. A little bit more detail on our XML interchange format. Sort of the big question that we've gotten since NAB of this year when we announced XML is when will it be available?

Well, today we have a public beta available on the WWDC site. Simply go to connect.apple.com and log in. It's an early build, but shows up, gives you import and export XML commands inside of Final Cut Pro. Documentation there on the format. Again, preliminary stuff. We'll be updating it on a regular basis until we hopefully release it later this year. And we're also basing a new plugin API on this data format. Certainly the commands that Harry was able to use with his software were written using this new API, and we'll be getting that out to you as soon as possible. But more importantly, sort of one point to emphasize is we really want your feedback. We've been working on this for a long time. We've talked to a great deal of people in the industry about that. Another gentleman I'll actually bring up here in a few minutes that has another sort of compelling tool based on this. But we really want to hear what you think is missing or what can be done better or sort of what your needs are. There may be various workflow scenarios or various tools that you want to build that we just haven't thought of. And any of that feedback is incredibly valuable. And we will be releasing this in a final form to end users and developers by the end of this year.

sort of what other people are doing. The AAF forum actually in the last few months has formed a working group to discuss making an XML representation of AAF that's standard across different applications. Sort of an interesting development. They've certainly been talking to a lot of the same people that we have and come across a lot of the same needs in terms of sort of workflow scenarios that where sort of binary format is inconvenient and not even necessarily media, sort of media containers necessary. And of course, there are a lot of other new applications that are just using XML as a base file format from the get go.

Some strategies for your application, should you want to play nicely doing data interchange. Any form of data interchange you can do is incredibly helpful. Even if it's primitive, just something that at least is documented or maybe in a plain text form. A lot of people in the post-production community are very creative and amazed at the amount of pain people will endure to sort of have that safety feeling of looking at their data. So certainly anything you can do is good. Conventional legacy formats, if you can support them, that's great. It can be a lot of work. It can be a lot of debugging. If you can't, then we encourage you to at least look at doing some more modern open formats and sort of allowing other people to write translators in the same way that Automatic Duck has. Opening that door gives you more leverage without necessarily expending a lot of engineering effort. And certainly, open formats are great. They level the playing field for everyone. And in the end, everyone wins. Developers sell more software, and users get the tools they need. And it's a very good thing.

For Apple's personal applications, Final Cut Pro 4 at present has native support for EDLs, Batchless, and of course XML very shortly, and OMF through AAF, or OMF and AAF through the automatic duck guys. ShakeThru, which I want to mention for a moment, is a little bit different story in that at the moment there isn't really an XML representation or direct OMF or AAF support, but their project file format is at least sort of a plain text file. A ShakeScript is something very similar to C or C++ that sort of defines the structure And it's an example of something that is rather technical, but at least it's in a form where other tools can generate and parse this information. And that's one of--sort of one of the details that has made Shake incredibly popular and powerful in the high-end post-production industry.

So I'd like to move on to exchanging media. And so we talked about the project composition data side of the universe and getting that data that-- and you just spent a lot of time creating-- move back and forth. But media is also incredibly important as well. Why do you want to do it? Well, there might be formats you don't support in your application. It may be that you support still image files, but you don't support movies. Or you're based around video or audio, but you really can't deal with container formats.

By allowing users sort of to import and export data in different formats, you just sort of increase what's possible and what users are able to do. By exchanging data, you can leverage things in other applications. You might have a wonderful compositing engine, but you really don't do 3-D animation. If you can import and export data, then you can bring in 3-D animation from some other application and work with it. Hardware support is an interesting one, in that hardware support, sort of the ability to output to decks or capture video from a deck or a camera isn't always the easiest thing to do and can be a lot of effort, and yet users need it. If you can import and export media, then you can leverage someone else's software to do that for you. And finally, in a real production environment, certainly there are some tools that will fit the entire bill for production, but most times there really isn't. A lot of high-end facilities like to pick and choose between different tools for different uses, And by exchanging media cleanly, you allow yourself to be inserted as part of that pipeline. And there are a few other details that you need to think about to make that practical, and we'll get to those in a few moments. Thanks. Some of the traditional difficulties had in sharing media, lack of public formats. Certainly there are a lot of formats, but when you move into the higher end of the spectrum, you get some more private things. You get codecs.

The details aren't necessarily there. Certainly you can get a piece of code compiled for one CPU but not for another. And some formats are more difficult to work in than others. An example of OMF and AAF, you basically have to wrestle with what libraries to compile and build and load to use that data on different platforms. There's also a big issue, which isn't always necessarily considered, is quality and conversion when transcoding media between different formats. In the computer world, RGB is great. That's pretty much what we all use. When you move up into the high-end film market, you've got sort of nonlinear, high-bit depth RGB, but when you're in the general production market, you've got YUV video to deal with. Conversions to basically YUV to RGB and back again, You lose color because there isn't complete overlap in the spectrum there. And that can be an issue in some circumstances. Traditionally, it's been identified as an issue for sort of the broadcast online market. They're a little bit more open to that these days, but it's still a problem, especially when you move up into the high-definition market. And licensing issues. Certainly, you may have this wonderful codec, and there may be some source code floating around on the web, but you can't really use it because of licensing issues. And sort of by supporting more open formats, you can help to get around that by at least getting a format that will go into another tool that maybe does have the licensing situation worked out.

just sort of some common formats everyone's familiar with. You've got all the still formats, been around for a while, for the most part open. Of course, they aren't really that great for video. A lot of people early on sort of took those still formats and just numbered them and put them in a folder and played them back. And that can be rather CPU intensive, and certainly there are a lot of Unix workstations that that's just the best way to deal with it because you can get to any frame really quickly, but it's kind of a pain to move around.

Certainly QuickTime is a great container format for just stringing together. There are a lot of video images. Do it uncompressed. Do it in various codecs. In fact, we actually have a lot of open codecs at Apple. Final Cut Pro 4, we introduced some new open uncompressed codecs for 8 and 10-bit video where the details, sort of the bits, are completely documented for free. Of course, we have our own codec implementation. But should you be on another platform, another piece of software, and you can actually use QuickTime, all the details are there so that you can parse those out and use those.

And certainly have Microsoft formats, AVI and Windows Media. Traditionally more used in the delivery space than the editing space, although certainly some low-end tools make use of them. OMF and AAF, again, dual design, sort of for media container and composition container, so you can embed data in there. Cineon slash DPX is a format that Kodak came up with about a half dozen years ago for the film industry, for sort of high-resolution, high-bit depth, nonlinear RGB images. Details for that are out there. You have to dig to find them. but a lot of high-end tools like to use those frames for sort of final finished film renders and effects work. And, of course, MPEG-2, just pure element streams you might spit out of Compressor or DVD Studio Pro. Not really used... There's some movement toward using MPEG-2 in the editorial space, more for iframe-only, basically in-frame edits or files, as opposed to the long-op stuff traditionally used for broadcast, but still a lot of that stuff out there. Again, really quick, some common audio formats, AAF and WAV, uncompressed, everyone knows them, more or less the same except the bits are flipped.

SD2, and I actually bring this up because it's an interesting example of sort of a partially public format. Certainly there are a lot of tools out there to read SD2, it's not a hard format to reverse engineer. Unfortunately this is one of those licensed formats that I mentioned earlier where you exactly create a product that will write SD2 files without a license from Avid, actually.

It's interesting in that Pro Tools in the past has made very heavy use of SD2. It makes it a little bit interesting to get data into Pro Tools sometimes, but just sort of be aware. Of course, QuickTime, Windows Media, OMF and AAF, containers for audio formats as well. And of course, there are a lot of popular compressed formats now, MP3 and AAC, more for delivery, but we tend to see a lot of these in post just because someone gets a that that's the only format they have and need to bring that in.

Talk about MUX formats for a moment. Formats where basically you have audio and video, potentially ancillary data combined together. Very handy container you can just move around, something you can just open up and play back. Of course, QuickTime's great for this. You can put pretty much anything you want in a QuickTime movie. Of course, when you get to applications like Final Cut Pro, there are some conventions that you have to observe, things like timings, video times, etc. AVI, Windows Media, again, more delivery formats, but they do support MUX data. OMF and AAF as well can support this.

MXF is something that's interesting to mention in that it's a format that Sony has been working on for the last few years with SMPTE. And MXF has actually been designed as a subset of AAF with the goal of creating a MUX data format that hardware devices could implement cheaply so that you might have a camera that's recording direct-to-disk and you need some format to describe that data and interleave it together in a completely, ideally, platform and software independent manner. Get the specs for that through SMPTE. It's starting to gain momentum with some new devices that have been coming out that have been announced this year. Still sort of ramping up. Interesting to see how common that becomes and sort of if it scales from the low bitrate compressed formats up into uncompressed. And just for completeness, MPEG-2 transport streams that you might get off of an antenna for HDTV or program streams that you might have on a DVD. Thank you.

I also want to talk about metadata for a minute. We've been talking about sort of the core, audio and video data, the bits that represent the things that you listen to and you see on the screen. But metadata is actually really important and becoming a lot more important as time rolls on. So if I've gone out into the field and shot 40 hours of footage, I need some way to identify that footage.

Certainly by simply being on a tape-based device, there's time code. But when that media is brought into the digital realm or brought onto a computer hard drive, there needs to be some way to track it other than the file name. And this is really where metadata comes in. Traditionally, pretty much any non-linear editing system has tracked time code. So basically you can embed a set of numbers in a media file that track where that came from on a tape. And you may attach that with a source tape identifier as well. Traditionally, it's been stored in pretty strange locations just because it's really been an afterthought.

It's remixed formats together, it's great, playing back, wait a minute, where are we going to put timecode? Fortunately with QuickTime being a very general architecture, it's actually easy to drop timecode in a logical location for a change and even put other information in. You can utilize things like text tracks and user data bits just to drop data into a file and at least be confident that it's writing consistently with that media on disk. Certainly metadata, if you go into a professional environment, it's required. They need it there. So it's very important to be able to read and process that. And it's just becoming more important. As the amount of media grows, as multi-user systems grow, the value of having that data is just all the more important.

So just some quick strategies on things that you can do to deal with media interchange correctly. You want to support as many media formats as possible. That might involve using a rich media engine, like QuickTime to do the translation for you. It's quite handy. Certainly there are other options out there as well. When you're processing media or importing it into your system, you really need to try and keep it as close to the native format as possible. Sort of the biggest thing that I get is YUV to RGB conversion. The reds will get weird. The color will get muddied if you don't do it right.

And that's kind of a big deal if the native acquisition device is YUV and the output device is YUV, but in the middle you're going through RGB. So if at all possible, you need to try and keep that in mind. Audio is another situation where if you've got a 24-bit audio recorder out in the field, you want that audio to stay 24-bit when it gets to the audio posthouse in the very end. And again, metadata. At the very least, pass it through. Ideally, access it and display it and edit it. But if nothing else, if the data simply passes through your system cleanly, then your users are gonna love it.

Apple's applications, certainly QuickTime. We love QuickTime. It's pretty much our universal container format. We use QuickTime as a translation conduit for other formats. We have a lot of great codecs. I mentioned earlier the uncompressed codecs we can use with Final Cut Pro 4, the pixel codec announced here at the show, and traditional things like animation and CinePack and Sorenson. And timecode and metadata.

We do currently Final Cut Pro 4, supports multiple time code tracks and QuickTime files, multiple tape source identifiers. And as time goes on, we're going to be expanding that. We're going to have more support for metadata and not less just because it's come up so often from all of our Pro customers. And we also now have support for 24-bit 96-kilohertz audio along with multi-channel audio in Final Cut Pro 4. That all comes in at the moment through AFF files. The number of formats we bring in will be expanded as time goes on.

So we sort of talked about project exchange and media exchange. And I sort of want to bring them together and sort of plant some ideas out there for how you might make use of these. It's not always obvious if you're not in a post house or at a film studio sort of what the opportunities are to sort of enhance and extend things and sort of where new and unique applications and small tools might fit into the picture. So one of the biggest requests we get now from post houses is sort of media asset management, where a post house is only sort of getting more work as time goes on. They may have six projects going at once. And to have sort of project data and media scattered across 40 different machines is really kind of a pain. It's a pain for backup. It's a pain for tracking. And it's just a pain for workflow, and that one machine might be locked on a project. And sort of by building a central archive, you've got one place where you can collect and track things. And you can do things like track the revisions of a particular element. You might have something you shoot on video. It comes in. It's captured. Great, you've got revision one of this element. Now it needs to be color corrected. Then it needs to have maybe some effects applied to it. Maybe it needs to have a lower third title applied to it. Sort of almost do versioning like we're used to in CVS, but with media elements so that if something goes horribly wrong in the process, you're not going back to the original tape to bring the thing in and run it through. You can actually go back to maybe step number three where the issue came in.

Review approval loop is very important. Sort of the concept--traditionally, if working on a show, I'd have to get approval from an executive, approval from a client. I'd have to take the project, dump it out to VHS, give the VHS to a courier, send it across town, have them look at it, send something back, give it a call. Having sort of automated or at least electronic review loops is incredibly, incredibly handy. So certainly you could send an email to the client and say, "Hey, the spot's up. Take a look at it. Log into a URL. Look on a web page. Play it back. Make some notes." and sort of cutting the time all that review processes take. And also, coming back to sort of central location, backups, and even just status, looking at a project, seeing what elements are completed, what elements are left to be done. And it only sort of primes things for multi-user products in the future. This is interesting where there are products in the marketplace that many people today consider to be multi-user, but really are just sort of media sharing. And sort of the idea of having sort of direct collaborative workflow where two people might be working on the same sequence, at the same time is something that's not necessarily around today, but is coming. And when it gets here, it's going to take the market by storm. And by encouraging this infrastructure and building tools that tie into this infrastructure, it's only going to make this easier.

Another very powerful example of this will be linking specialized applications. No one piece of software does everything and it's not really even possible. There are things that might be specialized to one particular company, things that might be specialized to one particular market segment. And it makes sense in circumstances to use specialized software for specialized tasks and then be able to bring data back and forth. And it can also make you sort of different skill sets. You might have people who are less technical who just need to organize something, and people who are more technical who are sort of going to finesse things and give it that final polish that it needs. And even down to sort of allowing for low-end hardware at one phase, high-end hardware at another, or even going to really dumb hardware at some point just for an executive to view And at this point, I'd actually like to ask Michael Johnson to come up and give a demo of an example of sort of linking specialized applications using XML and media exchange technology. Thank you.

Hey, folks. So this is a little tool that we wrote last year, and we've actually continued to work on it, and it's one of these things where we heard about the XML stuff that the Final Cut Pro folks were doing a little while ago, but then, you know, they have a product to get out, and so you're like, oh, that sounds really great. We're looking forward to that. We'll be very excited when that comes along. So they got us some stuff a few months ago, and we looked at it and gave them some comments, but really weren't using it or anything. And then last week they stopped by and said, well, you know, we're going to have this talk there. We'd like to do that thing, and we'll get you that spec, that code that will let you read the XML stuff and your Final Cut thing there.

And we had some little kind of going back and forth on that. And I think I actually got the thing from David, I guess it was about 45 minutes ago. Yeah, so we actually did it over there in the session in the back there. We actually said, oh, look, it actually works. So I'm actually here more as a developer, as a sort of a fellow developer here, and just... When you do things like this, when you deal with custom tools, it's so nice when it's a file format. Because we deal with OMF and things like that, and OMF is just like, you know, it's just this thing. It's just this blob of stuff, and there's all these libraries, and you have to compile them, and you have to go get them, and yes, you have the source code for them, but then, oh, you've got a new compiler, and, oh, we've got a link against that. Oh, no, is it C++? Oh, yeah, okay, we've got a link against that. Oh, no, recompile that part. You know, this is like, it's a spec, it's a file format, it's text. And what's also fun with it is that, so David and the Final Cut folks, they're at Apple, and so they have all these people who know all sorts of stuff about programming, like all the core foundation things and stuff like that. And, you know, I'm an old Unix Next Step Packer guy. I don't really know from core foundations. So if it's not Cocoa, I'm really kind of at a loss. But so it's XML. So I just go out in the net, I get XPAT. And actually, that's for parsing it. But just for this little thing here, let me just show you this. We've got this simple little program here, which just lets you go and time things out for your whole-- You know, we're good on that. And then if we actually want to... Let's see if I put it out there. It's in my debug menu. I got the idea from Safari. And so let's see. So if we just say... Let's call it demo. And then... So all I'm doing there is writing out strings and then telling the NSString to write itself out. So I got me a little XML file there. And let's go and say... Import XML.

And let's just see. That looks good. Yeah. And-- So now we've got that and it's got our timing on there. Now actually, there's one really neat thing about this, which is not at all obvious to this, which is that this is actually going out-- and those are actually FilmRes storyboards. And so that's actually a really nice thing about stuff like Final Cut is I just specced in the XML thing. I said, oh, well, I'm going to give you some media and it's actually this big, even though the media is actually like two megapixels. actually just do it as a, you know, whatever it is, 720 by 540 or something. And it just deals with it. It's just good. And so let's actually just go look at the... Let's go look at what that looks like here. Because there's a couple of interesting things in terms of-- let's see, how big do we have to make that?

You can actually read that. So this is what we wrote out. And it's just text, right? And I'm one of those-- and you don't have to have all the indention or anything like that, but I'm one of those people who, when you write the code, you might as well make it so that it's readable. Because unfortunately, David is completely correct in that Text file formats will be edited by power users, sadly enough. We tool makers like to say, no, we'll give you a really nice way to just-- don't open the file. Don't edit it directly. But, and again, this is where the whole file format versus the 17 libraries that you have to link against is a great thing, because in a production environment, in a real production environment, you have all sorts of people who you cannot keep them to the purity of your code. You want to write in C or C++ or Objective-C or whatever your particular thing is. Well, too bad. They have a cartoon to make. And so if they need to write a Perl script that's going to go over this thing, grovel this thing, move this thing into here, or they've got to write some Python that's going to do this, or some C shell, or an Apple script, or whatever, God bless them. They have work to do. And so this is actually what's really neat. And I just want to point out one thing that's really, really neat in here.

I don't know if this is actually true, but I will take some credit in giving them the-- saying at least that this was a really good idea-- which is this little guy here, the path URL. What that means is in this XML file format, your media, it's a URL. And I'm pretty sure that the Final Cut, the version of this as it's going in here, it really wants file URLs. But from our perspective, we write custom stuff. And we might have a web server in the way of that media there, and it's going to serve up that piece of media to you.

And because it's a URL, if you're writing custom things that's using this file format, you're all good. You can just put an arbitrary URL in the way there. And if you want to have your version control system in there, if you want to auto-generate that piece of information, there's all sorts of interesting things you could do with that. And like I said, the format is really, really simple.

And for parsing this stuff, I used XPAT. Nice thing with XPAT is it's out there, and most languages have access to that. It's just this very simple C library. And XML is just-- It's just really nice. And it's very wordy. And it's very wordy. But that's actually great, because you write a program and you parse it. And it's also one of these things of where it's not as fragile as normal text formats, because there's all sorts of tools for seeing that you screwed it up. And it also scares away the casual hacker on the thing there, because it's like, oh my god, there's this much stuff to describe that thing. I'm not going to mess with that. Maybe I'll use their tool for it. And then, of course, other people will actually take it as a challenge. And then I'll actually write something useful with it. But it's really good. And it's also one of these things where you can do very, very powerful things with this and some really, really neat things. and I'm actually looking forward to when this is finally out there and shipping. I think this is actually going to be a boon, not only for us in our universe, but for all sorts of little shops that are using Final Cut to do their whole, to edit their major piece with. This actually gives you a very, very easy way to write little pieces of glue tools that will actually do all sorts of sophisticated things that normally you just would have this big black box of data there. And unless you're doing stuff with the Avid and you buy the great automatic duck stuff, normally you'd be locked out of these things. And I just think this is a huge step forward. And I really highly recommend that people take this very seriously because this is actually a new thing. This is actually something that we've spent more time than I would care to admit in a public forum getting things in and out of our editorial system. and that's a very, very hard problem. It's a miserable problem. It's not a problem that you want to deal with and with this thing with the XML stuff, it's actually pretty fun because now you can write, you know, this is a little storyboarding tool that our storyboard artists use and they want to bring something in and they want to do some more work on it in Final Cut. It's very easy to do that. We can also then round trip it back in and that's just something you just couldn't do a year ago. I mean, you know, you had to be us and even us that would be like, you know, miserable. So I think it's very exciting. Back to you, David.

So sort of one final example I'd like to talk about today. Sort of the concept of production pipeline. And this is not so much an editorial, so much as actual final rendering and production, where you're trying to take a series of disparate tools to get a certain look for something. Earlier I mentioned the concept that there may be one application that does a blur really well, and one application that does a composite really well. You just want to smash them together. And a lot of people do production pipelines this way. They may render and shake. They may pull it into After Effects. They may output it using Compressor. And sort of allowing tools to be hooked into that pipeline is incredibly compelling. And part of this is project files. XML is great. Certainly you can endure the pain of OMF and AAF. I don't recommend it. But if at least you can sort of concept something to drive your software from the outside, that's sort of the beginning of it. And then, of course, we move on to media interchange and trying to bring media through a system without loss in quality. or at the very least known loss of quality. It may be that you have a tool that doesn't make sense to work in YUV, but if at least sort of you can document what the effects of it are, that's gonna make someone more willing to give it a shot and see what it is. And scriptability is great, at the very least just dropping something on and having it go, but technologies like Apple Script are very useful. They're very interesting to implement at times, but they're incredibly useful.

And try and summarize things. Project data interchange, import-export, wonderful thing. Open formats, wonderful thing. If you can move data through an application, actually, and something I sort of mentioned a moment ago, if you can move data in and out of an application, it's actually going to make it easier to be adopted than harder. One of the challenges we've had on Final Cut Pro has been convincing people that, you know, that $200,000 thing you bought three years ago, it's really not all that. You need to try this PowerBook. And their response is, well, that's great, but that thing in the corner, I know what it does, and I know I can count on it, and I'm just really nervous about bringing my project into it and not being able to get it out again. If they know that you can bring data in and out, they're a lot more willing to try it, they're a lot more willing to throw it in, and if it's great, they're a lot more willing to adopt it because they sort of have that safety layer. Media interchange. Again, just like project data, if you can pull data through an application, know what the results are, It's just going to make people more willing to try it. And combining the unique abilities of your application with others just makes it all that much more powerful.

And this is not strictly data interchange, but alluded to a few moments ago, extensibility and scriptability is very important, both sort of in workflow systems and in production pipeline systems. If you can very basically control how something sort of spawns something, spawn a process to go do a render via script, via just an import file with some extra commands in it, it just makes the whole process easier and makes it possible in some cases.

And scripting is great because if you have those wacky power users out there who are just bitching because you haven't written that one tool to do the special clip move that they've been demanding for three years. If they can script it, then they can just go off and write it And a couple strategies, again, some of the same messages. Open project media formats are great. Scriptability is great if you're doing an application. If you're writing a little tool, you want to hook into that data flow somehow. You might write an integrated plug-in. You might write just a small application that takes the output of one app and converts it to another, just like the automatic duck guys have done. And if you can integrate tools into an application, it's very compelling. I mentioned a little while ago that sort of based around XML, we have a new plug-in API coming soon. And we'll actually be discussing that on Friday. And being able to, again, like the automatic duck guys have done, being able to insert a tool directly into the UI of a larger application like Final Cut Pro or Shake or something else just makes it easier for users who may be very artistically talented but not technically talented to get their head around something and use it.

And sort of our direction for professional applications is we like open formats. The whole concept is there's an ecosystem. There are tools of varying sizes, and the users don't really care where they come from. They just need them to work. Open data formats allows everyone to play and everyone to talk in the same space. We like QuickTime a lot. We're pushing a lot of-- we're sort of pushing for QuickTime to provide open, high-quality data interchange methods.

So new codecs, like our uncompressed codecs and Pixelit. Basically trying to set the Mac up such that if you're doing high quality video processing, it's just easy. Because you don't have to deal with things like file I/O and gamma conversion and hardware output. The pieces are there for you to build into your applications.

And extensibility, extending application through plug-ins, through scripts, et cetera. That just makes it all the more powerful. Because then power users can do their thing, tool developers can use their things. in the end, there's just a much more compelling solution. And finally, I've mentioned earlier, we really want your feedback. Anything you feel we're doing right, we're doing wrong, tools we may not have thought of, things that you're trying to do with Final Cut Pro or other applications that you just can't do, we really want to hear about that so that we can adjust our direction accordingly to try and address your needs and sort of make this space just a lot better.

And let's see. One other session we had this week you might be interested in. We actually have a session on Friday talking about all the different plug-in APIs of the Apple Pro application support. Shake, Final Cut Pro, Logic, Soundtrack. That's on Friday at 3.30. Also be giving some initial details on the plug-in API we're hoping to wrap XML around later this year. If you need to contact people, first person is really Jeff Lowe. He's the evangelist at Apple for Pro Video Applications. He's an excellent starting point. He'll vector you off to whoever you need to get your question answered. If you have questions on Final Cut Pro data interchange, feel free to email me, and I'll get back to you as soon as I can and, again, vector you off to the right person if I don't have the answer to your question. Thank you.