Render 60-second data explainer: R, MP4 under 10 MB, Constant Rate Factor (CRF) 23 vs 28

For a 60-second R-generated data explainer, CRF 28 with a maxrate cap reliably keeps a 1080p MP4 under 10 MB while maintaining legible chart text.

Use CRF 23 only if a frame-level check confirms that axis labels are unreadable at CRF 28.

Why 10 MB Sets Your Bitrate Math

A 10 MB file-size ceiling is not an abstract target; it translates directly into a fixed per-second bitrate budget for a 60-second clip. The arithmetic is straightforward: 10 megabytes × 8 bits per byte = 80 megabits of total data. Dividing that total by 60 seconds yields an average bitrate ceiling of about 1.33 Mbps (80 ÷ 60 = 1.333…) for the entire file, including both video and audio streams.

Once a 128 kbps audio track is accounted for, the video stream must live within roughly 1.1–1.2 Mbps on average. This is a hard mathematical constraint: any sustained overshoot in video bitrate will consume the margin reserved for audio or push the final file past the ceiling, regardless of how sharp individual frames appear in isolation.

That constraint exposes a key limitation of constant rate factor (CRF) encoding. CRF targets a consistent level of visual quality, not a predictable file size, so a CRF-only encode offers no guarantee that the output will land under 10 MB. To enforce the ceiling, the encoder must be given an explicit size boundary, either through a bitrate cap (such as maxrate and bufsize) or through a two-pass encode aimed at a calculated bitrate target.

Before treating 10 MB as a fixed number, confirm how your delivery platform defines it. Some systems count a megabyte as 10⁶ bytes (10,000,000 bytes), while others use 2²⁰ bytes (10,485,760 bytes). Check the platform’s upload documentation or test with a known file, then verify the exported MP4 against that exact byte limit so the arithmetic you planned against matches the gate your file must pass.

What CRF 23 vs 28 Actually Changes

CRF is a quality target rather than a size target: lower values generally preserve more detail, while higher values allow more compression. The comparison here is between CRF 23 and CRF 28 at the same 1920x1080 frame size; because CRF alone does not guarantee a byte ceiling, verify any quality/size trade-off by encoding a short representative slice at each setting and checking both the reported bitrate and label legibility.

That trade-off is governed by how much novel detail each frame contains. H.264 compression is most efficient when large regions stay uniform or repeat from frame to frame, because the encoder can represent them with very little data. Data explainers typically feature flat color fields, static axes, simple shapes, and limited motion, all of which create low spatial and temporal complexity. Even when text and line art introduce sharp edges, those elements are predictable and occupy a small fraction of the frame, so they remain stable at lower bitrates.

NoTriangle Studio's November 2025 render-resolution guide focuses on resolution as total pixel count and cautions against defaulting to the highest possible value; it does not establish a detail-density-to-bitrate rule for charts. Treat the flat-background compression advantage as a hypothesis to test: encode a short representative slice at the chosen settings and inspect small axis labels at full resolution before accepting the full render.

For a 60-second, 1080p data explainer, this compression advantage is what makes CRF 28 a practical starting point: the encoder can meet a tight size target without the kind of texture breakdown that plagues photographic content. The elements most at risk are thin axis labels, tick marks, and small annotations, not the broad areas of color that dominate the frame.

Before accepting the output, perform a frame-level inspection of the exported MP4 at full resolution. Zoom in on the smallest axis labels and data annotations and check for blurring, ringing, or broken strokes. If every label remains legible, CRF 28 has preserved the information that matters; if any text becomes unreadable, that specific failure is the signal to re-encode at CRF 23.

CRF 23 vs 28 vs Two-Pass Compared

When a 60-second R-generated data explainer must fit under a 10 MB ceiling, the encoding choice is a trade-off among three things: guaranteed compliance with the file-size limit, legibility of chart text at 1080p, and the time spent encoding. Comparing CRF 23 alone, CRF 28 with a bitrate cap, and two-pass encoding against those criteria produces a clear winner for most standard explainers.

CRF 23 alone delivers the best per-frame quality, but it offers no size guarantee. A busy 60-second animation with frequent transitions, dense grids, or rapid label changes can push the output past 10 MB, which means it fails the primary constraint even if individual frames look excellent. For any workflow where the file must upload or attach without exception, unconstrained CRF 23 is the wrong default.

