Is drop frame needed / relevant anymore?

[Oliver Peters]

Drop-frame is purely a function of timecode and has to do with how you count frames. The counting scheme in drop-frame TC allows 1 hour of TC to equal 1 hour of clock time. If you aren’t producing for broadcast – or if it’s only TV commercials – then it’s perfectly OK to use non-drop-frame TC.

Don’t confuse drop-frame with the fact that video runs at 23.976, 29.97 or 59.94 versus a true 24, 30 or 60. That is NOT drop-frame. Fractional frame rates are required to be in sync with any TV standard. So if you are creating a DVD designed to play on standard TVs, then it needs to be produced in a fractional frame rate. If your content is for a web file or purely theatrical, as in a DCP, then it can be a whole frame rate.

– Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com

[Jeremy Garchow]

You should produce a drop frame master if your timing has to be exact to real time (45 minutes of video runtime equals 45 minutes of real time). Otherwise, you don’t need drop frame.

[Patrick Donegan]

Oh, my …

I know nothing about “fractional frame rate”

I thought it was just the drop frame part of it.

I so need to understand that one.

FCP X 10.2.1 – user since FCP 1.25
iMac mid 2011, MBA mid 2012
iPhone 4
HVX-200, Shure wireless mic
Miller Solo tripod
Advanta-Jib

[Joe Marler]

[Jeremy Garchow] “You should produce a drop frame master if your timing has to be exact to real time (45 minutes of video runtime equals 45 minutes of real time). Otherwise, you don’t need drop frame.”

By “video runtime” if you mean literal playback time as measured by the wall clock, I don’t think this is correct. Using the NTSC/ATSC fractional frame rate of 29.97, 45 min of video runtime will equal exactly 45 min of real world playback time. This is because it is both recorded and played back at 29.97 fps. Provided you play back at the speed it was recorded, any frame rate (fractional or otherwise) will have the same playback time as record time.

Drop frame timecode is only needed to ensure the recorded timecode consistently matches up with actual program duration. Without this, by the end of an hour-long program the time code would be 3.6 seconds behind the actual elapsed time. If the playback system has “time to go” or “time from start” counters derived from the recorded timecode, these would gradually become inaccurate unless drop frame timecode is used. It would be impossible to FF or REV to a specific timecode value and have that match the elapsed program time to that point. However the actual real-world elapsed time remains accurate between playback and record of 29.97 material.

So it’s not the video frames that are dropped, but timecode values are periodically dropped to keep them in sync with real-world elapsed time. The only purpose of this is to keep the timecode (or HH:MM:SS:frame addressing system) in sync with elapsed program time.

There is a good explanation here: https://documentation.apple.com/en/finalcutpro/usermanual/index.html#chapter=D%26section=6%26tasks=true

SMPTE timecode is true metadata in HH:MM:SS:frame format recorded in a standardized format. Some devices like Zoom H4 and certain Tascam audio recorders show a “pseudo timecode” but this is not SMPTE and cannot be used by editing software to sync based on timecode.

[Oliver Peters]

[Patrick Donegan] “I so need to understand that one.”

When video went from B&W to color in the US, the frame rate was “slowed” in relationship to the electrical current. Instead of being based on a 60Hz standard (electrical current), it was changed to a 59.94Hz standard. Thus video changed from 30.0fps to 29.97fps, which is called a fractional frame rate. It’s important to realize that there aren’t any actual fractions of frames. Merely that 1/30th of a second of video takes a slightly longer duration than a true 1/30th of a second as measured on a clock.

When timecode was introduced, engineers realized that an hour of time as measured in timecode was in fact 108 frames longer in time than an hour as measured on a clock. This was no good for network timing because you’d miss commercial breaks. Thus the drop-frame timecode scheme was developed to aid in this sort of timing issue.

Regardless of how you time the program – timecode or not – the color video standard is still based on 29.97/59.94 in NTSC countries and this means a video signal still has to conform to that standard because TV sets are still manufactured based on that standard. This doesn’t apply to theatrical projection or the web, which is why whole frame rates (a true 30.0fps or 24.0fps) can be used there.

– Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com

[Jeremy Garchow]

[Joe Marler] “By “video runtime” if you mean literal playback time as measured by the wall clock, I don’t think this is correct. Using the NTSC/ATSC fractional frame rate of 29.97, 45 min of video runtime will equal exactly 45 min of real world playback time. “

I think we are saying the same thing, but differently.

