Trying to send a product demo video, the email attachment caps at 25 MB and the video's 80-something. Compress it — compress hard and it's a wall of macroblocks, the key UI actions unreadable; compress light and it's still over the cap. After a few rounds of tweaking parameters I realised the problem isn't "how much to compress", it's "how to allocate between size and quality".
The dumbest way is a flat bitrate: one rate for the whole video. But the content isn't uniform — a static UI screenshot is clear on almost no data; a fast-scrolling, rapidly-switching sequence turns to mush at the same rate. Flat either wastes bitrate on the static parts or starves the moving parts, losing both ways.
The right way allocates by content complexity. ImgIng samples before compressing: the start, middle, end and several representative spots, estimating texture density, average motion and change peaks, and from that sets a pre-encode budget — jointly planning resolution, frame rate, video bitrate, keyframe interval and audio budget. Rich-texture, fast-motion, frequent-cut segments get more data and shorter keyframe intervals; static frames shed wasted bitrate. Then it encodes with quality-first VBR. Same target size, but the data landed where the picture needs it — key content sharp, and what's saved was invisible anyway.
The distinction worth naming: flat rate is "encode, then check if the size is right"; content-aware is "set the budget before encoding". The former often takes several passes to hit a size; the latter lands in one, because it already capped the total budget under the source at estimate time — the output won't exceed the original, and when it's not worth it, it keeps the original in the same container or blocks a cross-container save.
For "how far is far enough", my bar is "is the key content legible", not a quality score. A demo needs the UI actions, text and flow clear, so keep the budget there; background, gradients and transitions can soften, nobody cares. Get that and you stop chasing "how do I compress this losslessly" — compression is lossy re-encoding, it can't be lossless; what it can do is put the loss where no one looks.
Another size lever people skip: resolution and frame rate. Bitrate allocation saves data at a given size, but if the target size is oversized to begin with, dropping resolution or frame rate a notch beats squeezing the bitrate — a 1080p60 recording at 720p30 sheds most of the size, and for demo content the loss is invisible. Shrink the dimensions first, then talk bitrate; the order saves a lot of effort.
Audio's the same: it defaults to AAC 128 kbps or Opus 96 kbps, perceptually close is enough, and the saved budget goes to the picture. The whole chain — container parse, decode, scale, encode, audio, save — runs locally, the video not uploaded, which also suits not wanting an unreleased demo to leave the machine.
So "fit under a size cap without mush" isn't achieved by trying compression ratios one after another, it's by allocating the limited size by content complexity. Same size — whoever spends the data in the right place wins on quality. Flat rate spreads the budget evenly; content-aware spends it where it counts. That's the whole difference. Tool is ImgIng (imging.ai).
Top comments (0)