Unique Frame Identifier

[Dylan Reeve]

A unique clip identifier is a good idea. But giving every frame the same UUID + Frame number is a big mistake and missing the point. UUID's are an essentially limitless addressing space. If you want to know what clip a frame is a member of, include the parent clip UUID in the metadata of each frame. Create a new UUID for any derived frame and point to the parent frame by it's UUID, in fact hold the entire history of derived frames in a tree of UUID's. This all amounts to just kilobytes per frame.

Indeed the relationships can be stored in that way, but it does become a lot harder to manage (although it is possible to describe more complex relationships).

Describing and entire sequence as a series of completely unique frame IDs certainly lacks the efficiency of a system where elements can be described with a start and end.

A root UUID with further descriptors can still provide the benefits in terms of global uniqueness.

On further thought the idea of a revision number is somewhat untenable, as it lacks centralised control meaning duplicates are very possible (revision one gets into two different processes, both output what they think is revision two).

So now I'd be more inclined to have something like:
[Clip UUID]-[Frame Count]-[Revision ID]
Where revision is a further unique ID, allowing for all revisions to co-exist with a common lineage.

The biggest problem here arises when a new frame is the result of more than one source frame, one has to be chosen as the ID which continues. Although obviously the relation to additional source frames can be described in further metadata.

There is no reason, of course, that both these concepts could co-exist (after all there's no shortage of UUIDs).

 

[Scott Simmons]

I'm late to this discussion but isn't this kind of what Quantel is doing with the Genetic Engineering idea? If I understand it correctly, instead of capturing media as a clip each frame is essentially stored as an individual file so it can always be accessed this way by apps that support it. That way each frame is indeed individual and has individual identifiers. That's gotta be a lot of directory management at the OS level but they seem to swear by it!

 

[I Bloom]

Indeed the relationships can be stored in that way, but it does become a lot harder to manage (although it is possible to describe more complex relationships).

Describing and entire sequence as a series of completely unique frame IDs certainly lacks the efficiency of a system where elements can be described with a start and end.

A root UUID with further descriptors can still provide the benefits in terms of global uniqueness.

On further thought the idea of a revision number is somewhat untenable, as it lacks centralised control meaning duplicates are very possible (revision one gets into two different processes, both output what they think is revision two).

So now I'd be more inclined to have something like:
[Clip UUID]-[Frame Count]-[Revision ID]
Where revision is a further unique ID, allowing for all revisions to co-exist with a common lineage.

The biggest problem here arises when a new frame is the result of more than one source frame, one has to be chosen as the ID which continues. Although obviously the relation to additional source frames can be described in further metadata.

There is no reason, of course, that both these concepts could co-exist (after all there's no shortage of UUIDs).

The whole purpose of having a UUID on every frame, is to prevent slippage between applications. If you are working on a clip by clip basis rather than a frame by frame basis than you risk applications shifting frames. This happens often with visual effects and composite shots. The main problem with most workflows. Every clip must have its own identifier, not just a frame count.

Efficiency is not a concern. Robustness is. You are talking about things that scale linearly, and just megabytes of additional data.

So in the model I'm proposing, each frame header will include:
1. Frame UUID
2. Parent Clip UUID
3. Frames History: Tree of Frame IDs from which the current frame is derived.
4. Frame count
5. Edgecode
6. Timecode
7. Other metadata

Part 3 is the most important. It's just a dependency graph. How exactly the compositing is being done can be handled by another standard or in another file.

IBloom

 

[vittiphoto]

Hey, my first post (goo goo!) Hey Mark, hey Ian (Bloom Agree, he's one of the smartest people alive).

Unique frame ID's might also benefit from locator bit(s) storing where the files (on what volumes/devices) exist? Been thinking about this for still photo (natch, grows into video post), after you close the image file, sequence files or project file and you put the media away, how easy would it be to relocate it with locator bits (or possibly locator bits in the header?)