The present and future of post production business and technology

We were talking a couple of night ago and discussing how various of the NLE developers are dealing with the Carbon/Cocoa transition. But before I get to that a disclaimer and some background.

Disclaimer: I have no inside knowledge. If I did it would almost certainly be under NDA and therefore would not be shared. Everything I post here is based on publicly available knowledge, if not that commonly known. (Depends on how much you care about code and most people don’t.) So, I present data points, interpretation and extrapolation: in plain English, guesswork, but intelligent guesswork! PLEASE DO NOT CONSIDER THESE RAMBLING “RUMORS” OR HAVING ANY INSIDE KNOWLEDGE. THEY DO NOT AND ARE NOT RUMORS.

Final Cut Pro, like most software developed originally for OS 9, is built on a type of code called (for short) Carbon. The Carbon APIs (Application Programming Interface – the building blocks of code) allowed Final Cut Pro, Photoshop, Illustrator, Media Composer and thousands of other applications to make the transition from OS 9 to OS X “reasonably painlessly”. (Meaning, hard but not impossible). Carbon code runs just fine on OS X and is no less efficient in and of itself than the more modern Cocoa code.

So-called Cocoa code is the native language for OS X. It is built almost completely on NeXTstep, which Apple acquired when they acquired NeXT (and Steve Jobs) as a replacement for OS 9. Now, originally Apple said (at the 2006 WWDC) that there would be 64 bit versions of the Carbon APIs. This would have meant that Final Cut Pro, Media Composer, After Effects, Photoshop, Illustrator, et al. would be able to move to 64 bit versions without major rewrite. And so it was good.

Until a year later. At WWDC in July 2007 Apple reversed that decision and said that any application that wants to go to 64 bit would have to be rewritten to Cocoa.  Much gnashing of teeth in the ProApps camp and at Avid and Adobe. Not only can’t they go to 64 bit without rewriting but Final Cut Pro cannot start to use OS X technologies like Grand Central Dispatch and OpenCL until that rewrite is done.

I’m much less familiar with Adobe’s code but the current version of Premiere Pro was ported to OS X in the modern code era and is almost certainly Cocoa where it hits the OS X road. It is highly likely that the majority of the code is in a format that is common to both platforms with mostly interface-specific code for each platform.

That’s also likely with the Media Composer code but I have reason to believe that Avid have been progressively rewriting functional blocks of code from Carbon to Cocoa over the last several releases (since mid 2007 probably)!

Most of the ProApps are already written in Cocoa: Soundtrack Pro, Motion, DVD Studio Pro (when it was based on Spruce not Astate’s code) and Compressor. These are already in a form that makes it relatively easy to move forward to take advantage of modern OS X technologies.

Not so Final Cut Pro.  Now we do know that most of what has been added to Final Cut Pro in recent versions has been written in Cocoa. Apple’s Xcode development tool allows a mixture of code types in the one application. I’m uncertain whether Multicam is written in Cocoa but I’d expect it to be. HDV Log and Capture; Log and Transfer; Share, Master Templates etc are clearly also written in Cocoa. (The main evidence is that the interface is using the “ProApps Kit” interface used in Motion, Soundtrack Pro et al.)

So to the question that started the post: “Are Apple rewriting parts of the code as they go?”  I think the answer is yes.

One really strong piece of evidence is the new Speed Change tools in Final Cut Pro 7. The new interface is ProApps kit, not Final Cut Pro’s interface elements, which by itself suggests new Cocoa code. What is stronger evidence is that speed changes in XML files give different results when imported to Final Cut Pro 6 than they do when imported to Final Cut Pro 7. This is very strong evidence that new code is involved. (The old code would give the same result even with a new interface.)

One would have to extrapolate that the new Marker functions (with their new interface) has also been given new code but that’s much less certain as the Marker interface still shows the original Final Cut Pro interface style with new elements added. (Compare the Speed Change dialog and Marker dialog to see the difference.)

The rewrite to Cocoa, even assuming they don’t make fundamental changes* is very time consuming and a lot of hard work to rewrite and test. That there is evidence in the current release of work already complete strongly suggests that the team is hard at work doing what’s necessary to bring Final Cut Pro into the modern Cocoa OS X code era. But don’t expect to see a converted release any time soon. There’s a lot of work that the QuickTime team has to do to add functionality to the underlying QTKit API (The modern QuickTime API for programmers) that an updated Final Cut Pro needs. Right now there’s no support for QuickTime metadata in QTKit, for example.

