Help with 119.88 fps timelines w/wo dropframe

I'm struggling to understand how DaVinci 119.88 fps timelines work. I thought I understood dropframe, but ...

I'm using a GoPro 9 black and recording at 119.88 fps. The resulting mp4 files have the following metadata:
Video: 99.9Mb/s, 2704x1520(16:9) @119.880(120000/1001)FPS, Format: HEVC

As a test, I recorded 30 min of a running stopwatch.

DaVinci allows me to create a 119.88 FPS timeline with or without dropframe and defaults to non-drop-frame. Once a framerate is set I didn't see any reason to use dropframe.

I imported all of the GoPro generated mp4 files into a Davinci project timeline,
Time_30_NDF, set to 119.88 fps with Drop Frame UNCHECKED, trimmed the
footage to include ONLY the precise start of the stopwatch through to the
moment 30 min appeared on the stopwatch.

I rendered the result to a file, 30_min_trimmed.mp4, and added it to the Davinci
project's media pool.

Finally, I created a new 119.88 fps timeline with Drop Frame CHECKED, Time_30_DF, and
added 30_min_trimmed.mp4 to the start of this timeline.

The following table summarizes the two timelines:

Code: Select all

Timeline         Frames  Frames/119.88  Last frame TC  TC -> sec  Frames/sec
--------         ------  -------------  -------------  ---------  ----------
Time_30_NDF      215796  1800.1 sec     1:29:58:035    1798.3     120.000
Time_30_DF       215796  1800.1 sec     1:30:00;011    1800.1     119.881


According to the timecodes in the NDF timeline, the NDF timeline is a couple of seconds too short. The DF timecodes are what I'd expect (almost exactly 30 min). It appears (to me) that the timecodes in 119.88 fps non-dropframe timelines is wrong(?!). The timecode and number of frames implies 120 fps, right?

No doubt, I'm missing something here. I'd appreciate any help to understand what's happening here.

That seems correct to me. DF and NDF difference as expected.
It is showing TC. If you look at the frame count it is the same.

Remember that DF will show higher TC for the same amount of frames compared to NDF.
It is skipping certain :00 and :05 TC but not skipping actual frame.

As you can see number of frames is the same so it means it's 100% same data with same length. Nothing is dropped, etc. as many think
You can use what you want - best are actually frame numbers as they are always the same (regardless of frame rate)

NDF or "normal timecode" for integer fps (24,25, 50 etc) is simple: each frame is +1 frame to timecode. All works fine and timecode matches clock time.
For "fractional fps" it's not so easy, because you will end up with "fractional frames", eg. 00:12:10:15.4 if you start using eg. 119.88 based math. This doesn't work We need to find some other way to count those frames and this is what DF is about. Some clever/cheated way of counting timecode.
We could use NDF approach and we do, so use 120 (in your case) in math instead of 119.88, but then our timecode won't match clock time (as we did not really recorded with 120fps, so we have less frames).

With DF at every whole minute (except every 10th minute) timecode jumps from xx:00:59:29 to xx:01:00:02 not xx:01:00:00, so we skip 2 frames (just from counting not actual video frames). This is needed as we don't have 120 frames but bit less, so we need to "speed up" a bit to match realtime.

You can use same approach to 119.88 (which is 4x 29.97) and have non-realtime NDF or realtime DF timecode (as you found out).

Note that 119.88 is also 5x 23.976, but for 23.976fps DF timecode officially doesn't exits. We use NDF which matches 24fps based files and it's not real time.

My advice is to forget about those legacy rates (unless you specifically need them) and use proper integer numbers 24,25...60, 120 etc.
Everything except broadcast is "happier" with 24/30 etc. If you're not going to broadcast then you can forget about DF at all. It's only them who in most cases require supplied masters to use DF (as it matches real time, so works better for them). In any other case you choose what you want. Most important is to stay with chosen method. When you pass TC for check by someone else you both need to use same TC type or you will be looking at different frame (this is why frame numbers are the most solid measure).

Batter way of thinking about fractional fps is not as frame per second, but as how often you capture a frame.
So for 120fps you capture a frame every 1/120 of a second and for 119.88 at 1/119.88, so less often.
This gives you 0.0083333 of a second and 0.008341. In those "time distances" you capture a frame. This somehow makes more sense (at least for me) then saying I have 120 or 119.88 frames per second (how can you have fraction of a frame? ). In the same time you can say I captured frame every 0.0083333 or 0.008341 of a second and both make perfect sense (just different distance without anything confusing).