CRF 28 combined with maxrate 1.2M and bufsize 2.4M wins for standard explainers because it completes in a single pass, keeps the file size predictable, and leaves typical flat chart graphics well within the available budget. This setting enforces the ceiling while preserving enough detail for axes, tick marks, and annotations to remain readable at 1080p in ordinary data-visualization scenes.

Two-pass encoding at 1.2 Mbps earns its place only in a narrow case: CRF 28 visibly degrades text and you must still guarantee the final size. Because it requires two full passes over the source, it doubles encode time. To verify whether that cost is justified, run both CRF 28 capped and two-pass on one representative 10-second segment, then compare tick-label sharpness frame by frame at full resolution before committing to the longer encode.

Use this rule to decide quickly: start with CRF 28 plus the bitrate cap, confirm the output is under the limit and the labels are legible, and escalate to two-pass only when that visual check fails. This keeps the default fast and compliant while reserving the slower method for the cases that actually need it.

Numbers That Matter Before You Encode

Before you touch an encoder flag, lock the parameter block the rest of the pipeline inherits: the reader rule specifies 1920x1080, and the byte budget uses a 60-second duration. Arktek3D's January 2026 and NoTriangle Studio's November 2025 resolution guides focus on choosing pixel dimensions for the deliverable; they do not establish a frame rate or a universal bitrate ceiling. Test any frame-rate choice against the byte limit and label legibility before committing the full render.

The budget split is what makes these numbers hold together for a 10,000,000-byte deliverable: allocate roughly 1.20 Mbps to video and 128 kbps to AAC audio, for a combined ~1.328 Mbps stream. Over 60 seconds that yields about 79.68 megabits, or roughly 9.96 MB, which leaves almost no container or muxing overhead. Treat 9.5 MB as the working target so routine fluctuations in encoder output do not push the final file over the limit.

Verification is a required step, not a formality. After encoding, confirm the exact on-disk size with ls -l output.mp4 on macOS or Linux, or check file properties in your system’s file manager on Windows. For a stream-level check, run ffprobe -v error -show_format output.mp4 and confirm the reported bit rate and duration align with the inherited budget before you share the file.

Carrying this parameter block forward keeps every downstream decision consistent: the resolution and frame rate define the pixel workload, the audio rate fixes a non-negotiable slice of the budget, and the byte thresholds give you an unambiguous pass/fail check. If the verified file exceeds 10,485,760 bytes, adjust encoding settings within this same frame size and duration rather than revisiting the arithmetic established earlier in the pipeline.

Where the CRF 28 Rule Breaks

CRF 28 is the default for this pipeline because flat chart backgrounds compress cleanly, but three content patterns can break that assumption. The table below separates the cases where CRF 28 still wins from the cases that need CRF 23 or a two-pass encode.

Frequently Asked Questions

What is the average bitrate budget for a 60-second video to stay under 10 MB?

A 60-second clip must stay within an average bitrate ceiling of about 1.33 Mbps for the entire file, including both video and audio streams.

What is the total bit budget for a 10 MB file?

A 10 MB file-size ceiling translates to a total bit budget of 80 megabits (10 MB × 8 bits per byte).

What H.264 encoder settings help keep a 60-second explainer under the 10 MB limit?

Encoding with CRF 28, maxrate 1.2M, and bufsize 2.4M reliably keeps the file under the ~1.33 Mbps budget while preserving chart text legibility.

What is the maximum file size in bytes to confirm the 10 MB ceiling is met?

The final output MP4 must be verified to be under 10,485,760 bytes.

When should you use CRF 23 instead of CRF 28?

CRF 23 should be used only if a frame-level check confirms that axis labels are unreadable at CRF 28.

What check is required before deciding to lower the CRF value?

You must perform a frame-level check of chart text to determine whether axis labels are unreadable at CRF 28.

Quick answers

Also worth reading: 7 Key Web Browser Rendering Engines Shaping Enterprise AI Development in 2024: 7 Key Web Browser Rendering · Essential Python libraries to simplify your data validation workflow: Essential Python libraries to simplify · AI tutorial generator under $50: 5 tools, adaptive loops cut learning 15% in 2026: AI tutorial generator under $50: