RED frame IDs

B

boothba

Well-known member
I was going to reply to Stuart's REDCINE post, but I didn't want to muddle his thread.

It is my wish that RED employs a rigorous and extensive frame identification system so that each each RED frame has a unique DNA to allow for its identification throughout the production, post and archival process. This is different from timecode or naming conventions which are often tailored to user preferences. id-DNA should be unchangeable (granted at birth), meaningful & unique to each and every RED frame, to allow for seamless conversions, conforms, archives, as well as the reusing of 'library' footage recycled for different projects.

Some may wonder why I am making such a mundane request. Well mostly because this has been screwed up so often in the past. Consider these examples:

Example A: Timecode. Inadequate. Most films and episodic shows use a 24 hr timecode system, which means at after 23:59:59:29 you start again. Very frustrating when dealing with 25 (or 250) hours of footage. Timecode is also specific to playback rates (23.98, 59.94, 60p, pal) of which there are always emerging formats. Will the future bring us a 120 fps playback standard? SMPTE better hope not!

Example B - Autosoft / Discreet Logic frame ID system. Perhaps the most frustrating thing I've ever seen. Simply put Discreet did not allocate enough meta-data characters to identify each frame. As a result the box becomes "full" long before the drive is at capacity. The company I work for runs Smoke, Flame and Inferno on 2 & 4 terabyte stones - but we can only ever use about half that storage because the system runs out of frame IDs first. AGGGHHH - a nightmare! Thank god they've fixed this in the new version.

Example C - Y2K. All your computers die at midnight because the systems were not designed to go past 1999. Okay, maybe that's BS - I just wanted to be controversial. :)

My point is that flawed systems have be designed by some very smart people, and RED may only have one chance to get this right. Perhaps the best system is keycode, but even that can be improved upon - and with small preparations RED could design a far superior new standard. Ideally this system would:

- be exhaustive - have enough characters to identify every frame in a Red camera's shooting life.
- be meaningful to a viewer (not just a jumble of random characters)
- act as an odometer, or running counter of frames recorded (useful for rental companies, or resale)
- be easily converted to timecode, specific to ANY & ALL playback rates. A popup timecode calculator.

Here's a simple example:

first frame shot = r0478a_aaaaaaa_0000000ab
last frame shot = r0478a_zzzzzzz_9999999ab

where:

​
- "r0478a" = red serial number. 'a' = the port from which the frames were exported (RED-drive, RED-flash, RED-RAID, SATA, HD-SDI etc.)

​
- "aaaaaaa" = MAJOR FRAME COUNTER. When the minor frame counter reaches capacity (9999999), advance by one character (aaaaaab...aaaaaac....aaabrtz....zzzzzzz). Perhaps the users could advance this when starting a new production (in which case add more characters).

​
- "0000000" = MINOR FRAME COUNTER. 6 or 7 digits is about right because it is still somewhat meaningful at a glance. (9999999 frames = 115.74 hours of footage @ 24p playback, or 46.29 hours of footage @ 60p playback). This is the number to which a timecode calculator can be applied.

​
- "ab" = field A & field B. Sorry, but fields are still important even when shooting progressive. A great deal of television programming is shot 24p, and then cine-expanded with 3-2 cadence applied. Progressive frames can be identified as nothing or as 'ab' above.

The above example would allow for trillions of frame IDs and millions of hours of footage, specific to each red camera (necessary for multi-camera shoots).

A second tier id system could be applied in REDCINE or other software to characterize some of the standard processes applied in post (such as down-rez, resize, flip, flop, color grade, etc)

Such a system may seem excessive but it is worth it, big time. And it is so fundamental to RED workflow that it should be thought out and perfected at the beginning. Who knows - if RED can invent a better digital standard perhaps they can sell it to SMPTE. Or at least be the envy of all other formats.

Sorry about the loooooonnnngggg.... booooorrrrinnngggg post.
 
Getting the "mundane" bits right will help ease the workflow concerns that so many people from the 35mm film camp always bring up to trash digital solutions. Now if we could just get some benchmarks for deliverables on hard drives and optical discs...

Blair S. Paulsen
RedOne #19
 
What kind? Practically everything that exists as data in the camera - so lots, and what form, probably XML binary encoded (to keep files small).

Graeme
 
These are excellent posts. Given that there is so much image data for each frame, there's no reason not to include at least as much metadata as DSLRs include, plus a unique frame ID. Even if each frame ID needs 100 bytes, if it's guaranteed unique that is VERY valuable. With recode at 27 MB/sec, it would only increase the overall datarate less than 0.01% (totally insignificant).

100 bytes gives 6.7x10^240 unique frames. A bit of overkill, as the number of atoms in the universe is estimated to be 10^79. So you could label each atom with a 33 byte serial number (counts up to 2^264 ).
 
You forgot one critical piece of meta-data. Even more critical than the output port: Resolution.

A numerical identifier would be sufficent for HD, 2k, 4k etc. This would facilitate proxy management, although Graeme keems hinting at an internal proxy system using the wavelett resolution levels.
 