Thanks to both Andrew and mpetech for your quick replies. Unfortunately, my GoPro camera (hero 9 black) does not support 120 fps. Although the setup options say "120 fps" the mp4 files created are always "@119.880(120000/1001)FPS".

I think I understand dropframe and timecodes, and I apologize for being such a noob, but ...

When placing a timeline marker on the NDF timeline at the timecode 10:00:000, shouldn't the video frame show 10 min on the stopwatch? It doesn't, it shows "9:58.0".

On the DF timeline, however, the stopwatch times in the video match the timecode (almost) perfectly; i.e., the stopwatch indicates "10.00.0" at timecode 1:00;003.

I guess the root of my confusion is, why would one ever want a timeline at 119.88 fps without dropframe? The 119.88 NDF timeline is behaving the way I would expect a 120 fps NDF would with my footage.

So, I also tried both a 120 fps NDF and a 120 fps DF timeline with the same footage. DaVinci surprised me once again. It magically added frames to the 120 fps NDF timeline; it shows 216011 frames instead of 215796!

Code: Select all

Timeline         Frames  Frames/120     Last frame TC  TC -> sec  Frames/sec
--------         ------  -------------  -------------  ---------  ----------
Time_30_120_NDF  216011  1800.1 sec     1:30:00:011    1800.1     120.000
Time_30_120_DF   215796  1800.1 sec     1:30:00;011    1800.1     119.881


I can see this as a legit feature of DaVinci, but where did the new frames come from, how were they created, or are they in my original footage?

It seems that if I want timecodes, footage, and computed frame rates to be consistent, I must use either 119.88 fps DF or 120 fps DF DaVinci timelines.

Last question (really!): Is there any reason to prefer a 120 fps DF timeline over a 119.88 DF timeline? Are these two timelines really just the same thing to DaVinci?

For 120fps you should not be able to activate DF timecode as it makes no sense.
Also - real 120fps recording vs. 119.88 will have different number of frames.
If you wan to normalise footage to 1 of them you assume new fps in clip attributes, but then your audio will be out of sync, so you need to process it as well to stay in sync. You're basically speeding/slowing down your footage, depending which way you go.
Also- apparently here may be actually a bug in Resolve with high fps DF timelines. I just read it on the forum, not sure which thread.

Also- apparently here may be actually a bug in Resolve with high fps DF timelines. I just read it on the forum, not sure which thread.

Maybe it was my scripting thread, but the bug is in libavutil, not Resolve. Resolve isn't affected by the bug but if you reference libavutil in a Resolve script to convert frames to timecode it will ignore drop frame for 119.88DF.

Ok, yes it probably was.

Thanks again for the rapid responses to my questions!

if you reference libavutil in a Resolve script to convert frames to timecode it will ignore drop frame for 119.88DF

Actually, that's what I was expecting: I figured the only reason for 119.88 fps was to enable playback at "30 fps" DF to get exactly 1/4 speed slo-mo at standard broadcast framerates. I assumed that enabling "Use Drop Frame" (DF) would have no effect and the Resolve "bug" was simply to fail to disable the option for 119.88 fps.

What I'm discovering, however, is that there are real (negative) consequences to my timelines if I don't enable DF.

Also, as Andrew pointed out, "real 120fps recording vs. 119.88 will have different number of frames." In fact, that's what seems to happen in the timelines: adding the exact same footage to a 120fps NDF timeline appears to have more frames (exactly the right amount to ensure 120 fps for clips that were shot at 119.88 fps)! Where do these extra frames come from?! I'm beginning to appreciate the corporate name "BlackMagic Design"

When I saw this, I figured that I should treat "120fps DF" like "30fps DF"; i.e., the "DF" qualifier implies the real fps is slightly lower to accommodate NTSC and, if you need/want frame accurate labeling, use the DF algorithm. In other words, other than being much easier to say, "120fps DF" is really the same as "119.88 fps DF".

Anyway, if any or all of this looks like a Resolve bug, should I be posting to a different forum/support list?

Again, thanks for all the very timely replies. It's been really helpful - if only for my peace of mind.

dave

Resolve is handling this as it should, there's no bug that I can see.