* Fundamental Changes. We’ve argued this instead of watching TV as well. Most of Final Cut Pro’s functionality is just fine. There’s not a lot to be gained by totally redesigning and redeveloping the Transition Editor, for example. There are, however, two areas that I think it would behove Apple well to rethink: Media Management and Metadata views. Media Management in Final Cut Pro is now reliable, except for a few edge cases (largely to do with dual system and merged clips). Whether or not to spend a lot of effort (and dollars) to improve it that last little bit for the relatively small customer base that would benefit is a management decision I’m glad I don’t have to make!

I do think they need to do something more flexible with metadata support. Non-tape sources come complete with comprehensive metadata that Apple capture and insert into the media file. This support was added in my all-time favorite Final Cut Pro release – 5.1.2! Unfortunately the Bin interface has limited flexibility. While there are a lot of viewable columns there’s no way to add a column unless you’re the Apple engineer that does that!  Other NLEs are much more flexible. Media Composer will add as many columns for whatever metadata you ask it to display. Not so Final Cut Pro where the only simple way to view QuickTime metadata in a QuickTime file is with my company’s miniME. (Go on, download it. The free demo lets you view all QuickTime metadata in a file and export it to an Excel spreadsheet. Buy it and you can remap the metadata into Final Cut Pro’s columns.)

It takes years to make major transitions in software. QuickTime metadata support came in late 2006. With the advent of Log and Transfer, that support became valuable. So my informed guess is that a future release of Final Cut Pro will allow that metadata to be viewed and used in Final Cut Pro. It’s all there in the file and in any XML export. To me that suggests a foundation for some future construction.

Like I said, nothing more than intelligent guesses. NOT RUMORS. NOT INSIDE INFORMATION. Just me joining dots and I’m bound to be wrong about half of it. I just don’t know which half!

In a January article “Apple pushing TV Networks to slash prices on iTunes” and more recently “Apple to offer $1 TV shows in April” Business Insider/Silicon Alley Insider suggest Apple are pushing the price of programming through iTunes down, with the goal of selling “some shows” for 99c.

This is absolutely a step in reality’s direction but it still prices individual programs at well above the traditional income-per-viewer that networks have traditionally received, and way above what it would cost for an average viewer via a cable or satellite subscription.

At 99c, the content owner would get 65c per download as Apple take 35% and pays for the bandwidth (at about 10c a GB).

65c per viewer per show is right at the top end of what the big four networks have been able to command from advertising: per show, per viewer. (Even the Superbowl only gets 85c average per viewer per 3 hours show).  At the other end, the big four get a low of 25c per viewer per show.

But not all television is “big four” nor is it always worth the network premium. Take one of my favorite shows: The Daily Show with Jon Stewart. The best research I can find is that Comedy Central pays Stewart’s company about $5 million a year or $32,000 each for the 160 shows a year that are produced. The Daily Show has an audience of around 1.5 million viewers according to Wikipedia and other sources. Cost of production to Comedy Central is just about 2c per viewer.

Presumably Comedy Central are turning a profit between the 60c per subscriber per month they get from cable carriage and whatever advertising revenue is generated across the 5 or so showings of each episode.

And yet, through iTunes that show is currently $1.99 or 99c per episode if you buy a season pass for 20 episodes. (One of the few cases where a season pass gives significant savings). It’s still too much.

If Jon Stewart’s company sold direct through iTunes at, say, 10c an episode (because once watched it has little future rewatching value, unlike episodic drama or comedy) then gross revenue would be $150,000 per show or $97,500 after Apple’s cut. (Apple’s bandwidth cost would be around .6 of a cent in SD, or $8550 leaving Apple $43950 gross profit on the sales.)

On the other end of the equation, the content creator (Stewart) gets $97,500 or three times the income for the same show as working for Comedy Central brings.

So, while 99c TV shows are a step in the right direction there’s still a long way to go before Internet, on demand, video reaches fair price parity with traditional revenues. This is not an opportunity for the existing entrenched players to dramatically increase their margins: it will kill the nascent future.

You can get a great deal on the AVP Conference for either the whole conference or any single days, by using my discount code: BIGBRAIN when you register.

I’m talking about the Association of Video Professionals Conference Jan 28-30 at the Radisson Hotel, 6225 W. Century Bld, Los Angeles (just near LAX). This year the conference has some of the best trainers in the industry, including myself, Larry Jordan, Frank Rohmer, Mark Spencer, and Bruce Nazarian.

My session, on Thursday 28th is:  Awesome Titling

How to use all the Titling tools available in Final Cut Studio to create Awesome Titles: choose the right font; better typgraphic design; when to use Calligraphy, Motion or LiveType; and animating fonts and glyphs.   Be prepared to experiment, be inspired and be exposed to new possibilities with titles in the Final Cut Studio ecosystem.

Register and use my discount code BIGBRAIN and you’ll get a 10% discount on the full conference or any single day. That’s $20 off a day and $50 off the three day Conference package. But wait there’s more! Anyone that signs up for the conference using my promo code will also receive a free one year Gold Listing on the FindAVideoProfessional.com site (a $149 value).

It’s going to be a great conference. Come along if you want to learn how to make awesome titles and I’ll see you there.

In Apple’s latest release of Logic 9.1, Apple have turned on 64 bit support. Now, I’m not privvy to the internal workings of the Logic code – I don’t even own a copy as I’m not a musician or post-audio guy – it is my understanding that 64 bit support requires the App to be written in Cocoa, the more modern of the underlying coding languages for OS X.

Logic was originally released on OS 9 and Windows by eMagic, long before the advent of OS X. (Apple purchased eMagic in mid 2002, less than a year after the first release of OS X 10.0, and Logic was well established before that.) Logic was therefore almost certainly written in the older language and used Carbon (the older language) for OS X compatibility.

As I’ve written before Apple initially announced that Carbon APIs (Programming interfaces) were going to be released in 64 bit; and then at WWDC 2007 announced that the Carbon APIs were NOT going to 64 bit after all. Basically meaning that, if you want 64 bit support (and you do with RAM hungry applications) then you have to rewrite to Cocoa.

This release of Logic would suggest that work has been complete on making Logic a Cocoa application supporting 64 bit.

That is good news because Apple have another piece of Carbon-heavy “legacy” code that they need to rewrite to Cocoa if it’s to go to 64 bit. That application is Final Cut Pro. The action on Logic is another data point that Apple is very keen to get its applications to 64 bit as soon as possible. Of course, the Final Cut Pro team are also dependent on QuickTime to also support a 64 bit Cocoa API through the QTkit framework.

Right now, the QTkit Framework lacks support for QT features that Final Cut Pro needs: like the ability to read and write QT Metadata through QTkit. (This is currently handled by the older “deprecated” C API from the Carbon days. A deprecated Framework can still be used but Apple are giving notice that you shouldn’t use it. Unfortunately, there’s no current alternative to the C API for that functionality.) So, it’s not as easy for the FCP engineers as it might have been for Logic because this example is only one place where the more modern API does not yet support essential functionality FCP needs.

Still, I’m encouraged by the Logic announcement.

Of course, I don’t have any direct link into the mind of Grant Petty, founder of Blackmagic Design and don’t know more about the purchase of daVinci other than what Grant posted, but it’s such an interesting purchase that I can’t help but comment and guess.

Like so many of the industry’s giants of old, daVinci was losing money in the face of lower priced competition (Apple Color) and a reliance on mostly-obsolete 2K-limited hardware. On the other hand, Resolve is software only and resolution independent running on a cluster of Linux machines connected with Infiniband high speed data interconnect. daVinci also have Revival, although I don’t know anything about what advantages it brings.

Clearly, Grant thinks that the company has not been making the most of its opportunities and more focus on marketing and product development will once-again bring the daVinci brand to prominance. (Assuming it ever lost it.)

However, I don’t expect we’ll see Blackmagic Design suddenly want to start competing with Apple Color. I don’t think that’s the market and Grant himself seems to rule out that direction:

DaVinci Resolve is unique because it uses multiple linux computers linked together with InfiniBand connections and multiple GPU cards so you get the real time performance advantage it has. I donʼt think that can be lowered in price much, however over the next few years as technology advances this might happen a little. However, DaVinci is different to a DeckLink card because itʼs a high performance computing based tool. Our focus will really be on adding more features. Thatʼs what we want, and I guess others would too.

Possibly, some time in the future, a network of multiple Linux machines might be replaced by optimized code on some future 8+core Mac with awesome graphics card and an application written with Grand Central Dispatch and  OpenCL in mind. But don’t hold your breath! Combined CPU+GPU power has to increase a lot to replace multiple machines and the market is not that big.

