John Heagy
Forum Replies Created
-
[Craig Seeman] “Quicktime is legacy. AVFoundation is the way forward.”
I thought I was pretty clear in saying I want QT ref via AVFoundation. Understand that AVFoundation is the future of QT. AVF replaces the QT API not the QT.mov file format. AVF only makes .mov currently, so the way forward is AFV and QT.mov. On top of all that the only difference between a self contained .mov and a reference .mov is the path to the media. Like with QT Reel, Apple could do this while falling off a log.
[Craig Seeman] “If there’s going to be linking to clips it would probably be through XML.”
That would be great except render files are not listed in XML, therefore no linking to rendered media for effects. XML only links to original source files… reference mov links to finished/rendered media.
The closest FCPX has to a ref.mov is the actual FCPX project file. Unfortunately they are all named exactly the same (CurrentVersion.fcpproject) whose bright idea was that!
John
-
[John Heagy] “”However if one chooses to embed data in QT tcsource aka:Reel then READ IT!””
[Jeremy Garchow] “Oliver points out that it does happen, just not as expected.”
If your referring to the Arri Reel Name, that is a custom QT Key via a com.arri.camera.ReelName entry and not tcsource aka:Reel.
Apple has decided to exclude tcsource!
This is all exposed in CatDV which is excellent at reading every QT metadata entry amoung many others.
APPLE!!
IF IT”S THERE… READ IT!!!
John -
[Jeremy Garchow] “Sorry guys, handing this process off to camera manufacturers/3rd party developers to support it, is smart and logical.
With an importer, metadata will get passed through in FCPXML.
I know, it won’t write to the files, but that’s a daunting task. Best to keep the metadata separate (like Panasonic already does) to allow all applications to read and access the data fairly easily. “
I have no problem with addition metadata be read and populated via other methods beside Reel. However if one chooses to embed data in QT tcsource aka:Reel then READ IT!
-
[Chris Kenny] “usually they don’t conflict, and they often end up being a very import piece of metadata in a world where file names can be changed to easily, and where offline/online workflows are still quite common.
“Here’s how we use Reel ID in a offline/online workflow. Let’s take a 3hr football game that’s assigned Reel and of course TC. Initially, due to quick turnaround shows, the entire game is made available to online (HD) and offline (proxy) systems. Once these shows are delivered the online media gets paired down to only the highlight plays, but the offline systems keep the entire game. With a workflow like this, filename/path doesn’t work, a more agile system is required. One that identifies the content in the files, not just the files themselves.
Reel also benefits LTO archive and restore. Take the same 3hr game. Imagine having to restore the entire 3hr file just to link up a few shots. In our case the “chopped up” game is now in many shorter segments (highlights and outs) so just the segments that contain the shots need be restored.
If one happens to have an LTO system that supports partial file restore, something I’m not in favor of, then the system “slices out” just the content required and assigns it a new filename. Again reel and TC would be how these files are linked.
In both cases the reel metadata should be embedded in the media and need to survive this “chopping/slicing” process, thankfully QT Reel/Tape does.
Now with typical digital acquisition with many camera start/stops one doesn’t have long media files. The exception being lengthy interviews and live events. Ether way data granularity is an issue with archive and restore and Reel/TC can help.
John
-
[Chris Kenny] “Now, one could make an argument that in file-based workflows this shouldn’t be necessary — file name + timecode is sufficient to uniquely identify any frame in the project. However, this makes me very nervous.”
I’m not a fan of filename/path linking either. Why would I rely on the two easiest to change attributes of a file. We routinley change both the name and path of files and rely on Reel and TC to link.
John
-
[Ian Bailey] “We noticed that when AVCHD was imported into FCPX 10.0.5 the bitrate was 120 Mbit/s. This is lower than standard ProRes422 (147 Mbit/s, HD at 60i), but higher than ProRes422 LT (100 Mbit/s, HD at 60i).”
ProRes is a variable bitrate codec. If there is any redundancy within the frame it will drop the data rate. Of course any black breaks in the footage will drop the data rate to almost nothing.
John
-
[Jeremy Garchow] “But isn’t there persistent metadata in all of these files?
One man’s tcsource is another mans ClipID.
“In the case of QT it’s UUID and for P2 it’s ClipID neither survive the encode process.
[Jeremy Garchow] “Once you start working with Red native files, or other RAW files, or image sequences, or anything that’s not a nicely package Qt movie, does that mean that FCPX has to translate and write in to every single file format possible?”
I package up everything in QT first. Too many NLEs try to be the center of the universe when it comes to media. We prepare, or as we say make the files “full citizens” of our process. This means being assigned unique Reel and TC.
Every frame of media whether film, tape, or digital media from 1958 ’till today can be found with two numbers… beat that!
I’m not asking for anything new here. This is bread and butter QT metadata that is currently supported in AVFoundation.
If Apple has other plans for “Reel” then just read and populate it as tcsource. There’s no excuse for excluding it.
John
-
Our Reel system applies to all media, camera original, masters, and elements. It is a simple 6digit number that simply increments.
It obviously started as tape IDs where each camera tape and every master have it’s own Reel ID. In the case of digital camera media we currently assign Reel ID on a card/container basis but ultimately it will span multiple cards to represent a camera/day. Because we require unique reel IDs we can’t use the camera generated Reel in Alexa or Red as they are not unique and quickly repeat.
I use Reel as more of a GUID or content ID then anything to do with a container/tape. I need a way to ID content so when a select gets sliced out of a larger file, or a partial file restore comes in from LTO, the Reel ID persists so I can link to it without worrying about the original filename/path, or any other linking criteria matching. I can’t rely on UUIDs as they are reset whenever a new file is made regardless of content.
Reel ID is also a way of communicating accurately. Remembering the exact name of a master or group of camera files is less accurate, or as easy to remember, as a 6 digit number.
As far as a standard I think it should continue to be whatever the user needs it to be. So a simple text string is fine for me.
John
-
[Oliver Peters] “Unfortunately I think that ship has sailed. It’s not the direction Apple has decided to go.”
Can you explain what you believe Apple has in mind for “Reel”. It’s being populated by Red’s importer but every other file is not allowed to populate it?
The Quicktime API replacement AVFoundation does support tcsource entry. Why would Apple carry it forward and not read it?
Worst case, as silly as it sounds, one could build a QT importer that does read tcsource and populate Reel.
Apple does seem willing to change course, like source monitor, so hopefully conversations like these can help persuade them.
Again, if Reel is so important it can’t be touched just map tcsource to tcsource. What’s one more metadata reel in the sea of fields FCPX already supports. There are 3 Altitude fields for Pete’s sake!
John
-
[Jeremy Garchow] “John Heagy talked about the reel system that he uses. It is extensive and extends to many types of media including tape. FCPX allows user assignable reels, which are crucial to his organization system and archive. There are some things, especially when talking about tapeless assets, that shouldn’t be changed.”
The value of tcsource for us is that it’s embedded in the file, it’s actually the name of the timecode track, and can survive encodes, at least with Telestream software. The fact that tcsource is user definable in QT is where the value is for us. Having it user definable in FCPX, while not updating the file, is pointless to us. User definable data is only useful for that project/event. We need it to persist across projects/events as part of the media.
If Apple is reading all the custom QT keys from cameras, what is it reserving Reel for if not tcsource? If Apple has other plans for Reel so be it. Just give me the data from tcsource in a tcsource metadata field. I don’t think that’s asking too much. What excuse could they possibly have for excluding it?
John