Fit a video under Discord's limit

How the planner works

Why a bitrate, not a magic button

Video size is almost entirely bitrate × duration. To land a clip under a hard cap, you pick a total bitrate so that bitrate × seconds ≈ target bytes, split between video and audio, with a little headroom for the container's own overhead. smallcord does exactly that math (the same planner that's unit-tested in this repo): it reserves 128 kbps for audio, keeps ~3% headroom for MP4 mux overhead, and reports the video bitrate that should land under your limit. If even the lowest watchable bitrate can't fit the clip's length into the cap, it says so plainly and suggests trimming, lowering resolution, or a bigger tier — instead of handing you a number that won't work.

Size target vs. quality target (CRF). The command above aims for a byte size: it picks a video bitrate so that bitrate × duration lands under your cap. Below it the result also offers a second, quality-target command built on x264's CRF (Constant Rate Factor) — -crf 23 by default. CRF holds a constant visual quality and lets the bitrate float scene by scene, so a still talk-show shot spends few bits and a busy pan spends more; that usually looks better per byte than a fixed bitrate. The honest catch: CRF does not target a file size. A lower CRF (say 18) means higher quality and a bigger file; a higher CRF (say 28) means a smaller, softer one — but neither promises a specific size, so the output can land over or under your limit. Reach for CRF when quality matters more than hitting an exact cap, and always check the finished file's size before you upload it.

Honest limits: this is a planning estimate, not a byte-exact promise. Real encoders hit a target average bitrate with tolerance, and how well a given clip compresses depends on its motion and detail — a static screen-share shrinks far more cleanly than fast gameplay. If a first pass lands slightly over, drop the video bitrate about 5% and re-run. The command uses H.264 (libx264) in an MP4, which Discord previews inline on every platform — unless you pick VP9/WebM in the compressor panel above, in which case the planner mirrors that choice: the command switches to -c:v libvpx-vp9 with Opus audio and a .webm output. VP9 typically fits the same visual quality into roughly 20–40% fewer bits than H.264, so the same byte cap buys a better-looking clip — the honest trade-off is that WebM inline playback varies by Discord client, so H.264/MP4 stays the default.