I think the move will allow daVinci to continue developing their modern products and repositioning the company (to be operated independently of BMD) for the mid-size post house: those that have become dissatisfied with Apple Color but who would not have purchased a full daVinci hardware/software package. If the price could be, say $60K instead of $300K (or more) then that has a really good chance of reviving the brand and – in that inevitable trend – make higher quality available at lower price. That has always been Grant Petty’s goal, so it seems this is consistent.

With the release of Snow Leopard (OS X 10.6) this week, we finally get to see QuickTime X.

Simply put, QuickTime X is, as predicted, a simplified media player and simplified architecture optimized for playback of linear video streams. Most of what made QuickTime interesting to interactive authorers back a few years, is not present in QuickTime X.

We gain some new features: 2.2 gamma, screen capture and easily publish to major online video sharing sites. Screen capture is a nice addition and easy sharing probably would have been predictable if we’d seen Final Cut Pro 7 earlier.

The 2.2 gamma will no doubt take some time to get full adoption but at least it provides a way for us to add or change a color profile. Files with color profiles automatically adjust display to look correct on all screen. (At least, that’s the theory.) Within the Final Cut Studio it seems that correct gamma will be maintained *if* conversions are done with Compressor and not QuickTime 7’s Pro Player.

Chapter display has changed from a pop-up text list to thumbnail images. Better for consumer focused movies; less good for professionals.

Fortunately, it’s not an either/or. You can choose to install QuickTime 7.6 in addition to QuickTime X. If you try and access a movie that requires QT 7 features, users will be prompted to install QT 7 (aka “the real QuickTime!). If you want to make sure it’s installed, Apple have instructions on installing it.

So that’s the story of QuickTime X – a simple, consumer-focused player with a modern-looking interface, just as I predicted a little over a year ago.

Added 8/31 Just got this off a QT Apple email list. It’s not an official word from Apple but I think it sums it up well:

Quicktime X at this time isn’t a replacement to Quicktime 7, just allows faster multi-threaded playback of some of the older codecs.

Added 9/1 Ars Technica has a deep article on the difference between QT X and QT 7 and how QTkit negotiates between them,  that confirms I got my “educated guesses” right and provides more depth in how Apple achieves this.

With the apparent demise of Shake – really nothing real now, as it seems to have been withdrawn from sale – Apple appears to be redirecting enquires to the Final Cut Studio 3 pages, suggesting that they consider Motion a substitute for Shake. I hope there’s something else coming (“Phenomenal” anyone?) because Motion is not a substitute.

Now, before I get into the reasons why they’re not interchangeable, let me say that it might make perfect business sense to drop Shake and not replace it. Shake, when Apple purchased it, had about 200 customers. That number has obviously grown dramatically but I’d be surprised if there were 10,000 true users: people who use Shake as the high-end compositing tool it was designed to be. It was also obvious that Shake, as it was, wasn’t going to be able to move forward in any serious way: no way to hook into GPU power or other such lush goodness.

Creating a replacement from scratch – all new, modern code – is an expensive operation. For a company like Apple, probably in the tens of millions of dollars to not only create the application but to test it internally (the Motion team, at time of launch, had as many QA people as software engineers), put the marketing plan into practice, run launch events, seminars, create training resources, etc. At Apple’s level, software is an expensive business.

The market for high end compositing software is small, and in the time Shake hasn’t been developed competitors have been significantly upgraded and taken market share from Shake. Maybe the decision was made to simply take what they could from Shake and roll it into Motion.

But Motion is not now, nor ever will be, a replacement for Shake. Motion is a great motion graphics tool with compositing capability. Shake is a compositing tool with some motion graphics capability. You see the problem.

Motion is an excellent motion graphics tool for video editors. It is designed to make it relatively easy for non-experts to create some fabulous looking motion graphics. Shake, OTOH, was for those individuals who were trying to track a head  shot against green screen onto a body while putting the whole body into a scene generated in 3D while adding other 3D characters.

This would be a nightmare to composite in Motion, because it’s not what Motion was designed for.

So, while it makes perfect sense to kill Shake – it was old and needed updating, and maybe updating doesn’t make economic or marketing sense – it doesn’t make sense to pretend that Motion is a suitable replacement.

I suspect that the original purchase of Shake was more for the marketing benefit of being associated with Tentpole movies rather than the income from software sales. Apple doesn’t need that so much anymore (and that’s a good thing).

I’d still like to see what the Nothing Real team would do recreating the application from the ground up with modern technologies, but I suspect Shake will never be anything real in the future.

Since the launch of ProRes 422 in Final Cut Pro 6, I’ve been vocally disappointed that Apple didn’t choose to license Avid’s DNxHD family of codecs instead of developing their own competing (and almost identical) ProRes 422. Right down to the data rates used, the two codec families are very similar.

