The standard rates
ITU-R Recommendation BT.709, the standard for HD television, specifies picture rates of 60, 50, 30, 25 and 24 Hz. For the 60, 30 and 24 Hz systems it also specifies those values divided by 1.001. That division is where the odd numbers come from:
| Rate | Exact | Frame lasts | Frames per minute |
|---|---|---|---|
| 23.976 fps | 24000/1001 | 41.708 ms | 1,438.6 |
| 24 fps | 24 | 41.667 ms | 1,440 |
| 25 fps | 25 | 40.000 ms | 1,500 |
| 29.97 fps | 30000/1001 | 33.367 ms | 1,798.2 |
| 30 fps | 30 | 33.333 ms | 1,800 |
| 50 fps | 50 | 20.000 ms | 3,000 |
| 59.94 fps | 60000/1001 | 16.683 ms | 3,596.4 |
| 60 fps | 60 | 16.667 ms | 3,600 |
29.97 is a rounded label. The true rate is 29.97003 frames per second, and 23.976 is really 23.97602. Two files labeled 30 and 29.97 do not have the same number of frames per minute.
YouTube's upload guidance lists 24, 25, 30, 48, 50 and 60 as common frame rates and asks for video to be uploaded at the rate it was recorded. It recommends a higher bitrate for the high rates of 48, 50 and 60, for example 12 Mbps instead of 8 Mbps for 1080p, because there are twice as many pictures to encode. File size per minute at each resolution is in how big is a video file.
Timecode and the 3.6 second problem
Timecode labels every frame as hours:minutes:seconds:frames. At 30 fps the frame field counts 00 to 29 and the labels match the clock exactly. At 29.97 fps the counter still counts to 29 before the second ticks over, but the frames arrive slightly slower. Microsoft's documentation describes this as the discrepancy between video at 29.97 frames per second and a time code display of 30.
The arithmetic: one real hour holds 107,892.1 frames at 29.97 fps. Counted at 30 labels per second, those frames reach a timecode of only 3,596.4 seconds. Non-drop timecode therefore falls 3.60 seconds behind the clock every hour, about 86 seconds a day. A one-hour program would read 00:59:56 at its real end.
How drop-frame timecode fixes it
Drop-frame timecode skips some labels so the count keeps pace. Microsoft's description of the rule: frame numbers 00 and 01 are skipped at the start of each minute, except for minutes that are multiples of ten. It adds that only the numbers in the timecode are dropped; no actual frames are.
That leaves 107,892 labels per hour against 107,892.108 real frames. The remaining error is 0.108 frames an hour, or about 86 milliseconds a day. Drop-frame only applies to the 1001-based rates. At 24, 25, 30 or 60 fps whole frames match whole seconds and no labels need skipping.
Converting between rates
Changing the frame rate means inventing or discarding pictures. Going from 30 to 24 fps removes one frame in five; going from 24 to 30 shows one frame in four twice. Either way the pictures are no longer evenly spaced in time. That is the practical reason behind YouTube's advice to keep the recorded rate. The same applies to interlaced material: YouTube asks for it to be deinterlaced first, for example 1080i60 to 1080p30.
Cutting a clip does not change its frame rate. The trim video tool's fast mode copies the streams unchanged, so a 29.97 fps file stays 29.97 fps; only the start and end move. Containers and codecs, which are a separate question from the rate, are covered in MP4 vs WebM vs MOV.
Frame rate in a GIF
The GIF89a specification stores the delay before each frame in hundredths of a second. Only rates that divide 100 evenly are exact:
| Delay per frame | Frame rate |
|---|---|
| 2 hundredths (20 ms) | 50 fps |
| 3 hundredths (30 ms) | 33.3 fps |
| 4 hundredths (40 ms) | 25 fps |
| 5 hundredths (50 ms) | 20 fps |
| 6 hundredths (60 ms) | 16.7 fps |
| 10 hundredths (100 ms) | 10 fps |
24 fps needs a delay of 4.17 hundredths, which the format cannot store. If every delay is rounded to 4, a 10-second clip of 240 frames plays in 9.6 seconds. 30 fps falls between 3 and 4, so a constant delay gives 33.3 or 25 fps. The video to GIF converter handles 30 fps by alternating delays of 3 and 4 hundredths, which keeps the total length right while the frames are not quite evenly spaced; 5, 10, 20 and 25 fps need no rounding at all. Lower rates also shrink the file, since a GIF stores every frame as a full picture. When you build a GIF from still images in the GIF maker, you set the delay per frame directly, so enter it in whole hundredths, such as 0.04 or 0.1 seconds.
Frame rates and subtitles
Subtitle files such as SRT store times in hours, minutes, seconds and milliseconds, not frames. That makes them independent of the frame rate, until the video's speed changes. Suppose subtitles were timed for a 23.976 fps file and the video you have plays the same frames at 25 fps. It runs 4.3 percent faster, so a line that belongs at 60:00 in the original appears at 57.54 minutes in your copy, about 147 seconds early. At the start the error is zero; it grows steadily over the film.
A constant offset, where every line is two seconds late, is fixed by shifting all times. A growing offset needs the times stretched. The subtitle timing shifter does both: shift by a fixed amount, or sync by two points, an early line and a late line, and it scales everything in between.
Which rate to use
- Match the rate of the footage you already have, and keep it through editing and export.
- Use the 1001-based rates only when your camera or delivery requires them, and then use drop-frame timecode for anything timed to the clock.
- For GIFs, choose a rate whose delay is a whole number of hundredths: 10, 20, 25 or 50 fps.
- When subtitles drift, check whether the offset is constant or growing before you fix it.
Frequently asked questions
Why is it 29.97 and not 30 fps?
The fractional rates are the whole rates divided by 1.001, which ITU-R BT.709 lists alongside 60, 30 and 24 Hz. 30 ÷ 1.001 = 29.97003 frames per second. Microsoft's documentation describes it as the NTSC video rate that drop-frame timecode exists to correct for.
What is drop-frame timecode?
A way of numbering frames at 29.97 fps so the timecode stays in step with the clock. Frame numbers 00 and 01 are skipped at the start of each minute, except minutes 00, 10, 20, 30, 40 and 50. Only the numbers are skipped; no picture is removed. Without it, the timecode falls 3.6 seconds behind real time per hour.
Is 24 fps or 30 fps better?
Neither in general. YouTube asks for video to be uploaded at the frame rate it was recorded and lists 24, 25, 30, 48, 50 and 60 as common. Converting between them repeats or drops frames, so the pictures are no longer evenly spaced in time. Record at the rate you will deliver.
Why does my GIF play at the wrong speed?
GIF stores each frame's delay in hundredths of a second. 24 fps needs 4.17 hundredths per frame, which cannot be stored. A converter that rounds every delay to 4 makes the GIF play at 25 fps, 4 percent fast. Pick 10, 20, 25 or 50 fps for an exact, even GIF speed.
Why do my subtitles drift out of sync?
If the subtitles were timed for a version of the video with a different frame rate or speed, the offset grows over the running time instead of staying constant. A single shift fixes a constant offset; a growing one needs the timing stretched, which is what syncing by two points does.
Sources
- ITU-R Recommendation BT.709-6 (picture rates of 60, 50, 30, 25 and 24 Hz, with the 60, 30 and 24 Hz rates also divided by 1.001)
- Microsoft Learn: AVEncVideoHeaderDropFrame (NTSC video at 29.97 fps against a 30 fps time code; frame numbers 00 and 01 skipped each minute except multiples of ten; no actual frames dropped)
- YouTube Help: Recommended upload encoding settings (upload at the recorded frame rate; common rates 24, 25, 30, 48, 50, 60; deinterlace 1080i60 to 1080p30; 1080p bitrate 8 Mbps standard and 12 Mbps high frame rate)
- W3C: GIF89a specification, Graphic Control Extension (Delay Time in hundredths of a second)