Maybe it's easier to explain from the other end, if you have timelines that are the same duration in timecode but using the three different frame rates. With a 01:00:00:00 timeline in 120fps, it's 1 hour in "real" time. If it's 119.88 NDF, it's playing the same frame count but slower, making the duration in real time 1 hour and 3.6 seconds. The timecode is the same for both as it can only refer to whole frames. Another way to think of it is that as far as timecode is concerned, the frame rate is 120 in both cases.

The 119.88 DF timeline will have fewer frames so the resulting real time is as close to 1 hour as possible. It's just slightly under 1 hour, the difference is about 4 milliseconds per hour.

The standard only supports drop frame on frame rates that are divisible by 29.97 (or 30000/1001). So there's no 120fps DF, just 119.88fps DF.

Actually, that's what I was expecting: I figured the only reason for 119.88 fps was to enable playback at "30 fps" DF to get exactly 1/4 speed slo-mo at standard broadcast frame rates.

Note that there is no 30fps drop-frame standard. It only goes to 29.97 drop-frame and then stops; 30fps is always non-drop.

I don't think you'll see a palpable difference in terms of changing the speed in Clip Attributes. For slo-mo purpuses, there's no difference between 29.97fps and 30fps (coming down from 120fps).

To me, people should stay as far away from DF timecode as they can unless they're specifically delivering news footage for broadcast or creating a final broadcast deliverable for network TV.

When I saw this, I figured that I should treat "120fps DF" like "30fps DF"; i.e., the "DF" qualifier implies the real fps is slightly lower to accommodate NTSC and, if you need/want frame accurate labeling, use the DF algorithm. In other words, other than being much easier to say, "120fps DF" is really the same as "119.88 fps DF".

120 will always be real-time and be the same as 119.88 DF as long as you have 2 separate recordings at each fps. As I said 120 and 119.88 are not the same recordings and will have different frame numbers. You can’t interchange them directly as they are as different as eg. 24 and 25fps (just smaller difference).
If you want use both than you speed up/slow down. Different is small so even after processing audio you are fine.

Note that there is no 30fps drop-frame standard. It only goes to 29.97 drop-frame and then stops; 30fps is always non-drop.

The standard only supports drop frame on frame rates that are divisible by 29.97 (or 30000/1001). So there's no 120fps DF, just 119.88fps DF.

Sorry, my mistake. Thanks for pointing this out, I should have been more careful. I've only used 119.88 and 120 timelines and Resolve allows me to independently select "Use Drop Frame" (DF). I wrongly assumed the same would be true for the other framerates: it's not, Resolve only allows DF for 29.97, 59.97, 119.88.

...people should stay as far away from DF timecode as they can unless they're specifically delivering news footage for broadcast or creating a final broadcast deliverable for network TV.

Ironically, that's what I was trying to do. But, it seems that if I want time in the video to match the timeline's time, I have no choice but to enable "Use Drop Frame". If I don't enable it, timeline markers will have progressively inaccurate times that are significant for my usage.

I apologize for being dense about this but, to be honest, I still don't get why I need to specify "Use Drop Frame" for a fractional framerate. In the table below, the same 30 min footage of a running stopwatch added to two separate 119.88 fps timelines (one with and one without DF) results in different durations.

Code: Select all

Timeline         Frames  Frames/119.88  Last frame TC  TC -> sec  Frames/sec
--------         ------  -------------  -------------  ---------  ----------
Time_30_NDF      215796  1800.1 sec     1:29:58:035    1798.3     120.000
Time_30_DF       215796  1800.1 sec     1:30:00;011    1800.1     119.881

Note: Frame numbers and timecodes are reported by the timeline, the other columns are computed assuming an average framerate of 119.88 fps.

I've attached screenshots of these two timelines and you'll see that the NDF timeline labels the 30 min frame of the stopwatch with a timecode of 29:58:035; i.e., almost 2 seconds off. But, the DF timeline gets it much closer at 30:00;011. Is this really what's expected?

119.88 fps timeline with "Use Drop Frame" disabled

timeline_30_NDF.png (688.47 KiB) Viewed 1340 times

119.88 fps timeline with "Use Drop Frame" enabled

timeline_30_DF.png (614.93 KiB) Viewed 1340 times

1800,1-1798,3=1.8 and this is exactly 30*60*0.001 (because speed difference between 120 and 119.88 is 0.1%)
Difference is 1.8 second, so all looks fine.
Resolve TC shows 1sec +120-35 frames so it's 1.71 seconds, so close enough taking into account your measuring method (specially that 11 frames (DF timecode) is 0.09 sec)
On 30min source you are of by 1.8 sec when not using DF timecode and this is correct. It's basically 0.1%, so 3.6 sec for 1h (3600 seconds).
You really making it more complicated than it really is