Except DNxHD is truly cross platform including *creating* files on Windows. Apple might not want to acknowledge it but the best high end compositing apps (Nuke et al.) are Windows and many of the highest end 3D apps are Windows only. That’s the world Apple’s customers live in and not having a way to create ProRes 422 on Windows is still a failing of that codec family. DNxHD codecs can carry alpha channels in all versions. Plus, if Apple had adopted DNxHD then media would be (sort of) compatible between Final Cut Pro and Media Composer. (A rewrap from MXF to QuickTime would be required, or the use of RayTools to read MXF natively into Final Cut Pro.)

But with the release of Final Cut Pro 7 and the new ProRes 4444 codec, I can see why Apple wanted to “do their own thing” as it were. They get to control the future of the codec family without involving third parties.

There’s no DNxHD 444 codec. There is now a ProRes 4444 codec and there is now alpha channel support for those who want it. (Admittedly I’d like to see alpha channel support in the 220 and 140 Mbit versions as well, but perhaps I shouldn’t be greedy.)

While it only duplicated DNxHD functionality (and really the new 45 Mbit Offline codec in ProRes duplicates the similar DNxHD 36 codec) it didn’t make sense to have competing offerings.

Giving us more than DNxHD does, makes up for the duplication.

But please, Apple, give us a way to create those files on Windows. I’m no Windows fan but this is the real world and Windows exists in media creation.

I was prepared for a “small” release this time round, as I assumed that the Pro Apps Team would be working hard to convert to Cocoa and would have to release a smaller “interim” release, but Final Cut Pro 7 is definitely more than I was expecting.

Having iChat Theater built-in means no more workaround with remote collaboration using two Macs! It also suggests the Pro Apps folk “get” that remote collaboration is booming and they know they need to adapt to that world.

Likewise the new publishing palette is going to be great for a lot of editors who need to routinely provide progress updates and deliver them on the web. That it runs in the background while you continue working is even better. You could have saved a reference movie and sent that to Compressor and added an upload action to the preset, but this is just so much simpler, and gives direct access to the most popular sharing sites, and Mobile Me!  MobileMe might be the best choice for many editors – files can be private and certainly not as public as YouTube!

My all-out favorite features, while a small one, is that Markers in a Sequence now move with the Sequence as clips are inserted or deleted. Colored Markers are great and I’ll use them a lot to identify a type of marker. For example, one color could mean “more work needed here” another color would be a locator just you jump quickly to part of the Sequence, and so on.

The technologist in me is very impressed with the new ProRes codecs. Those that work at the high end will love the ProRes 4444 codecs (and those that want an alpha channel will use it anyway). The Proxy version at 36 Mbit/sec parallels Avid’s own DNxHD offline codec and Apple needed something similar for HD offline. The most interesting codec is, however, the 100 Mbit LT version.

Clearly aimed at acquisition I expect we’ll see camcorders and other devices, like maybe the Ki Pro, supporting this data rate, which is co-incidentally the same as AVC-I at its highest setting. AVC-I up against ProRes 422 LT would be very, very similar in quality, both 4:2:2 and 10 bit and using similar compression strategies. It would be a perfect data rate for the Ki Pro if AJA want to support it. (I can’t help but wonder if the last-minute-delay of the Ki Pro wasn’t to wait for this announcement, but I’m just guessing.)

The Pro Apps team have thrown a “sop” at those who want Blu-ray authoring with the ability to create a Blu-ray compatible H.264/AVC file in Compressor that can be burnt to Blu-ray or standard DVD media. Nothing that Toast 10 hasn’t been able to do for some time now but nice to have it included in the lower-cost Final Cut Studio.

Many have interpreted the inclusion of this feature as an indication that Apple are going to get “more serious” about Blu-ray, but I’m not sure. I think it indicates the opposite. If there was going to be a big Blu-ray push the these features would be added to DVD SP, which received almost no update in this version. I think we’ve got Apple’s “solution” for Blu-ray in Final Cut Studio. Who know, only the future (and probably a Product Manger at Apple) will tell. (The PM won’t ever tell, that’s for sure!)

As to the loss of LiveType. It was probably inevitable as it was increasingly obvious that Motion was taking on many of the roles previously done by LiveType. By adding in the LiveType glyph animation features to Motion (adopted directly from LiveType) most of the functionality is now in Motion. My only concern is whether Motion now recolors LiveFonts correctly (i.e. the way LiveType did). I’ll test as soon as I have a copy in hand.

Finally, the price. Who can complain about Final Cut Studio being the same prices now as Final Cut Pro was alone for the first couple of generations.

Certainly, on the surface, it’s a good release.

On the timing – I notice that all Pro Apps products – Studio, Server and Logic (Pro Music) all came out together for the first time. Does it mean anything? It’s Apple, who knows and I’d rather not drive myself crazy trying to second guess them!

We’ve been working with a few people previewing, and getting feedback on, a new addition to our First Cuts assisted editing tool – basically checking some areas of Final Cut Pro that I haven’t explored for years and I had the most interesting conversation with Jerry Hofman.

Before I get to that though, let me ask (beg) for feedback on any of our software products. We want to keep making them better and love feedback, feature requests and especially problems. We respond quickly – this particular feature request was received on Friday 26th, discussed briefly during a Hollywood Bowl concert on Saturday night and was a preliminary feature by Wednesday!

Anyhow, in discussing this particular tool with Jerry (you’ll find out what it is soon enough!) I asked how much metadata from RED is imported to Final Cut Pro via Log and Transfer. Jerry, who uses RED a whole lot more than me (i.e. he uses it!) said “not very much”, which pretty much matched my understanding working with a whole bunch of RED clips with Sync-N-Link and never seen any of the color temperature, date or other information that’s in the RED metadata.

In sharing this conversation with my smart partner, and our main code writer, Greg Clarke, he commented “Oh, I do think Mr Hofman is mistaken!” (or words to that effect). Turns out Greg has been scrolling past this metadata for most of the last year. The difference is that Greg works with FCP XML exports, while Jerry and I were looking through the Final Cut Pro interface.

OMG! What a treasure-trove of metadata there is. And why didn’t we know of this? Surely someone from all the conversations we’ve had with people developing Sync-N-Link must know about this? (You’ll all come out of the woodwork into the comments and let me know you’ve known about it for years!)

So this morning Greg’s built me a tool for exploring this hidden (I prefer “secret” because it makes it seem more mysterious) metadata, turning it into an excel spreadsheet. I already had XDCAM EX media and P2 media along with RED clips and I was able to download some AVCCAM media shot with Panasonic’s HMC-150 camera.

There’s an enormous amount of Source metadata there. A lot of fields that seems to be unused even in the camera. Clearly, the current version of Final Cut Pro doesn’t have the flexibility to display items like ‘whiteBalanceTint’ or ‘digitalGainBlue’ settings in the original file. I guess this type of metadata is going to be challenging for Apple and Avid to deal with, as they don’t (currently) have displays in their application for the enormous amount of metadata that are generated with tapeless cameras. I’m just very thankful that it’s being retained, and that it’s available via XML (and associated with a Final Cut Pro clip ID).

There’s definitely metadata already  being produced that we can use to improve First Cuts – at least for non-tape media sources. But it’s also interesting to explore fields that are available but not being used.

Show all columns and you'll be surprised at what's available, or going to become available.

BTW, you can explore yourself using Log and Transfer. Open any type of media that Log and Transfer supports and then, right click on the column header (like you would in Final Cut Pro) and select “Show all Columns”. The columns displayed will change according to the type of media selected.

So far, Sony’s XDCAM EX has the least amount of metadata and the least interesting metadata – barely more than the basic video requirements and information on the device: model and serial number.  RED footage has a lot of metadata, although most is focused on the technical aspects of the shot as you would expect for a digital cinema camera.

But take a peak at the source metadata from P2 Media! All the goodness like the date of the shoot (which FCP otherwise does not export) and time (as does RED) but also fields for ‘Reporter Name’ (awesome for a First Cuts – News product) and Latitude and Longitude. While they’ve been blank in every instance because I don’t think Panasonic are shipping any cameras with GPS built in yet, it does suggest that future Panasonic cameras are likely to contain GPS and store that data in with the media file. Anyone who’s a regular reader will know that means Derived Metadata! There are also fields for ‘Location Source’, ‘Location Name’, ‘Program Name’, ‘Reporter’, ‘Purpose’and ‘Object’ (??).

AVCCAM carries all the fields of P2, more or less, with the addition of a “memo” and “memo creator” fields.

It’s been fun exploring this ’secret’ metadata. Now to find a way to make some use of it, or make it practical. Would anyone be interested in a tool that would not only read and explore this metadata, but allow some of it to be mapped to existing Final Cut Pro fields?