FORUMS: list search recent posts

Is drop frame needed / relevant anymore?

COW Forums : Apple Final Cut Pro X

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Patrick Donegan
Is drop frame needed / relevant anymore?
on Aug 28, 2016 at 1:18:05 am

If one is not producing anything fro broadcast, is it time to drop the drop frame?

Or is it the "just in case"?

Or - does DVD_Video and BluRay use or need drop frame?

I am just wondering .... about other people's experience and future knowledge.

Thanks!

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


Return to posts index

Oliver Peters
Re: Is drop frame needed / relevant anymore?
on Aug 28, 2016 at 12:24:56 pm
Last Edited By Oliver Peters on Aug 28, 2016 at 12:27:01 pm

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


Return to posts index

Patrick Donegan
Re: Is drop frame needed / relevant anymore?
on Aug 29, 2016 at 8:06:54 am

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


Return to posts index


Oliver Peters
Re: Is drop frame needed / relevant anymore?
on Aug 29, 2016 at 1:19:01 pm

[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


Return to posts index

Jeremy Garchow
Re: Is drop frame needed / relevant anymore?
on Aug 28, 2016 at 1:50:29 pm

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.


Return to posts index

Joe Marler
Re: Is drop frame needed / relevant anymore?
on Aug 29, 2016 at 11:57:06 am

[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#chapte...

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.


Return to posts index


Jeremy Garchow
Re: Is drop frame needed / relevant anymore?
on Aug 29, 2016 at 4:39:45 pm

[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.


Return to posts index

Warren Eig
Re: Is drop frame needed / relevant anymore?
on Aug 30, 2016 at 4:24:52 pm

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: http://www.BabyBoomPictures.com



For Camera Accessories - Monitors and Batteries
website: http://www.EigRig.com



Return to posts index

Jeremy Garchow
Re: Is drop frame needed / relevant anymore?
on Aug 30, 2016 at 5:30:53 pm

[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.


Return to posts index


Joe Marler
Re: Is drop frame needed / relevant anymore?
on Sep 1, 2016 at 12:28:37 am

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: http://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...

- 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.


Return to posts index

Jeremy Garchow
Re: Is drop frame needed / relevant anymore?
on Sep 1, 2016 at 2:30:44 am

[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.


Return to posts index

Joe Marler
Re: Is drop frame needed / relevant anymore?
on Sep 1, 2016 at 12:41:06 pm

[Jeremy Garchow] "you have to separate real time from NDF timecode. NDF tc, while expressed in hours/minutes/seconds, does not equal real time."

Yes I agree with this. In fact the Apple page on timecode stresses this, and the confusion which can occur by referring to timecode values as elapsed recording time or "length": http://bit.ly/1BlCL49

"Remember that these numbers don’t reflect time; they are simply unique identifiers. The first frame of NTSC video is labeled 00:00:00:00. The 29th frame is labeled 00:00:00:29, and the 30th frame is labeled 00:00:01:00. Again, just because a frame is labeled 00:00:01:00 does not mean that 1 second has passed. The frame could just as easily have been named AAABD, in which case there would be no temptation to read the label as a time value. Only the frame rate of the video can determine how much time has passed by the 30th frame."

"Timecode is merely a method of labeling frames with unique identifiers to easily find them again later. It is a convenient way of giving each frame a name that can be referred to later without having to verbally describe and visually search for it. Even though frame rate and timecode are independent, people commonly confuse the two, which can lead to frustrating problems in post-production."


Re measuring by elapsed recording time (not indicated time code) and equating this to frame count, both DF and NDF material with the same elapsed recording time will have the same frame count. This can easily be inspected with QT7 Pro, Invisor or other tools.

I still think there is a bug in how FCPX displays NDF 29.97 material. Even though the project and TC display format are set to NDF, it displays a shorter clip length in the timeline, as if it were 30 fps. Premiere CC does not do that. This is just another example of how you can't trust TC readouts and referring to TC duration as program length can be misleading. It's OK to refer to it as length for loose purposes but someone in the production -- the DIT or 1st AE, etc -- must know the nitty-gritty details.


Return to posts index


Jeremy Garchow
Re: Is drop frame needed / relevant anymore?
on Sep 1, 2016 at 3:21:43 pm

[Joe Marler] "Re measuring by elapsed recording time (not indicated time code) and equating this to frame count, both DF and NDF material with the same elapsed recording time will have the same frame count. This can easily be inspected with QT7 Pro, Invisor or other tools."

Sure, but that is impossible to tell someone (or more specifically, it would be impossible for a computer to find the right frame without the tc number, and using a frame number) because you'd never express a frame address in elapsed time because elapsed time could be relative to any starting point (or timecode!), or perhaps there's a break in tc and the frame count wouldn't calculate to the time. And you'd then have to do the math to say "go to 3 minutes elapsed time" as the frame count would NOT be the same on tape or in a file when calculating frames from the tc. So then the computer would have to ask itself, "what 3 minutes and where is it?"

Of course, if something is three minutes long, it's going to be three minutes long, but that has nothing to do with NDF timecode. "3 minutes" of NDF tc and 3 minutes of DF tc will have different frame counts because they are different lengths. I don't see how it would be necessary to express it any other way.

[Joe Marler] "Even though the project and TC display format are set to NDF, it displays a shorter clip length in the timeline, as if it were 30 fps. Premiere CC does not do that."

This is with a DF source? I don't know what you mean, exactly. Fcpx will add auto speed adjustments to keep whole frames, you can reset these auto speed changes. Is that what you mean?


Return to posts index

Joe Marler
Re: Is drop frame needed / relevant anymore?
on Sep 1, 2016 at 4:06:02 pm

[Jeremy Garchow] "This is with a DF source? I don't know what you mean, exactly. Fcpx will add auto speed adjustments to keep whole frames, you can reset these auto speed changes. Is that what you mean?
"


It's possible I looked at it wrong. Unfortunately I have to go out of town a few days and can't pursue it until I get back. Thanks for the discussion and I'd like to continue this later.


Return to posts index

Jeremy Garchow
Re: Is drop frame needed / relevant anymore?
on Sep 1, 2016 at 4:17:09 pm

[Joe Marler] "Thanks for the discussion and I'd like to continue this later.
"


Likewise!

Seems like forever since we've had a good ole fashioned timecode discussion around here! :)


Return to posts index


Troy LaFaye
Re: Is drop frame needed / relevant anymore?
on Jul 20, 2017 at 7:19:47 pm

I get the reason why fractional frame rates are required for NTSC equipment/broadcasts, but are they required under ATSC?

If so, why? One of the primary points of developing ATSC was to revamp the bandwidth to accommodate for HD video, but wouldn't that have given them the opportunity to solve the problem that created the need for fractional frame rates to begin with?

I understand that ATSC can support fractional rates, but does it requirement them to broadcast or display?


Return to posts index

Shane Ross
Re: Is drop frame needed / relevant anymore?
on Jul 24, 2017 at 7:09:07 pm

If you shoot and cut 23.98, then it's NDF (Non-Drop Frame) anyway, there is no such thing as 23.98 DF. That only exists in the 30fps world (well...59.94i or 29.97p). But then those of us in broadcast who need to get 23.98 to meet actual broadcast timings to a "T" need to either calculate what end time we need 23.98 to be to meet 29.97 DF timing...or use hand things like in Avid that allow us to monitor the 29.97 DF timing in a 23.98 project.

Drop Frame timing won't be going away any time soon, not until broadcast dies completely...and even then, distributors for the web might still require DF timing. I've cut two projects that were web only and they still insisted on DF for accurate timing.

Shane
Little Frog Post
Read my blog, Little Frog in High Def


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]