Last note: 119.88 is just a rounding of exact value 120000/1001 (same as 29.97 is really 30000/1001).

I think the key to understanding why time doesn't match timecode when using fractional frame rates is that you should view timecode as a numbering system for frames. It's not time (or clock-on-the-wall-time as it's sometimes referred to).

If you're recording at 29.97 fps, the frame rate for the timecode is still 30 as it can only count whole frames. That's what makes the difference.

Note that there is no 30fps drop-frame standard. It only goes to 29.97 drop-frame and then stops; 30fps is always non-drop.

The standard only supports drop frame on frame rates that are divisible by 29.97 (or 30000/1001). So there's no 120fps DF, just 119.88fps DF.

Thanks again for setting me straight. I think I finally found the source of my confusion. I interpreted "Non Drop Frame" too literally and mistakenly thought that any timecode that isn't NTSC Drop Frame is "Non Drop Frame".

Why? Mostly because I'm a noob, but also because Resolve Studio allows me to create 119.88 fps timelines that are optionally Drop Frame (or not). It also allows me to create 120 fps timelines. It didn't occur to me that a 119.88 fps Non-Drop Frame timeline is effectively just a 120 fps timeline.

When I saw that it's possible to opt out of Drop Frame in a 119.88 fps timeline, I thought "Great! Resolve has another way to label frames that isn't Drop Frame, is also real-time (or close enough, like Drop Frame is) only better". After all, why offer both 119.88 fps Non-Drop Frame and 120 fps timelines if they're the same? Plus, there are alternative timecodes that respect fractional frame rates better than simply moving up to the nearest whole number of fps. Yes, they'll still have to occasionally skip timecodes, but they'll also not be NTSC Drop Frame; e.g., for 30000/1001 fps, skip one count every 30 seconds except during minutes divisible by 10.

The option to enable/disable Drop Frame for 119.88 fps timelines

119_timeline_opts.png (44.76 KiB) Viewed 1210 times

BTW: I still don't understand why 119.88 Non-Drop Frame is an option in Resolve. If anyone knows, I'm keen to know why.

You really making it more complicated than it really is

You're right, I was.

For the record: I like Resolve, recommend it to others, and recently upgraded to Studio so I can work with high frame rates and fully leverage my GPU.

I started using Resolve for its ability to export/import text files and control it from Python. Add to that a helpful and responsive user community willing to engage with a beginner, well ... I know I made the right choice.

Thanks again for your help (and patience).

NDF is used along DF as in many cases no one bothers with DF as they don't care about it not been realtime. It's just used as a point of reference, so when collaborating you can talk about same point in video.
DF is mainly used in broadcast where real time matters for them.
DF skips counting every minute not 30 seconds (except every 10th minute).
For manipulating video with use of Python look at vapoursynth- if you know Python you will be in your world.

NDF is used along DF as in many cases no one bothers with DF as they don't care about it not been realtime. It's just used as a point of reference, so when collaborating you can talk about same point in video.

Thanks, that makes sense. DF can be awkward to work with and, in a collaboration, some my need realtime while others will be more effective without it.

FWIW: I'm editing footage of fencing bouts, in which it is common for the athletes to request video replay in order to determine who should be awarded a touch. So, high frame rates are essential. As for real-time, I've been using the videos to double check the electronic "scoring boxes" which are used to enforce the very precise timing in the rules. For example, to be awarded a touch for a riposte in foil, it must occur within 0.3 seconds. Boxes are known to fail and the timing in the rules has evolved over the years, so it's nice to have a second measurement. After writing this, I realize this is not a reason for needing realtime. All I really know is that there's something in my workflow that causes video and audio drift that's corrected by DF. I need to review my flow more carefully.

DF skips counting every minute not 30 seconds (except every 10th minute).

Right, I only used that as an example of a timecode that is not DF but, for my usage, would have been better than rounding 119.88 fps to 120 fps in a Resolve timeline that was specified to be 119.88 fps. I had imagined that something like this was taking place in 119.88 fps timelines when I unchecked the "Use Drop Frame" option.

For manipulating video with use of Python look at vapoursynth- if you know Python you will be in your world.

Thanks! I'll check this out.