Tight fit? Use two-pass. The result block has a two-pass encode checkbox (single pass is the default). Two-pass runs ffmpeg twice with identical bitrate numbers: pass 1 analyzes the whole clip and writes only a stats log — its output goes to the null device (/dev/null on macOS/Linux, NUL on Windows — don't mix them up, the POSIX line pasted into Command Prompt creates a junk file literally named /dev/null) — then pass 2 encodes using that analysis. Because the encoder already knows where the hard-to-compress moments are, the average bitrate lands notably closer to the target: useful when your clip is only a little over the cap. The cost is roughly double the encode time, and even two-pass does not guarantee a byte-exact size — no encoder can. Pass 1 also leaves a small ffmpeg2pass-0.log file you can delete afterwards.

Downscaling the resolution. The result block has a Downscale resolution dropdown (Keep original, 720p, 480p). Pick 720p or 480p and the planner adds -vf scale=-2:720 (or -2:480) to every command it emits — single-pass, both passes of a two-pass run, and the downloadable .sh and .bat. The height is fixed; the -2 means "compute a width that keeps the aspect ratio and is an even number", because H.264 requires both dimensions to be even — a plain -1 can land on an odd width and make the encode fail. Be honest with yourself about what this does: lowering the resolution does not shrink the file on its own. The byte budget is still bitrate × duration and does not change with resolution, so at the same bitrate a 480p file is the same size as a 1080p one. What it changes is quality per bit: a lower resolution looks acceptable at a lower bitrate, so if the planner's bitrate for your clip looks too low to watch, downscaling makes that low bitrate usable — the lever you actually pull to fit is then a smaller target or a lower bitrate. It never guarantees a fit by itself.

Audio budget (keep stereo / mono / low / none). The compression panel at the top of this page has one audio control with four settings, and the bitrate it saves is handed straight to the picture. The arithmetic is simple: a byte limit is bitrate × duration, so a 2-minute clip aimed at the 10 MB free tier has about 678 kbps of total media bitrate to spend once ~3% is set aside for container overhead. A 128 kbps stereo track eats roughly 19% of that and leaves the video 550 kbps. Drop to 96 kbps mono and the video gets 582 kbps; 64 kbps mono gives it 614 kbps; removing sound entirely gives it the whole 678 kbps — about 23% more video bitrate for exactly the same file size. The live line under the chips shows the real number for your clip and target, and states the delta versus keeping stereo. If sound is the whole file — a voice memo, a song, a recorded call with no picture to pay for — then there is nothing to split: fit an audio file spends the entire budget on bitrate × duration, which is why a 12-minute 128 kbps stereo MP3 overshoots the 10 MB free tier by only about a tenth and just has to come down to ~113 kbps to fit. Two honest limits. First, when the target is tight enough that even 128 kbps stereo would starve the video below the watchable floor, the planner has already squeezed audio down to its 32 kbps minimum — so mono and low mono buy you nothing extra there (they still upgrade 32 kbps stereo to 32 kbps mono, which sounds better), and the readout says “no gain” rather than pretending otherwise. Second, the ffmpeg command below mirrors your audio choice exactly — -b:a 96k -ac 1, or -an for silence — but its -b:v is not re-planned, because the command planner sizes video against a fixed 128 kbps audio reserve. There, a cheaper audio setting makes the file land a little under your target instead of sharper. Only the in-browser encoder actually re-spends the reclaimed bytes on the picture.

Encoder preset (speed vs. efficiency). The result block has an Encoder preset dropdown offering the standard x264 preset names this page can honestly emit — veryfast, faster, fast, medium (the default), slow, and slower. Whichever you pick is substituted into -preset <name> in every command it emits — single-pass, both passes of a two-pass run, the CRF alternative, and the downloadable .sh and .bat. The preset controls how hard the encoder works: a slower preset searches more and fits the same target bitrate a little cleaner (fewer artifacts), while a faster one finishes sooner and leaves a bit of quality on the table. Be honest with yourself about what it does: a preset trades encode time for how efficiently the encoder hits the target bitrate — slower means a smaller-looking, cleaner result at the same size but a longer encode. It does not change the size estimate this planner shows: the byte budget is bitrate × duration and -b:v is identical whatever preset you choose, so the file still targets the same size — only the time it takes and how good it looks at that size change. medium is x264's own default and stays smallcord's default, so leaving the dropdown alone gives you the exact same command as before. (x264 also has ultrafast and veryslow extremes, left off deliberately: they give up too much quality or time to be worth recommending for a Discord upload.)

Trim to just the part you want. The single most effective way to fit a long recording under a hard cap is to not encode the whole thing. The Trim to a clip box takes a start and an end — type them as H:MM:SS, M:SS, or plain seconds, so 1:30 and 90 both mean the 90-second mark. When you set a range, smallcord adds -ss <start> -t <seconds> to the command right after the input file (both are placed after -i, so ffmpeg seeks frame-accurately on the re-encode rather than snapping to the nearest keyframe), and — this is the important part — it re-plans the bitrate for the shorter clip. A 6-minute gameplay clip that needs an unwatchable ~180 kbps to fit 10 MB becomes a 40-second highlight that fits comfortably at a much healthier bitrate, because the byte budget is bitrate × duration and you just cut the duration. The number the planner shows and the -t value in the command are always the same figure (end − start). Honest rules: the output contains only that span, nothing before or after; the end must come after the start and stay within the clip's length, and if it doesn't smallcord tells you plainly instead of silently swapping or trimming the values for you. Leave both boxes blank (the default) and the command is byte-for-byte the whole-clip one.