Mux direct upload chunks: multiples of 256 KB, UpChunk at ~5 MB
Mux direct uploads need chunks in multiples of 256 KB; UpChunk sends about 5 MB. A chunk-size helper and the upload states to wait on before using an asset.

If you stream a file to a Mux direct upload yourself instead of using a client library, each chunk must be a multiple of 256 KB. Mux's UpChunk library uploads in about 5 MB pieces, and the page's streaming example uses 8 MB. The docs do not state a maximum file size, so do not plan around a number we cannot cite. The helper below snaps any target chunk size to the 256 KB rule.
Facts from the Mux page
| Item | What the page says |
|---|---|
| Chunk rule | Multiples of 256 KB |
| UpChunk | Uploads in about 5 MB chunks |
| Streaming example | 8 MB chunks |
cors_origin | A domain, or * for any |
new_asset_settings | Includes playback_policy, video_quality, passthrough |
| Upload states | waiting_for_upload, ready, cancelled_upload |
| Events | video.upload.asset_created, video.asset.created, video.asset.ready, video.upload.cancelled |
A chunk-size helper
UNIT = 256 * 1024
def chunk_size(target_bytes):
if target_bytes < UNIT:
raise ValueError("chunk must be at least 256 KB")
return (target_bytes // UNIT) * UNIT
def plan(total, target=8 * 1024 * 1024):
size = chunk_size(target)
return [(i, min(i + size, total) - 1) for i in range(0, total, size)]
print(chunk_size(5_000_000))
print(plan(20 * 1024 * 1024))
Wait on the right event
An upload is not an asset you can play. After the last chunk, wait for video.asset.ready before you link the video anywhere. The passthrough setting lets you tag the upload with your own id; if the file came from Sume, put the job id there so the Mux asset traces back to the render that made it.
Preparing the file
A smaller input means fewer chunks and a faster ready event. Video trim cuts a range ($0.02 per job; output up to 900 seconds) and, in exact mode, conforms width, height (256 to 2160) and fps (24, 25, 30 or 60). Probe the result with video inspect for probe.size_bytes before you plan the chunks.
Retry behaviour
Chunked uploads fail in the middle more often than whole-file ones, so plan to resend a single chunk rather than the file. Keep the plan list from the helper, record the index of the last accepted chunk, and resume from there. The page documents a cancelled state, so if your user abandons the upload, let the upload end in cancelled_upload instead of leaving it waiting. Remember that the asset only exists after the first asset event, so do not store a playback id before then.
Limits
The helper only handles the chunk rule. It does not do the HTTP Content-Range bookkeeping, retries, or the creation of the upload URL, all of which Mux documents elsewhere. Sume has no bitrate or codec field, so file size is steered only by length and frame size.
Sources
Related posts
More in Developers
- Netflix subtitle limit: 42 characters per line, and max_chars
Netflix's English timed text spec allows 42 characters per line and two lines. Sume's caption design.phrasing.max_chars accepts 4 to 60, so 42 fits.
- Subtitle reading speed: check 20 characters per second before burning
Netflix caps English subtitles at 20 characters per second for adults, 17 for children. Check each cue's rate in a short script before a Sume caption render.
- NEXT_PUBLIC_ plus a Sume API key: why it ships to the browser
A NEXT_PUBLIC_ prefix inlines the value into client JavaScript at build time. Keep the Sume API key server-side, proxy via a route handler, rotate if it leaked.
- Poll a Sume job with AbortSignal.any in Node 26.10
Node 26.10.0 fixes AbortSignal.any() propagation. Here is a Sume job poll loop with a hard deadline and a caller cancel, using next_poll_after_seconds.
Written by Sume