Frame rate — 24, 30, 60 fps and the fractional rates that broke video

Frame rate is how many frames per second your video plays. It sounds simple, but it's actually one of the messiest topics in video — riddled with fractional rates that exist because of 1950s NTSC television, frame-rate conversion algorithms that introduce artifacts, and ongoing debates about high-frame-rate cinema. The frame rate decisions you make at capture, edit, and delivery affect file size, encoder behavior, motion appearance, and downstream compatibility. This page is the engineering reference.

#What frame rate is

Frame rate is the number of distinct still images (frames) shown per second of playback. The unit is "fps" (frames per second) or "Hz" when discussing display refresh.

Common video frame rates and their origins:

• 23.976 fps — NTSC film. The fractional rate exists for NTSC color compatibility (more below).
• 24 fps — cinema standard since the 1920s. The original "movie" frame rate.
• 25 fps — PAL TV standard (Europe, Asia, Australia). Half of 50 Hz mains frequency.
• 29.97 fps — NTSC TV standard (US, Japan, parts of Latin America). The 30 fps equivalent with NTSC's color subcarrier offset.
• 30 fps — common for digital video, gaming captures, modern web video.
• 50 fps — PAL high-frame-rate broadcast.
• 59.94 fps — NTSC high-frame-rate broadcast. Same color-subcarrier offset that gives us 29.97.
• 60 fps — common for gaming, sports streaming, smooth motion targets.
• 100 fps, 120 fps — high-frame-rate sports, slow-motion source for normal-rate output.
• 240 fps, 300 fps — extreme slow-motion source.

Different content uses different frame rates. Cinema is 24/23.976. Broadcast TV is 25/50 (PAL regions) or 29.97/59.94 (NTSC regions). Sports is often 50/59.94/60. Gaming is typically 30 or 60. Web video varies; YouTube serves 24, 25, 30, 48, 50, 60 fps content.

#The NTSC fractional rate disaster

23.976, 29.97, 59.94 — these fractional rates exist because of a 1953 decision to make NTSC color TV backward-compatible with NTSC black-and-white TV.

Original NTSC black-and-white was 30 fps (technically 60 fields/sec interlaced; more on interlacing later). When color was added in 1953, the engineers needed to interleave a color subcarrier signal at 3.579545 MHz that wouldn't interfere with the existing audio carrier at 4.5 MHz. The math worked out best if the frame rate was reduced by a factor of 1000/1001:

• 30 × (1000/1001) = 29.97002997...
• 60 × (1000/1001) = 59.94005994...
• 24 × (1000/1001) = 23.976023976... (used for film transferred to NTSC video via telecine)

This decision propagated through every NTSC color TV from 1953 onward, into VHS and DVD, into early digital video, and into the streaming ecosystem. Every frame rate calculation that touches NTSC content has to handle 29.97 and 59.94 explicitly.

PAL (1967, Europe) didn't make the same compromise — PAL color uses 25 fps (50 Hz fields) cleanly. PAL regions don't have fractional-rate problems for native PAL content.

For 2026 streaming pipelines, the legacy lives on:

• US/Japan-origin content tends to be 23.976 or 29.97 or 59.94.
• Europe/Asia-origin content tends to be 25 or 50.
• Modern digital content increasingly uses clean 24, 30, 60.

When pipelines mix frame rates (which they often do — content from multiple regions in one streaming catalog), the conversion problem appears.

#Frame rate conversion

Converting between frame rates requires generating frames that don't exist in the source. Several algorithms:

Simple frame duplication / dropping — duplicate frames to slow down, drop frames to speed up. Cheap but produces visible judder. The classic NTSC-to-PAL pulldown does this.

3:2 pulldown (telecine) — converts 24 fps film to 29.97 fps NTSC video. Each pair of source frames becomes 5 NTSC fields with a specific repeating pattern. The reverse operation (3:2 inverse telecine) is well-known but error-prone.

Frame blending — average adjacent frames to produce intermediate frames. Smoother than duplication but blurs motion.

Optical flow / motion compensation — analyze motion between frames and synthesize intermediate frames using motion estimation. Best quality; most expensive. Used by SVP, Topaz Video AI, and similar consumer tools.

