YouTube 1080p at 60 fps: a 3-minute Short is 270 MB, not 180

At YouTube's recommended SDR rates, a 1080p video at 24 to 30 fps is 8 Mbps and at 48 to 60 fps is 12 Mbps. Over 180 seconds that is 8 x 180 / 8 = 180 MB versus 12 x 180 / 8 = 270 MB, a difference of 90 MB for the same picture size. On Sume, a 180-second render is 3 billable minutes either way, $0.30, so the frame rate changes the file and not the price.

The numbers are from YouTube's recommended upload encoding settings (read 2026-10-09). The same page says to upload at the frame rate the content was recorded in, and lists 24, 25, 30, 48, 50 and 60 as the common ones.

The ladder

The page gives bitrates per resolution for standard and high frame rates. Arithmetic below assumes a constant rate for 180 seconds; real files vary.

What Sume's output.fps does and does not do

Timeline 1.0 accepts output.fps of 24, 25, 30 or 60. If you omit it, the render uses the rate of the sources. If you set a rate different from a source's, the job repeats or drops a frame every few frames, which causes judder, and the job reports output_fps_resamples_sources. Rendering 30 fps footage at 60 therefore gives a 60 fps file whose frames repeat; it is not high frame rate motion.

So set 60 only when your clips were captured or generated at 60. For 50 or 48 fps sources, Sume's list has no matching value; omit output.fps so the render follows the source, as the Timeline doc describes. YouTube's own advice, record and upload in the same rate, is the safer rule.

Cost of getting it wrong

Rendering 30 fps footage at 60 and uploading it gives you the larger file with no gain. Using the table, that is 90 MB more per 180 seconds at 1080p, and 180 MB more at 1440p, for repeated frames. If you are shipping a series of 40 Shorts, the extra upload is 3.6 GB at 1080p. Check the source rate first with a probe: video inspect with frames set to false returns only the probe, so you can read the source facts without paying for stills.

The reverse mistake is also real. A 60 fps source rendered at 30 drops every second frame and loses smoothness. The Timeline doc says that mismatched rates cause judder and warns with output_fps_resamples_sources, so read warnings[] after each render rather than assuming the file matches the plan.

Short or long

A vertical 1080x1920 Short uses the same bitrate table by resolution as far as the page states, but the page does not say how it applies to a 9:16 frame, so treat the table as a guide. Sume's default output is 1080x1920. For a long-form 16:9 video, set width 1920 and height 1080, each even and inside 256 to 2160.

Sume gives no bitrate control. The server compiles ffmpeg and refuses codec, crf and bitrate-style keys. The file you receive is a function of the content and the render; check its size and compare with the 270 MB estimate before you rely on it, especially for long videos where the sum approaches your upload limit.