Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Unique Frame Identifier

M

Mark L. Pederson

REDuser Sponsor
Joined
Dec 28, 2006
Messages
7,145
Reaction score
1
Points
0
Age
59
Website
www.offhollywoodny.com
Ian Bloom (we just call him Boba Fett) was over at Offhollywood yesterday and we got into one of our crazy "future of post" conversations.

When the conversation hit the subject of Unique Frame Identifiers we started finishing each other's sentences.

Imagine a world where a camera (gee ... let's just say the RED ONE, Scarlet and Epic) always writes a unique frame identifier.

Now imagine that other applications, like NUKE, After Effects, etc. would always PASS that meta data on in renders of comps, exports and outputs.

Now imagine an NLE that supports this.

I said it before and I'll say it again - Ian Bloom is one of the SMARTEST guys I have met in my entire life. And I know a few folks.

I got a sneak peak into the new Crimson roadmap - it's just insane what he is doing. You guys are all going to flip out!

Apple or Adobe better get their checkbooks ready ...
 
There is a virtual "keykode" proposal already floating around which is about uniquely identifying every frame from cameras, to CGI, to VFX... etc.

Bit I agree about Ian...

Michael
 
Nathan Buxton said:
For those of us with little-to-no high-end post production experience, could you summarize the benefits of this?
Click to expand...

The implications are pretty huge.

On the most BASIC level, if an NLE or DI applicaion just sees a table of unique frame ID's, any and all media can just "fall into" the right place. Who cares about naming conventions, timecode and reel #.

Think of it this way - EVERY SINGLE FRAME from the camera has a unique ID. Through the entire post pipeline - EVERY element made from those frames, carries over that data - so - EVERYTHING made from each and every frame - relates directly back to the original frames from the camera.

If you think about this for a while - then think about how the industry does it now ... you will see the light.
 
ooohh.. as in EVERY frame is 100% unique? I thought you meant just for that clip....

that would be kinda cool.... actually that could be very cool. you could "use" footage that you have never even seen just by being given the numbers... then once you get the footage it'll be ready to go?!

do i get it or dont i?
 
This seems like a good idea. BUT... for it to work, you need enough systems supporting it.

It shouldn't be bad as this doesn't seem particularly difficult to implement.

2- If you look at other useful metadata, it is not always used to its full potential.

For example there's VITC timecode, which is frame-accurate and sent over SDI. In my experience, Final Cut doesn't seem to be aware of this and its captures are not frame accurate. I'm sitting there with FCP and a DVCPRO HD deck and re-capturing the same clip and the frames will sometimes come in different/not in sync.

So while VITC has the potential for frame-accurate captures... this does not happen because that "metadata" wasn't implemented right.

2b- It's also possible for tape formats to support scene detection and pulldown flagging like capturing DV over firewire does. We could be sending such metadata in the vertical interval over SDI. But unfortunately I've not really seen this supported.

Scene detection would be *so* useful as it would save a lot of time logging... but unfortunately, the manufacturers never really got into that.

3- I guess what I am saying is... please for the love of _____, the industry needs standards on stuff like this.
 
Woh, where'd all the love come from.

Different camera companies will likely do different things for Unique Frame Identifiers, some will choose checksums and others will generate Uuids, the smart ones will generate both. That's why the standard for NLE's should be any alphanumeric string passed for any frame. Unfortunately if each company doesn't do both, the likelyhood of collisions increases.

I have a lot of ideas about this but the main one is that there should be an underlying standard for a basic cut, which is just a list of overlapping frames in sequence. Transitions, effects, and generators will likely be more complicated to transcribe and every company will have their own sauce but a good standard will let you ignore most of that stuff, if all you want is the frames.

The most important thing is that a sequence generated by an NLE is a series of new UFID's that are linking to other UFID's. Not a timecode template for existing UFID's. You can number them if you want but each frame in a cut should be the root of a tree of UFID's which can connect to another cut or a camera generated frame.

The hard part is of course sound. Sound samples recorded by cameras could be divided into frame intervals and assigned UFID's. But if you want to shift sound samples by any time increment smaller than a frame, shit starts to fly.

Fun times in software land. Let us please put EDL's in a museum next to the "Edit Droid"

IBloom
 
Unfortunately if each company doesn't do both, the likelyhood of collisions increases.
Click to expand...
Well right now we already have collisions. I've seen professionally shot and labeled tapes where two tapes have the same reel name. But that is something that can be solved. I believe that was fixed by changing the reel name and re-labelling the tape appropriately.

You also get collisions where you have timecode breaks. (Good times...)

Let us please put EDL's in a museum next to the "Edit Droid"
Click to expand...
IMO, there's a reason why we still use technology that was around before I was born. It's because EDLs are simple to implement (relative to say AAF or XML), it mostly works, and therefore manufacturers would actually implement it.

Thinking aloud here, it might be good if EDLs supported some extra metadata in comment fields.

- Unique frame identifier on top of timecode. It's another hint about which frame is the right one.
If UFIDs were passed over the vertical interval (over SDI) during capture, it could also help ensure frame-accurate conforms.
If you want UFIDs to work in a tape environment, I think you need a UFID for each field since sometimes you have to add 3:2 pulldown. And UFIDs should support some way of doing cadence detection.
For this stuff to happen, it would be necessary to standardize which line of VITC you'd put this stuff on.
Having UFIDs in a tape environment would also let people do scene detection (and you don't have to set the date/time on your camera like you have to with DV).

- Comment field for location of the file. This would be an optional hint to help the online system find the source files. e.g. to get stuff into Final Touch/Color via EDL, all the files had to be in the same folder.
*Possible issues here with weird characters like slashes in the file name.

- Perhaps for every instance of a clip on the timeline, it would get its own ID. If the offline edit changed, this would make it easier to keep track of edit changes if you have to re-conform. e.g. an editor logs a master shot and uses it three times. That's three instances with unique IDs. If they make changes to the rough cut, the finishing system could look at how the TCs on the unique IDs change and be able to handle the changed edit easier (e.g. copy effects over and adjust keyframes automatically). This might be a really bad idea if it leads to less discipline about locking edits down.

- 8 or less characters for reel name is a weird limitation. But I suppose I don't necessarily advocate lifting that restriction because it would break backwards compatibility. This is something we can live with, as silly as it is.
 
Mark and Ian are correct and I've had the same conversation with ian.

think about never having to worry about all the human error that goes into Logging/Digitizing and whatnot from a data structure.

of course nothing beats a great physical system but if you were backed up and kept from totally screwing yourself or some else screwing you this would be it!

Mark said it perfectly
 
ibloom said:
The most important thing is that a sequence generated by an NLE is a series of new UFID's that are linking to other UFID's. Not a timecode template for existing UFID's. You can number them if you want but each frame in a cut should be the root of a tree of UFID's which can connect to another cut or a camera generated frame. And if Mark Pederson can tell me what this means his next tequila shipment is on me.
Click to expand...

Basically you're talking about UFID's as Reference markers to each other. based on either the "new cut" ref or the orig footage ref but they're basically metadata pointers created at many stages of content creation directing the various software's to do your bidding.

am i correct in this assumption?

also yes audio is indeed a problem since it doesn't exist in a frame based world but a sample based one. but im sure some smart guy can figure it out...

like locking an audio clip to a frame REF with a separate additional "tag" ID'ing it as audio so it can slip and slide around but contain the orig "picture" metadata pre-tag to keep it in sync if need be.
 
of course nothing beats a great physical system but if you were backed up and kept from totally screwing yourself or some else screwing you this would be it!
Click to expand...
I don't think it's possible to build a system that is completely 100% idiot proof.

This system will screw up if the metadata gets stripped/lost somewhere. I don't think that will be hard to do.

all the human error that goes into Logging/Digitizing
Click to expand...
I think the error rate there is pretty low and not a huge problem.

TC breaks is an issue.

Systems not capturing frame-accurately is probably a bigger issue as it sucks up more time (for workflows where you re-capture via SDI).

But current SDI-based workflows for the most part work. Which is important, because many other systems do not (or are very time consuming).
 
i agree with you and i meant more from a project perspective of someone potentially delivering a project for finishing or pre-loaded for a job that you yourself didnt have the control over from setup.

TC breaks kill me esp during a multicam shoot when one idiot camera operator is constantly stopping and starting when the others are rolling.

As an AVID user I rarely have any issues with my system not being frame accurate and i'm only saying that as that is my system of choice and have had success from a workflow perspective with it. I have no specific FCP knowledge so its not a slight on FCP or its users.

the UFID concept would be potentially to make it very hard to "strip" or lose the metadata for such purposes and others, although theres always some jackass out there who inadvertently figures out how to do it, screwing himself and the unfortunate people he finds to work on his project.
 
GlennChan said:
Well right now we already have collisions. I've seen professionally shot and labeled tapes where two tapes have the same reel name. But that is something that can be solved. I believe that was fixed by changing the reel name and re-labelling the tape appropriately.

You also get collisions where you have timecode breaks. (Good times...)


IMO, there's a reason why we still use technology that was around before I was born. It's because EDLs are simple to implement (relative to say AAF or XML), it mostly works, and therefore manufacturers would actually implement it.

Thinking aloud here, it might be good if EDLs supported some extra metadata in comment fields.

- Unique frame identifier on top of timecode. It's another hint about which frame is the right one.
If UFIDs were passed over the vertical interval (over SDI) during capture, it could also help ensure frame-accurate conforms.
If you want UFIDs to work in a tape environment, I think you need a UFID for each field since sometimes you have to add 3:2 pulldown. And UFIDs should support some way of doing cadence detection.
For this stuff to happen, it would be necessary to standardize which line of VITC you'd put this stuff on.
Having UFIDs in a tape environment would also let people do scene detection (and you don't have to set the date/time on your camera like you have to with DV).

- Comment field for location of the file. This would be an optional hint to help the online system find the source files. e.g. to get stuff into Final Touch/Color via EDL, all the files had to be in the same folder.
*Possible issues here with weird characters like slashes in the file name.

- Perhaps for every instance of a clip on the timeline, it would get its own ID. If the offline edit changed, this would make it easier to keep track of edit changes if you have to re-conform. e.g. an editor logs a master shot and uses it three times. That's three instances with unique IDs. If they make changes to the rough cut, the finishing system could look at how the TCs on the unique IDs change and be able to handle the changed edit easier (e.g. copy effects over and adjust keyframes automatically). This might be a really bad idea if it leads to less discipline about locking edits down.

- 8 or less characters for reel name is a weird limitation. But I suppose I don't necessarily advocate lifting that restriction because it would break backwards compatibility. This is something we can live with, as silly as it is.
Click to expand...

"Tape", "DV" what mean these strange words?!?

I once worked as a consultant for a company that had spent 100 thousand dollars on a tape based workflow that they could have replaced with a twenty dollar firewire cable and gotten a better image quality.

The world of tape based workflows is not mine. I take issue with many of the points you have made. But I won't argue with them for this simple reason: I live in a world where tapes are only used for long term storage of data. If you don't live in that world, then you will disagree with my point of view. I'm not going to tell you that your world is wrong or dead. I know there is a lot of work in that world and their will be for a long time.

The tape based world might as well not use UFID's, or it might use them as a helper for the existing structure built on EDL's. That sounds like a good idea. But insisting on backward compatibility of a new system is a terrible idea.

A new standard for transferring projects between applications should be pure, simple, and it simply does not need timecode once the original syncing relationship between audio and sound has been established. (Keep timecode in the comments if you feel the need) As far as I'm concerned media that is recorded to tapes can be striped with UFID's as it is imported into the file based world, and live on in the file based world forever.

I hope you understand me clearly. In a random access world we need a random access way of working. In the UFID world their are no timecode breaks and no reel # collisions. A frame has one identifier and possibly the identifier of the frame before it and the frame after it. This is a different way of thinking. A better way IMHO. But don't worry, the old way is here to stay. I'm hard at work on an f-ing EDL system right now. Let a man dream for christ sake.

IBloom
 
ibloom said:
Different camera companies will likely do different things for Unique Frame Identifiers, some will choose checksums and others will generate Uuids, the smart ones will generate both.
Click to expand...

There are quite a few very strong online communities of video makers. It is up to us to convince the manufacturers to develop and agree on open standards that benefit everyone. This is the first time end-users have had this kind of power. Let's use it.
 
Don't confuse legacy tape formats and metadata with can be achieved in a file-based world. Timecode can only be unique when an additional piece of metadata is part of it such as shoot date. Add to that multiple cameras and that is even more metadata. Even unique frame ID's still need the "context" metadata for it to best fit into a workflow.

I cannot give more details as to the format since I am under NDA. But it does promise to deal with much of this, but still needs to part of a greater context.

Source metadata is one, then you get into compositional metadata which adds far more complexity right away in coming to an agreement as to how these should be presented. That's why after all these years, an EDL for better or for worse is still the fallback position when all else fails.

Michael
 
MichaelP said:
Source metadata is one, then you get into compositional metadata which adds far more complexity right away in coming to an agreement as to how these should be presented. That's why after all these years, an EDL for better or for worse is still the fallback position when all else fails.
Click to expand...

Certainly between you and ian there are some great people thinking about this and im sure something positive will come of it regardless of totally changing the game as much as it could be changed.
 
Not withstanding the merits of an industry wide standard, each frame CAN be uniquely identified already IF you take the following -

Camera PIN - unique to each RED-ONE camera

Clip Name - i.e Camera letter plus Reel/Roll Number plus Clip Number and Date

(yes I know that there is an argument that there COULD be identical clip names, but lets assume that issue is resolvable / resolved)

Timecode(s) - T.O.D at least usually does not repeat, if it does then combining with the run record timecode value resolves that

So a unique I.D for a video frame recorded at 13.01.15.22, 15 seconds and 12 frames as clip 03, on reel 12, camera A, April 28th is -

ABC_XYZ_123_A012_C003_042808_13_01_15_22_01_00_15_12
 
You must log in or register to reply here.
Back
Top