Practical Bitrate for 4K and 720p Video

For 4K SDR, start H.264 at 20 to 35 Mbps for 24, 25 or 30 fps, and 35 to 55 Mbps for 50 or 60 fps. For HEVC or AV1, begin roughly 30 to 50 percent lower, then raise the bitrate if detailed motion produces visible compression.

These are working ranges, not delivery laws. A talking head against a fixed wall may look clean below them, while rain, foliage, smoke, confetti and handheld camera noise can turn the same bitrate into a pixelated mess.

Mbps means megabits per second. Multiply Mbps by 1,000 for the encoder field when it asks for kilobits per second: 25 Mbps becomes 25,000 Kbps.

The often-repeated setting 4K at 30fps: 35,000–45,000 Kbps is defensible for demanding H.264 footage, but wasteful for many static scenes and unusually high for efficient HEVC or AV1 encodes. Resolution alone cannot settle the number.

Use 18 to 30 Mbps for H.264 4K at 24 fps, or 10 to 20 Mbps for HEVC and AV1, as a practical starting point. Increase it for grain, rapid camera movement or HDR; reduce it only after checking the most complex scene at full size.

Twenty-four frames per second carries fewer frames than 30 or 60 fps, but the saving is not perfectly proportional. Encoders reuse information across frames, and the amount they can reuse depends on scene complexity, keyframe spacing and motion.

For a film export intended for later upload, constant quality encoding is usually more sensible than forcing a fixed average bitrate. In x264 or x265, use CRF mode and inspect the resulting file size. For a service that requires a target bitrate, use constrained variable bitrate or two-pass VBR so quiet shots do not consume the same data as action shots.

Do not remove natural film grain before a final check. Grain changes every frame and is expensive to encode. If preserving it matters, expect significantly higher bitrates and diminishing returns near the top of the range.

Raise the starting bitrate by about 40 to 60 percent when moving from 30 to 60 fps, and add roughly 15 to 25 percent for difficult HDR material. Fast motion, sensor noise and dense texture can justify another increase, while slides and static interviews can run lower.

Frame rate fps labels do not describe scene difficulty. A 60 fps screen recording with large flat areas may compress more easily than a noisy 24 fps night scene. Judge resolution and frame rate together, then account for what changes between frames.

• Sports, racing and fast games: start near the top of the range.
• Lectures, interviews and presentations: begin near the bottom.
• Snow, water, crowds, foliage and confetti: allow extra headroom.
• Grainy or noisy footage: denoise carefully or budget more data.
• HDR10: keep 10-bit output and check gradients, highlights and dark scenes.

HDR does not automatically require twice the bitrate. Its wider color volume and 10-bit precision can expose banding or block boundaries, particularly in shadows and gradients, but codec efficiency and the source still matter. For background on the formats rather than their bandwidth, see HDR10 and Dolby Vision differences.

Use the platform's current ingestion range first, then choose a value your connection can sustain with at least 30 percent upload headroom. For recorded uploads, preserve a high-quality master and let the streaming platform make its own viewer renditions.

Upload specifications and live ingest limits are different. A bitrate accepted for an uploaded file may be rejected by a live service, and limits can vary by codec, frame rate, account type and keyframe interval. Check the current encoder settings page for the destination before starting the final encode.

If you're streaming at 35 Mbps, do not treat a speed test reading of 36 Mbps as sufficient. Network conditions fluctuate, other devices transmit data and some internet connection plans have lower or less stable upstream capacity than downstream capacity.

1. Run several wired upload tests at the time you normally stream.
2. Take the lowest repeatable result, not the best result.
3. Reserve at least 30 percent for variation and audio.
4. Set the video bitrate below the remaining capacity.
5. Watch the encoder for dropped frames or network congestion.

Different platforms impose different ceilings, codecs and keyframe intervals. Platforms like Twitch may make 4K impractical even when the local encoder and connection can handle it. The service limit wins.

A practical bitrate for 720p is 2.5 to 5 Mbps for H.264 at 24 to 30 fps and 4 to 7.5 Mbps at 50 to 60 fps. HEVC or AV1 can often deliver comparable video quality at 1.5 to 3.5 Mbps for 30 fps, though device and platform support may dictate H.264.

Use the lower end for meetings, lectures and fixed-camera speech. Use the upper end for games, sports or footage with frequent cuts. Below roughly 2 Mbps, detailed 720p H.264 can become a lower-quality stream with obvious macroblocking, even though the resolution frame remains 1280 by 720.

720p is still useful when live streaming requires reliability more than sharpness. A clean 720p stream that reaches viewers continuously gives a better viewing experience than unstable 4K with dropped frames.

Do not spend the entire network budget on video. Allow approximately 128 to 320 Kbps for audio, plus upload headroom. Streaming requires predictable delivery, not merely a high average result from one speed test.

Use CBR for live streaming, constrained VBR when a delivery system permits variation, and CRF or constant quality for local files. Use two-pass VBR when you must hit a specific file size or average bitrate and have time for a second encoding pass.

• CBR: Keeps output near a fixed rate. It is easy for streaming platforms and networks to budget, but quality changes as scene complexity changes.
• VBR: Moves data toward difficult scenes and away from simple ones. A maximum bitrate prevents bursts from exceeding delivery limits.
• CRF or constant quality: Targets visual quality and lets file size vary. It is a strong default for archives and upload masters.
• Two-pass VBR: Examines the complete program before allocating data. It helps when a 60-minute file must fit a known storage or transfer limit.

CBR is not literally constant at every instant. Encoders use buffers, and short-term output can vary around the target. FFmpeg exposes codec-specific quality, bitrate, buffer and pass controls through the options documented in its codec configuration reference↗.

Avoid confusing an encoder preset with bitrate. A slower preset spends more computation finding efficient predictions. It may improve quality at the same bitrate, but it does not automatically change the configured data rate.

Encode the hardest 30 to 60 seconds at three nearby bitrates, then compare the results at normal viewing distance and at 100 percent scale. Choose the lowest setting that keeps motion, gradients, faces and fine texture free of objectionable compression artifacts.

1. Cut a representative sample containing motion, darkness and detailed texture.
2. Keep codec, profile, preset, frame rate, keyframe interval and audio settings identical.
3. Encode at the low, middle and high points of the proposed range.
4. Compare the same frames and moving passages, not three different scenes.
5. Check blocking, mosquito noise, banding, lost grain and smeared texture.
6. Confirm file size or live upload use against the actual limit.
7. Move the range upward only if the middle encode visibly fails.

Do not inspect only a paused frame. Temporal pumping, trails behind moving objects and momentary pixelation appear during playback. Also test on the display that matters. A defect hidden on a phone may be plain on a 65-inch television.

For an objective second opinion, VMAF compares a compressed encode with a reference and produces a quality score. Netflix publishes the VMAF implementation and model details↗, but the score should support visual inspection rather than replace it.

If all three encodes look the same, keep the smaller one. That is diminishing returns made visible.

Multiply the total bitrate in Mbps by duration in seconds, then divide by eight to estimate megabytes. Add audio before calculating, and allow a few percent for container overhead.

A 20 Mbps video with 0.192 Mbps audio running for 10 minutes is approximately 1,514 MB before minor overhead:

For a one-hour program at 35 Mbps video plus 0.320 Mbps audio, the estimate is about 15.9 GB using decimal units. This arithmetic describes the amount of data processed, not the visual quality.

For live work, convert the requirement into sustained upload load and then add safety margin. A nominal 20 Mbps stream should have roughly 29 Mbps of dependable upload capacity if reserving 30 percent of the connection. For more combinations, use the video bitrate calculator.