How to reduce video file size to fit an upload limit

To reduce a video's file size, re-encode it with fewer bits: a lower bitrate or quality setting, a smaller frame, a lower frame rate, a shorter length, or no audio track. A file's size is its average bitrate times its length, so each of these can make it smaller. Sume's editing tools take no bitrate, quality, or target-size field, so with Sume you trim the clip to a smaller frame, a lower frame rate, or a shorter range, or drop its audio, then check the new size_bytes with a free probe.

The facts come from the Video trim and Video inspect docs, the Sume API reference, and FFmpeg's ffmpeg and codecs documentation, read on 2026-09-27. Anything described as current behavior is read from Sume's code.

How do I get a video under a limit like 10 MB?

Work out the average bitrate the limit allows: the limit in bits divided by the length in seconds. Taking 10 MB as 10,000,000 bytes, a 60-second video can average 10,000,000 × 8 ÷ 60, about 1,333 kbps, for video and audio together. An encoder that takes a bitrate can aim at that number; FFmpeg's docs set a 64 kbit/s video bitrate with ffmpeg -i input.avi -b:v 64k -bufsize 64k output.mp4.

Sume can't aim at a size. Trim refuses crf, codec, and other ffmpeg fields, and its encoder targets a quality level, so you cut what the encoder has to carry and then measure the result.

Which Sume settings make a file smaller?

All of them are fields of POST /v1/video-trim, which reads your workspace's media.sume.com files, such as an earlier Sume job's output; which URLs each endpoint accepts explains the rule.

• Today, setting only height or only width keeps the aspect ratio; Change a video's frame rate or resolution covers the conform in detail.
• To shorten a clip without re-encoding it, use precision: "keyframe": a stream copy, so the kept part keeps its original bitrate. The cut may start a GOP early, and output is refused with it (video_trim_output_requires_exact).

curl -X POST https://api.sume.com/v1/video-trim \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: shrink-clip-720p30-001" \
  -d '{
    "video_url": "https://media.sume.com/artifacts/artf_demo/clip-4k60.mp4",
    "start": 0,
    "end": 60,
    "output": { "height": 720, "fps": 30 }
  }'

Why can the new file come out bigger?

Sume's encoders aim at a quality level, not a size. Today a trim encodes video with libx264 at CRF 18, which FFmpeg's docs describe as constant quality mode, and filters and Timeline renders use CRF 20; kept audio becomes AAC at 192 kbps. The bitrate follows the picture, so re-encoding a source that was already compressed hard, or whose audio was below 192 kbps, can produce a larger file than you started with.

How do I check the new size?

Run a free probe on the result: POST /v1/video-inspect with frames: false returns size_bytes and duration_seconds, and the average bitrate is size_bytes × 8 ÷ duration_seconds. If the file is still over the limit, trim the original again with a smaller frame or a lower frame rate. Trim never changes its source, so every attempt starts from the same file instead of re-encoding a re-encode.

• Trim reads sources up to 1,800 seconds and writes at most 900 seconds per job.
• Each trim is billed per job, plus a 5.5% agent fee by default; the docs say to confirm the rate in GET /v1/catalog. The probe is unbilled.