45 minutes of non-drop frame video does not equal 45 minutes of real time. Otherwise, why would we need drop frame?

Drop-frame was created to accommodate the fractional drift from real time. A 45 minute (meaning a movie with 45:00:00 tc) non-drop fame movie will not play back in 45 minutes (because a 45 minute non-drop frame movie isn’t really 45 minutes long). A 45 minute drop frame movie will play back in 45 minutes.

45:00:00 of DF is 80918 frames
45:00:00 of NDF is 81000 frames.

The NDF movie is literally longer, even though the elapsed tc matches at 45:00:00 of tc.

[Joe Marler] “Drop frame timecode is only needed to ensure the recorded timecode consistently matches up with actual program duration. Without this, by the end of an hour-long program the time code would be 3.6 seconds behind the actual elapsed time. If the playback system has “time to go” or “time from start” counters derived from the recorded timecode, these would gradually become inaccurate unless drop frame timecode is used. It would be impossible to FF or REV to a specific timecode value and have that match the elapsed program time to that point. However the actual real-world elapsed time remains accurate between playback and record of 29.97 material. “

Again, I think we are saying the same thing.

[Joe Marler] “So it’s not the video frames that are dropped, but timecode values are periodically dropped to keep them in sync with real-world elapsed time. The only purpose of this is to keep the timecode (or HH:MM:SS:frame addressing system) in sync with elapsed program time.”

No, you aren’t dropping actual frames, but you do have to edit out frames. For instance, create a 45:00:00 non-drop movie. Add that movie to a 45:00:00 df timeline, your movie is now not 45 minutes long, so you have to adjust the timing of your edit. This can not and does not happen during playback, is accounted for in the master. I have to do this frequently from going 23.98 (non drop) to 29.97 drop. It’s a big pain, and I simply can’t copy/paste timing from one to the other as even the timecode may match, the timing does not.

[Warren Eig]

I think what Jeremy is say is, 45 minutes of video is 45 minutes of video. The only thing that changes is the SMTP time code associated with it so the broadcasters clock stays the same. Since video plays back NTSC at 29.97, the timecode clock would cause a drift. Hence DF TC.

Warren Eig
O 310-470-0905

email: info@babyboompictures.com
website: https://www.BabyBoomPictures.com

For Camera Accessories – Monitors and Batteries
website: https://www.EigRig.com

[Jeremy Garchow]

[Warren Eig] “I think what Jeremy is say is, 45 minutes of video is 45 minutes of video.”

Kinda! 🙂

45 minutes of NDF 29.97 video is 45 minutes of timecode, but not 45 minutes of real time.

45 minutes of DF 29.97 video is 45 minutes of real time.

[Joe Marler]

The OP asked a simple question but this can be a confusing area. Here are several key concepts:

– 30 min of video recording time (by the wall clock) will always equal 30 min of playback time (by the wall clock), whether using DF or NDF timecode — unless that material is somehow manipulated. In these cases timecode means SMPTE timecode, an 80-bit number which is encoded as metadata with each frame, in the format HH:MM:SS:FF (hours:minutes:seconds:frames).

– No matter what frame rate you record at (whether a fractional or integer frame rate), if the material is played back at the same rate, the elapsed real-world recording time will equal the playback time.

– No frames are ever dropped during DF recording or playback — only timecode values are adjusted. Quicktime Player 7 Pro will show the timecode values jump during playback at the minute boundary. There is no visible glitch due to lost frames, because only timecode is adjusted. Likewise pressing the pop-up menu on the QT7 timecode and selecting “frames” will show the same number of frames in 30 elapsed minutes of DF *and* 30 elapsed minutes of NDF material. FCPX can also show DF or NDF TC on a per-clip basis by selecting the clip, then Inspector>Info>Timecode Display = DF or NDF. The project’s TC format can be examined or changed by selecting the project, then Inspector>Info>Modify Settings

– Although we often refer to the TC values as if they were elapsed time (e.g, “minutes of video”), in fact the TC values do not reflect time per se — they are merely identifiers which are *similar* to time. This is made clear in Apple’s informative page about TC: https://bit.ly/1BlCL49 This is also obvious since the TC display format can be changed (as above) for a clip loaded in the editor. Obviously the true elapsed time of the video material is not changing when we change the TC display format, no more than the true length of an object changes when we measure in centimeters vs. inches.

