Re: @A Cautionary Tale for the FCP Switcher

[Alex Udell] "Thus....

the battle between working native and transcoding.

One of the lesser discussed issues of working native is that lots of those "optimized for acquisition codecs" is that they don't play well when it comes to the media consolidation phase. The GOP based media formats don't play well with media truncation.

So rather than being an offline online world, what I'd like to work on is a parallel workflow.

Start cutting natively while at the same time generating consolidation and SAN/workgroup/full fidelity media sets. Then simply reconnect when the alternates are ready."

Yes.

I am not going to try and start a war here. I think we need to remain objective in all of this so we as users can ask for what we need and want, but I am going to mention FCPX here. Please don't shoot me everyone.

FCPX, in my opinion, got this portion extremely right. It is the best of all worlds for this style of media management. You can start editing natively, tagging clips, even rendering window burns of you need them, start editing, organizing, basically, start getting to work. In the background, FCPX can make either proxy media (which is good for multicam situations) or higher quality media, or sometimes it will just rewrap to h264 if that's what you desire. With a click of a preference, you can choose to work with the Proxy media, or the Original/High Quality media. It's not perfect, there could be some more functionality, but as a start, it is really very useful, and also a very modern way to approach this situation.

So you start native, and can choose to remain that way, or at any point in the game, you can choose to transcode, and there's no relinking, no footage hunting, it just simply works in the background, and you can work while it's transcoding. Any work that you do on the footage will translate to the proxy/DI footage as well.

[Alex Udell] "Prelude and AME should help with this....but with camera acquisition media names being arcane and based many times on atomized folder structures, rather than muxed files, relinking will still probably quite challenging.
"

It is certainly a blessing and a curse. The good thing is that MOST professional camera formats (like P2, XDCam, any MXF variant, really) have gobs and scores of metadata already in the clips. This means that almost ever clip ALREADY has a unique ID built in to it. This means that tracking this footage should be "easy" or at least, the information is already in the clips, NLEs just need to take advantage of it.

The also have methods of creating less arcane name that are stored with the clips. Sure, these names aren't exactly viewable on the Finder/Explorer level, but a spotlight search does bring up the native MXF name. So, professional tapeless formats have all the information that we need to access built in (especially P2), we just need greater access to it and we need our NLEs to do a better job of accessing and storing this information with the footage. The methods are already in place and have been for years. It's time to start using it.

I speak from experience as I have a relatively expensive QT Component for FCP7 that allows native use of MXF media in FCP without rewrap/transcode. The relinking aspect and media tacking aspect of this is so easy as the component really helps to define what that media is. For instance, in P2 material, this is what the reel number looks like:



themodernreel.png

So that number makes it very easy to discern what file is what. Sure it's long, and hard for a human to read, but a computer can track it really easily, and copy/paste is a computer interface mainstay for us humans :). Even with P2, there are sometimes dupe file names, but the Unique ID is always different, even if the file name is the same. It is ideas like this, that I think will help more the more advanced needs of broadcast workflows and certainly will help everyone in media tracking.

I agree, the amount of file formats is sort of a mess, and it will certainly take a lot of hard work to get a system that is bullet proof. It also seems that nothing is slowing down. There are new formats, new codecs, new wrappers. At least for a while, I don't think this will change.

This also means that less professional formats that don't have tc/Unique IDs (I'm looking at very inexpensive cameras that many people use, like DSLRs/GoPros) would need to get ASSIGNED this missing data. And that's where it gets interesting. In my view, I think it would be best to simply rewrap this information in an already proven container like P2 XMF, or XDcam, or whatever is best. These formats are understood by almost every NLE not the planet. So why not give the NLE what it understands?

I know this brings a level of complexity, but in my opinion, these are complex ideas. I hope all this makes some sense.

[Alex Udell] "If anyone does start working the parallel route or wants to discuss it more...drop me a line. This would be very valuable to explore."

Surely.

Jeremy