YouTube upload frame rate: keep the source rate, omit fps in Timeline

YouTube asks for the frame rate you recorded at. Sume Timeline matches the sources if output.fps is omitted; if set, it takes 24, 25, 30 or 60.

5 min readSume
All posts

Short answer

YouTube's upload encoding page says content should be encoded and uploaded at the same frame rate it was recorded. In Sume Timeline 1.0, leaving output.fps out makes the render match the sources; setting it accepts 24, 25, 30 or 60. If your clips share one rate, omit fps and you have followed the YouTube guidance without doing anything.

The risk is mixed footage. A 24 fps cinematic clip next to a 30 fps phone clip has no single recorded rate, so you have to choose, and the choice is yours rather than the platform's.

What each side documents

The YouTube page also lists container and codec preferences that apply no matter what frame rate you pick. The Sume column covers only what the Timeline docs state.

Frame rate and related upload settings (read 2026-10-03)
SettingYouTube guidanceSume Timeline 1.0
Frame rateSame as recordedoutput.fps omitted matches sources; 24, 25, 30 or 60
ContainerMP4, with the moov atom at the frontDefault output is an MP4
Video codecH.264Not stated in the Timeline doc
AudioAAC-LC or Opus, 48 kHzNot stated in the Timeline doc
Resolution (1080p vertical)1080p max for ShortsDefault 1080x1920; width and height even, 256-2160

Mixed-rate footage

When sources disagree, pick the rate that matches your delivery. For talking-head and screen content, 30 is usually enough. For motion-heavy sports or gameplay, 60 keeps the motion smooth, provided the original footage was captured at 60; upsampling a 30 fps clip to 60 does not add detail, it only duplicates frames.

Video Trim can conform a clip before you build the timeline. Its output block takes width, height and fps (24, 25, 30 or 60) and only works with precision exact, which re-encodes with libx264 at yuv420p. That costs $0.02 per job. For a handful of odd clips this is cheaper than rendering everything at the wrong rate.

  • Check each source with ffprobe before you assemble.
  • If all clips match, omit output.fps.
  • If they do not match, conform the odd ones with Video Trim output.fps, then render.

A pre-flight check

Use the unbilled plan endpoint, POST /v1/timeline-1.0/plan, to confirm duration and segment count before the paid render. It returns duration_seconds, segment_count, billable_minutes and estimated_cost_usd_micros, so you see the cost of a 3-minute Short or a longer upload before committing.

Remember that the rate for Timeline is $0.10 per rounded-up output minute, so a 61-second piece bills as two minutes. If you are near a minute boundary, trimming a few seconds of dead air can halve the bill.

Related reading

For the full Shorts assembly, see building a three-minute YouTube Short from clips. For the length history, see the Shorts three-minute dates.

Why matching the recorded rate matters

Frame rate conversion is where judder comes from. Converting 24 fps footage to 30 means either repeating frames unevenly or blending them, and both can show up as stutter in slow pans. Uploading at the recorded rate lets the platform's own transcodes start from clean timing. That is the reasoning behind YouTube's guidance, and it is a good default for any pipeline.

For AI-generated clips the question is subtler, because the generator picked the rate rather than a camera. Different video models return different frame rates. If you mix generated clips with your own footage, check each clip's real rate before deciding what the timeline should do. The Sume docs for Timeline state that omitting fps matches the sources, but they do not define what happens when sources disagree, so treat mixed rates as something to resolve yourself.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume