60 fps 3-minute YouTube Short: 12 Mbps is 270 MB vs 180 MB at 30 fps

A 3-minute Short at YouTube's 12 Mbps 60 fps rate is about 270 MB, against 180 MB at 8 Mbps. Work out the sizes, and when Sume should not render 60 fps.

5 min readSume
All posts

Short answer

At YouTube's recommended 1080p rate for 48 to 60 fps SDR video, 12 Mbps, a 180-second Short comes to about 270 MB, plus about 8.6 MB of audio. The same Short at 24 to 30 fps and 8 Mbps is about 180 MB. Only render 60 fps in Sume when your source is already 60 fps.

Where the numbers come from

YouTube's upload encoding page lists recommended SDR bitrates for 1080p: 8 Mbps at 24 to 30 fps and 12 Mbps at 48 to 60 fps. It lists 384 kbps for stereo audio (read 2026-10-05). The Shorts help page says a Short can run up to 3 minutes if it is square or vertical, so 180 seconds is the ceiling for this arithmetic (read 2026-10-05).

The sizes below use decimal megabytes: megabits per second times seconds, divided by 8. They are planning estimates for the recommended rates, not a prediction of a particular encode. Sume has no bitrate field (the trim and timeline routes refuse codec and crf keys), so the table tells you what to expect when you upload, not something you set.

File size at 180 seconds

3-minute 1080p Short sizes from YouTube's recommended bitrates, read 2026-10-05
Frame rateVideo bitrateVideo MB (180 s)Audio MB (384 kbps)Total MB
24 to 30 fps8 Mbps180.008.64188.64
48 to 60 fps12 Mbps270.008.64278.64

When 60 fps is worth it

The extra 90 MB buys smoothness only if the frames exist. When you pick an output fps that differs from a source's rate, Timeline 1.0 repeats or drops a frame every few frames and returns a warning named output_fps_resamples_sources with the rate the sources wanted. A 30 fps phone clip rendered at 60 does not become smooth. It becomes a bigger file with the same motion and a judder risk.

If you omit output.fps, the job renders at the rate of the sources, where the longest video sources decide. That is the safe choice for a mixed set: it keeps a 60 fps screen recording at 60 and a 30 fps talking head at 30. Set 60 explicitly only when every video slot is 60 fps. The allowed values are 24, 25, 30 and 60.

Render and price

Timeline 1.0 outputs 1080x1920 by default, and the render is priced at $0.10 per ceil(output minute), so 180 seconds is 3 minutes and $0.30 whatever the frame rate. Frame rate changes your upload size, not the Sume rate. Run the unbilled plan call first to see billable_minutes, then render with an Idempotency-Key header. The timeline docs list every field.

A practical rule for a batch: pick the frame rate once per series, from the lowest-rate source you will use, and omit output.fps so each render follows its inputs. Then budget upload size from the 8 Mbps row for ordinary footage and from the 12 Mbps row only for the episodes that are truly 60 fps. For a 12-episode season of 180-second Shorts that is 12 x 188.64 = 2,263.68 MB at the lower rate against 12 x 278.64 = 3,343.68 MB at the higher one, a difference of 1,080 MB.

None of these figures come from a measured encode. They are the arithmetic of YouTube's published recommendations, and a real file can come out smaller or larger. Treat them as a way to catch a surprise before you start an upload, then check the actual size of the render.

def size_mb(mbps, seconds=180, audio_kbps=384):
    video = mbps * seconds / 8
    audio = audio_kbps / 1000 * seconds / 8
    return round(video, 2), round(audio, 2), round(video + audio, 2)

for label, mbps in (("30 fps", 8), ("60 fps", 12)):
    print(label, size_mb(mbps))

Sources

Related posts

More in Media tools

All Media tools posts

Written by Sume