– Similarly some audio material (such as that recorded by a Zoom H4 or lower-end Tascam field recorders) does not contain SMPTE timecode, even though the device may display a pseudo-timecode. When this material is imported into an editor it has a true duration based on the real-world recording time. Various editors may display a timecode-like number, but the file has no timecode in it. But we don’t call the duration zero just because there is no SMPTE timecode data. This illustrates how the program length is not determined by the encoded SMPTE timecode or by how the editing software displays it. Rather it is determined by the real-world recording time, or the frame count divided by the frame rate. In the case of audio I suppose you could divide the sample count by the sample rate. Why not just trust what the editing software tells you? See below.

– What IS different in DF recording is the TC rate (NOT the actual video frame rate) is effectively 0.1% faster than NDF. However some cameras when shooting DF material will display elapsed recording time not the actual SMPTE timecode.

So if someone tells you go shoot exactly 10.00 hr of 29.97 material, when the camera “HH:MM:SS” display (not necessarily the TC display) says 10:00:00, you have exactly 10 hr — despite shooting DF. Inside the video file the SMPTE TC value will be (I think) 10:00:36:01, but there will be exactly 1078920 frames in that file, exactly 10.00 elapsed hours. Had 29.97 NDF been used there would also be 1078920 frames in the file, also covering exactly 10.00 hr of elapsed time. The frame count can be confirmed by viewing the file with QT7 or tools like Invisor: https://itunes.apple.com/us/app/invisor-media-file-inspector/id442947586?mt=12

– When you *import* that 10 hr of DF material into an editor, the software has a decision to make when representing TC. It could show actual DF timecode which would mean the TC values would jump two frame numbers at the top of each minute. Both QT7 Player and FCPX will show that if configured. Or it could show a “fixed up” version of the TC so frame numbers don’t jump. The software must also decide how to graphically represent the material on the timeline. IOW does the timeline length and x-axis marks end at the real-world program duration? What about when conforming two different formats? Regardless, these are simply changes to the *displayed* TC representation. The underlying TC data and frame count in the files do not change.

– There may be a bug in how FCPX displays TC for NDF 29.97 material. When I import a clip with a known frame count to a 1080p/29.97 NDF project with NDF display format, the timeline nonetheless displays a slightly shorter length. The length is shortened by exactly the amount as if the timeline display logic was hard-coded to 30 fps, IOW it shortens the displayed timeline length by 0.1%. This display anomaly makes it hard to figure out what is going on — especially in a project where you’re mixing DF and NDF material. IOW are changed timeline lengths the result of a conforming algorithm, is it an intentional display simplification or is it a display bug? I don’t know.

[Jeremy Garchow]

[Joe Marler] “- There may be a bug in how FCPX displays TC for NDF 29.97 material. When I import a clip with a known frame count to a 1080p/29.97 NDF project with NDF display format, the timeline nonetheless displays a slightly shorter length. The length is shortened by exactly the amount as if the timeline display logic was hard-coded to 30 fps, IOW it shortens the displayed timeline length by 0.1%. This display anomaly makes it hard to figure out what is going on — especially in a project where you’re mixing DF and NDF material. IOW are changed timeline lengths the result of a conforming algorithm, is it an intentional display simplification or is it a display bug? I don’t know.”

I don’t want to over complicate this, but you have to separate real time from NDF timecode. NDF tc, while expressed in hours/minutes/seconds, does not equal real time. An NDF movie is going to be longer than its drop frame counter part of the hours/minutes/seconds/frames values are equal. If you use frames to measure (so that you have a file that’s 54,000 frames or whatever) the timecode will not match.

54,000 frames at 29.97 DF is 30:01;24
54,000 frames at 29.97 NDF is 30:00:00

Now if you use a different way to measure, and you are using time as the stick and not frames,

30 minutes (30:00;00) of 29.97 DF video is 53,946 frames
30 minutes (30:00:00) of 29.97 NDF video is 54,000 frames.

Since a good (only?) reason to use DF timecode is to measure program length against real time exactly, then it’s best to calculate the amount of frames needed to fit the required clock time, and you will get different lengths in DF and NDF. If a station specified the number of frames and a frame rate of 29.97, you will give them two different length movies depending on the timecode used (DF vs NDF).

So yes, recorded time equals real time, but it does not equal NDF timecode (and timecode is metadata that describes the location of a frame in a continues series of frames). And when you say an NDF movie has a tc of 30:00:00, it’s not 30 minutes long even though everyone in the world will say it’s 30 minutes long. Said another way, an NDF movie of 30:00:00 has a run time of 30 minutes, 1 second, and 24 frames of clock time.