Optical flow with deep learning — modern approach (2020+). Neural networks trained on motion synthesis produce remarkably good results. Industry-grade implementations: Twixtor, RIFE, DAIN.

For pipeline operations, frame rate conversion happens at the encoder stage:

ffmpeg -i input_24fps.mp4 -filter:v "fps=fps=30:round=near" output_30fps.mp4

The fps filter with round=near does simple frame duplication/dropping. For higher quality:

ffmpeg -i input.mp4 -filter:v "minterpolate=fps=60:mi_mode=mci:mc_mode=aobmc" output.mp4

minterpolate (motion interpolation) does optical flow-based frame synthesis. Slow but produces smooth output.

#VFR vs CFR

Constant Frame Rate (CFR) means every frame has equal time duration. Variable Frame Rate (VFR) means frame durations vary throughout the video.

CFR is what most production content uses. Streaming, broadcast, cinema — all CFR. The encoder produces frames at fixed intervals; the player displays them at fixed intervals.

VFR appears in:

• Screen recording — software grabs frames when content changes; static periods produce fewer frames per second.
• Gaming captures — game frame rate varies; capture preserves the variance.
• Some camera output — when frame rate adapts to lighting (drop frames when light is low to allow longer exposure).

VFR is operationally awkward. Many tools assume CFR; VFR can cause:

• Audio sync drift over time.
• Edit point misalignment.
• ABR streaming issues (segments don't have predictable frame counts).

For streaming pipelines, convert VFR to CFR at ingest. The first stage of any VFR-tolerant pipeline is -vsync cfr or fps=N filter:

ffmpeg -i vfr_input.mp4 -vf "fps=30" -c:v libx264 cfr_output.mp4

Producing CFR output normalizes downstream behavior. The cost is ~zero — the conversion is straightforward when you commit to a target rate.

#Frame rate and encoding

Frame rate affects encoder configuration:

GOP scaling — GOP duration is in seconds, but encoders typically configure GOP in frames. For 2-second GOP at 30 fps, set -g 60; at 60 fps, set -g 120. Get this wrong and segment boundaries don't align with GOP boundaries.

Bitrate scaling — bitrate budget per frame is bitrate ÷ fps. Higher frame rate at the same bitrate means fewer bits per frame; either bitrate increases or per-frame quality drops. For 60 fps content vs 30 fps content at equivalent quality, expect 30-50% higher bitrate.

Encoder presets — encoder presets are tuned at common frame rates. Performance characteristics may differ at unusual rates. Test before committing to non-standard rates.

B-frame and reference structures — generally framerate-agnostic, but extreme frame rates (240 fps+) may stress encoder reference buffers.

#Display refresh rate vs content frame rate

Display refresh rate is the rate at which a display physically updates its image. Common values: 60 Hz (most consumer displays), 120 Hz (gaming displays, some TVs), 144 Hz (gaming displays), 240 Hz (high-end gaming), 24 Hz (some cinema-mode TVs).

When content frame rate doesn't match display refresh rate, the player has to handle the mismatch:

• Frame doubling — show each frame twice (24 fps content on 48 Hz display).
• Frame interpolation — synthesize intermediate frames (smart TVs do this for 24 fps cinema content; the result is "the soap opera effect" most viewers find off-putting).
• 3:2 pulldown — for 24 fps on 60 Hz, alternate showing each frame for 3 refreshes then 2 refreshes. Causes judder.

Modern TVs and monitors increasingly support variable refresh rate (VRR, FreeSync, G-Sync) — the display refresh rate matches the content frame rate dynamically. For high-end gaming and cinema-mode playback, this eliminates judder.

For streaming, the player handles refresh-rate matching. Producers ship content at the correct frame rate; players adapt to display.

#Frame rate in HDR and HFR

HFR (High Frame Rate) cinema attempts to show feature films at 48, 60, 96, or 120 fps instead of 24 fps. The Hobbit (2012) shipped at 48 fps; Gemini Man (2019) at 120 fps. Audience reaction was mixed — HFR makes motion smoother but breaks the "cinematic look" associated with 24 fps judder.

For HDR streaming, frame rate is independent of HDR — content can be HDR at 24, 30, 60 fps, etc. Most premium HDR streaming is 24 fps (cinema content) or 60 fps (sports). The combination of HDR + HFR + 4K is bandwidth-expensive but produces the most spectacular streaming output for compatible displays.

#Detection and signaling

Frame rate is signaled in container metadata. ffprobe extracts it:

ffprobe -v error -select_streams v:0 -show_entries stream=avg_frame_rate,r_frame_rate input.mp4

The avg_frame_rate is the average across the file (relevant for VFR); r_frame_rate is the declared "real" rate. For CFR content, they're equal. For VFR, they differ.

Signaling at the codec level:

• MPEG-TS — frame rate in PES headers.
• MP4 — mvhd and mdhd boxes carry timescale and duration; frame rate is computed.
• H.264 / HEVC — VUI fields carry frame rate.
• AV1 — OBU sequence header has timing info.

For correct downstream handling, signaling must be accurate. Tools that strip metadata or set defaults can produce content with wrong frame rate signaling, causing playback issues.

#Frame rate ladder design

For ABR streaming, frame rate per ladder rung typically matches the source. Don't down-rate frame rate per tier; that introduces motion artifacts that shouldn't exist.

Some pipelines DO use frame-rate adaptation as an ABR tier — e.g., 60 fps top tier and 30 fps mid tier from a 60 fps source. The motivation is bitrate efficiency at lower bandwidths. The cost is motion-quality regression at the lower tier; viewers may notice.

For most premium streaming, all ABR rungs share the source frame rate. Bitrate adaptation handles bandwidth variance; frame rate stays consistent.

#Operational considerations

Things that matter for frame rate in production:

• Source frame rate detection — first stage of pipeline. Use ffprobe; verify the value before downstream processing.
• VFR-to-CFR conversion at ingest — normalize early to avoid downstream issues.
• GOP-to-frame-rate alignment — -g value scales with frame rate. Verify after configuration changes.
• Audio sync verification — frame rate changes can introduce audio sync drift if not handled correctly. Test after pipeline changes.
• Rounding behavior — 23.976 vs 24, 29.97 vs 30 — these aren't the same rate. Mistreating one as the other produces 0.1% drift over time. Audible on long content.
• Inverse telecine for 24-from-29.97 source — film content stored as 29.97 fps via 3:2 pulldown should be inverse-telecined back to 24 fps for streaming. The inverse pulldown saves bandwidth and produces cleaner output.

#What MpegFlow does with frame rate

MpegFlow's DAG runtime detects source frame rate via an FfprobeExecutor stage upstream of encode. Cross-stage data flow wires the probe output into the downstream FfmpegExecutor rendition stages so GOP scaling, bitrate budgeting, and segment-duration computation derive from the real source rate rather than assumed defaults. The partitioner persists each stage to job_stages with explicit dependency tracking; per-stage retry handles transient failures.

VFR sources are normalized to CFR at the encode stage by default through the appropriate FfmpegExecutor flags. Customers with specific VFR requirements (rare in streaming workflows) configure VFR-passthrough explicitly per workflow.

For ABR ladders, the default behavior preserves source frame rate across all parallel rendition stages — the partitioner emits the same frame-rate parameter across the rungs from one shared workflow value. Customers who want frame-rate-adapted ladders configure per-rung overrides.

For frame-rate conversion when needed (e.g., 50 fps PAL source to 30 fps streaming, or 23.976 NTSC film to 25 fps PAL distribution), the conversion runs at the FfmpegExecutor stage with the algorithm chosen via filter parameters; the conversion choice affects output quality and per-stage compute time.

The strict-broker security model handles frame-rate work like any pipeline payload — workers carry no ambient credentials; content access flows through short-lived presigned URLs scoped per stage; access is disposed on completion.

For customers building pipelines that mix content from multiple regions (US 23.976/29.97 + Europe 25/50 + global digital 24/30/60), the frame-rate strategy is part of the early pipeline design conversation. Common patterns: convert all content to a common target frame rate at ingest (typically 30 or 60), or preserve native frame rates per asset and adapt downstream. Both work; the choice depends on operational simplicity vs source preservation priorities.

The general guidance: detect frame rate accurately, normalize VFR to CFR at ingest, scale GOP to match frame rate, and handle the NTSC fractional rates explicitly rather than hoping rounding doesn't bite. Frame rate handling is one of the parts of video engineering that's easy to get superficially right and hard to get fundamentally right.