Future-proofing... forward compatibility? Can the metadata format leave some room for future expansion? For example if some future RED TWO knows internally about lens focal length and aperture, GPS time, coordinates, etc. that might be put in the metadata too. If it's just XML and without an overall fixed size limit, then I guess this would be easily done.
 
Graeme_Nattress said:
We're storing as much metadata as we can along with each frame or clip.

Graeme
Click to expand...


Thanks Graeme - you're a patient man.

It does sound like you're designing a truly deep and thorough metadata system. But for day to day shot identification, elegance is also desirable. It's amazing to me how often editorial changes are still communicated by phone, fax, post-it note or napkin: "Replace shot #4 with 01:01:59:20... use the twenty minute offset for the close up shot... try the third take at the start of 9 hr..." I still hear stuff like that every day. I think the trick is to make RED frame IDs deep where they need to be - and simple where they can be. That is why I'm a fan of the tiered ID approach.

Three quick REDCINE questions:

1.) Will REDCINE be able to cine-expand (add 3/2 to) 24p footage?
2.) Will REDCINE recognize drop and non-drop frame formats?
2.) Will REDCINE be able to burn in frame IDs / timecode / keycode (I'd say redcode, but it seems to be taken)? It is likely that much of RED's extensive metadata may be lost when encoding to older codecs for offline editing. TC-burn-in is a handy backup.

Thanks again.
 
1), Could be wrong, but I don't think we plan to allow the addition of pulldown - let me explain. If you're working online, you don't want or need it. Anything decent will either show 24p as 24p, or add pulldown on the fly on output to HD like a Kona card. If you do add pulldown, you've just added the one major thing that will muck up any matchback edit, and screw up a data-centric workflow because you've just manipulated and mucked around with timecode. Sooner or later people will have to learn to ditch the antiquity that is pulldown, which today, in the progressive world, causes more harm than good.

2) Yes, I think, but Stuart would know for certain.

3) burn in - not sure.

Putting a unique id on each frame is the way to go to really stop any nasty issues, and I think that's in the spec.

Graeme
 
Just goes to show, these guys seems to be two steps ahead on all kinds of issues. Great post by the way. That has been something I've been wondering about, as I too have to deal with weird timecode issues all the time. That metadata will come in quite handy, and as far as I'm concerned, the more the better. Great idea about including the serial # of the camera in there as well. Might seem unnecessary, but in fact could be quite useful for identifying problems with cameras, etc.

Steve
 
Graeme_Nattress said:
1), Could be wrong, but I don't think we plan to allow the addition of pulldown - let me explain. If you're working online, you don't want or need it. Anything decent will either show 24p as 24p, or add pulldown on the fly on output to HD like a Kona card. If you do add pulldown, you've just added the one major thing that will muck up any matchback edit, and screw up a data-centric workflow because you've just manipulated and mucked around with timecode
Graeme
Click to expand...

Fair enough. Many older AVIDs had a real problem with 24p but they do seem to be going the way of the Dodo. But you might consider adding a suffix to each frame ID (A or B, 1 or 2) when fields are extracted. It is certainly likely that some folks will shoot 1080i (59.94) and then deinterlace for slow motion. This is done all the time in sports for instant replays. Adding a field suffix to each frame ID would solve that problem.

I agree with your comments on the way things are going - but a large chunk of the industry is not there yet. The majority of the broadcast market is still 59.94. True, you could always keep your project 24p throughout the entire post pipeline, and then simply cine-expand the final. Buuuuutttt... this is does limit your creative options for time-warps, vari-speeds, etc. I know many on-line guys who like to finish at 24p like this... and their vari-speeds are often choppy. I prefer to finish in the format that is required for market. I can attest that the most common vari-speed used in car commercials is 125% - which you can achieve by removing the 3/2 to give you back the smooth, beautiful progressive frames. You could not perform a smooth 125% vari-speed if you were mastering at 24p and then expanding the final.

Would allowing for field identification be a huge pain in the ass? For cine-expanding you could add a little script to set the A-frame so that the progressive frames could always be retrieved and IDed accurately.
Ultimately this is just my silly old fashioned preference - and there are always workarounds. I can live with forward thinking. Thanks for listening.
 
Graeme_Nattress said:
1) Sooner or later people will have to learn to ditch the antiquity that is pulldown, which today, in the progressive world, causes more harm than good.

Graeme
Click to expand...

I couldn't agree more. But the problem is not filmmakers - I don't know a single director, DOP, editor, actor, pa, etc. - who WANTS to master at 59.94. The problem is the broadcasters who mandate 59.94 delivery. I abhor fielding, but if it has to be in the final broadcast I'd far rather control it myself. Perhaps a solution is to shoot 30p for broadcast stuff and 24p for film. And for dual purpose projects? Well perhaps we'll leave that for another thread (who am I kidding - 24p baby! :) )
 
You must log in or register to reply here.
Back
Top