View Full Version : how are different speeds handled?
a.falk
09-26-2008, 06:38 AM
hi there,
i received red-footage which tells me (in the quicktime-ref's) that it is playing with 25fps, 29,97fps & 50fps but is containing 25fps-timecode over all clips.
so with that i'm not able to import the clips frame-by-frame into media composer. the 50fps clips dump every second frame, so the slowmo's import as realtime-clips.
is there something wrong on the set with the camera-setup or am i doing somethign wrong?
i thought that speed-changes in recording (like slomo's) have exact timecodes, so that a 50fps recording is 2 seconds in timecode.
thanks.
Stuart English
09-26-2008, 07:46 AM
I received red-footage which tells me (in the quicktime-ref's) that it is playing with 25fps, 29,97fps & 50fps but is containing 25fps-timecode over all clips. so with that i'm not able to import the clips frame-by-frame into media composer. the 50fps clips dump every second frame, so the slowmo's import as realtime-clips.
is there something wrong on the set with the camera-setup or am i doing somethign wrong?
Where did you receive those clips from? It is probably not a camera set-up issue.
a.falk
09-26-2008, 07:53 AM
well, they are straight off the camera to a backup hard disk.
i'm opening the quicktime-refs and i am seeing 25fps timecode but 25; 29,97 & 50fps playback.
in 50fps-clips every timecode-frame contains 2 different frames of content.
a.falk
09-27-2008, 09:27 AM
anybody?
can't nobody tell me how this happens?
i would like to tell the production crew what went wrong.
or is this the way slomos are handled by red?
MichaelP
09-27-2008, 12:52 PM
I could see the 25fps for 50fps capture as a means of slomo inidication. Can the production tell you if that footage was shot at different frame rates?
Michael
jimhare
09-27-2008, 02:21 PM
You set a single time base for all clips for each piece of formatted media, so it makes sense that the timecode is all 25. The only indication should be the visual speed of the clips.
If you aren't seeing that (they all appear to play at normal speed) then maybe you should export the clips from REDCINE/REDALERT before importing them.
a.falk
09-28-2008, 03:41 AM
production crew did change the frame-rates on set.
but the main-problem i think with handling it this way is that you don't have unique timecode per frame of content.
so you cannot reference back to the exact frame with one timecode. e.g. 01:01:05:17 contains 2 frames of information.
how do you handle this when onlining?
if you take a look on how this is handled by p2-slomos.
timecode-base is always 60fps, frame-speeds can be 4-60 fps.
and the main factor is: every frame is indicated by a unique timecode.
that's the most important thing in an offline-/online-process.
without that you're lost!
so there must be an appropriate solution with red, starting with the base-files, not converting them!
otherwise you can always trash your timecode recorded on set.
MichaelP
09-28-2008, 07:08 AM
Over time, this is bigger issue as SMPTE only has "standard" timecode for 24, 25, and 30. 50fps and 60fps are not SMPTE standards. So there are relational references to frames when under 60... but for anything faster... you're out of luck.
What is needed is an additional unique ID - that is frame based and not affected by recording speed. Something like... KeyKode! ;) A similar concept for frame ID but for file based cameras. This is not new - several manufacturers have been discussing a "virtual KeyKode" concept for a while now.
Perhaps this is when it is necessary to repurpose the edgecode within the R3D file for unique identification of a frame when using offspeed recording? Avid tracks both timecodes when getting an ALE from REDrushes. Something I need to look into. I only have one offspeed file to play with. Anyone got any to share with me?
Michael
a.falk
09-29-2008, 12:20 AM
i think the most practicable way would be to use edgecode to be frame-accurate. there's no need for edgecode to be sync to real time. "tod" is for that.
so simply use 25fps timecode-base.
when recording offspeed-playback ensure that timecode is frame-accurate.
no more problems with that.