Compress MP4
Compression comes down to bitrate. Wave shrinks anything that comes in as an inefficient codec (WEBM, RMVB, MJPEG, ProRes) by re-encoding to H.264 during the MP4 conversion - typical drops of 10-20x. For MP4 already using H.264, a target-size compression pass is a HandBrake or ffmpeg job locally. This page covers both.
What actually changes
Compression works by lowering the video's bitrate - how many bits per second the encoder spends. File size is bitrate times duration, so cutting bitrate cuts size proportionally. The full formula, the CRF / CBR / VBR encoder-mode choice, and rule-of-thumb bitrates per resolution are in Video bitrate explained. Short version for a 5-minute 1080p MP4 that needs to fit 50 MB: target video bitrate around 1300 kbps.
Wave's current shrink path is codec substitution, not target-bitrate compression. When your source is WebM (VP9 + Opus), RMVB (RealVideo), Motion JPEG, MPEG-1/2, or ProRes, Wave re-encodes to H.264 during the MP4 conversion and the resulting file is typically 10-20x smaller than the source without any user-facing bitrate control - because those old or specialised codecs are 10-20x less efficient than modern H.264. When your source is already H.264 in an MP4, Wave's conversion is a remux (container-only rewrite - see Remux vs re-encode) that leaves the file size essentially unchanged. This page won't compress an already-efficient MP4 - a dedicated target-size UI is on the Wave roadmap, but not shipped.
For target-size compression today, HandBrake is the practical tool. It's a free desktop app with a "Constant Quality (RF)" slider for perceptual quality (RF 22 lands around 50-60% of source size at transparent quality; RF 24 around 30-40%; RF 28 around 15-25% with visible loss on complex content) or a Constant Bitrate mode with Two-Pass encoding when you need to hit an exact file size. Set Video Codec to H.264 (x264), pick RF or CBR, encode.
ffmpeg is the command-line alternative. Single-pass quality-target: `ffmpeg -i input.mp4 -c:v libx264 -crf 22 -c:a copy output.mp4`. Target-bitrate: `ffmpeg -i input.mp4 -c:v libx264 -b:v 1300k -c:a copy output.mp4`. For repeatable exact-size hits, two-pass: `ffmpeg -y -i input.mp4 -c:v libx264 -b:v 1300k -pass 1 -f null /dev/null && ffmpeg -i input.mp4 -c:v libx264 -b:v 1300k -pass 2 -c:a copy output.mp4`. Both produce the same MP4 container structure Wave writes.
Three steps.
-
01
Step 1
If your source is WebM, RMVB, MJPEG, or another inefficient codec, drop it onto Wave - the H.264 re-encode during the MP4 conversion shrinks the file dramatically (typically 10-20x).
-
02
Step 2
If your source is already H.264 in an MP4 and you need target-size compression, use HandBrake locally with the RF or bitrate math above.
-
03
Step 3
For the fast-start rewrite (a common upload-friendly requirement independent of file size), Wave adds that to every output automatically.
Answers, specifically.
Why can't Wave compress an H.264 MP4 directly?
Because a target-size UI is a real UX task that Wave hasn't shipped yet. The engine underneath (WebCodecs H.264 encoder) supports target-bitrate encode - what's missing is the "type in a target size, we compute the bitrate" step. It's on the roadmap. For today, the honest recommendation is HandBrake or ffmpeg locally.
What quality loss should I expect at typical compression targets?
At 50% of source size, effectively none (H.264 RF 20-22). At 25% of source size, occasional visible artefacts on high-motion content (RF 24-26). At 10% of source size, clear quality drop on any complex content (RF 28-30). For talking-head or static content, aggressive compression stays clean; for fast-motion sports or high-detail nature footage, aggressive compression falls apart.
Will compressing lose HDR / colour information?
It depends on the tool. HandBrake and ffmpeg preserve HDR metadata (Rec.2020, PQ or HLG transfer characteristics) through re-encode with the right flags. For HDR, use HandBrake's "Video → Colour Space → 10-bit" preset and check the HDR checkbox in the Video tab; for ffmpeg, add `-pix_fmt yuv420p10le -x264-params colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc` to the encode command.
How much smaller can I go before it looks bad?
The rule of thumb is 6 Mbps per megapixel per 30 fps for visually-transparent H.264. A 1080p60 clip has 2 megapixels x 2 (fps ratio) = 4 megapixel-seconds, so ~24 Mbps for perfect quality. Halving that (12 Mbps) still looks great. Quarter (6 Mbps) is fine for casual sharing. Eighth (3 Mbps) is watchable but shows compression on motion. Below that, quality collapses.
HEVC vs H.264 for compression - which should I target?
HEVC gives roughly 40% better compression than H.264 at equivalent visual quality. Trade-off: encoding is 2-3x slower than H.264, and playback compatibility is narrower (universal on modern devices, needs Extensions on Windows 10). For sharing to iPhone/Mac users and modern Android, HEVC is the better trade. For maximum compatibility, stay with H.264. HandBrake exposes both codecs; Wave's current re-encode path is H.264-only.
What about AV1 for even better compression?
AV1 is roughly 50% better than H.264 at equivalent quality but encoding is 10-40x slower without dedicated hardware. Hardware AV1 encoders (Intel Arc, AMD RDNA 3, NVIDIA Ada) started shipping in 2022 and are still not universal. For upload-once, decode-many workflows AV1 is worth the encode time; for casual compression H.264 or HEVC is faster and simpler.
How long does compression take?
Roughly real-time on modern hardware with hardware H.264 acceleration; slower without. A 30-minute 1080p compression to half-size on a modern MacBook takes 15-30 minutes with HandBrake's x264 preset. Hardware-accelerated encoders (VideoToolbox on Mac, NVENC on NVIDIA, Quick Sync on Intel) run 2-5x faster.