Lectures & screen recordings
Start with readable text. Trim irrelevant sections, crop in your editor when useful, and test a short segment before processing a long recording. Lower frame rates may suit slides but make cursor movement less smooth.
BitePDF Labs · 19 October 2026
How small
is still useful?
A video that fits the upload box still needs readable text, useful detail and clear sound. Here is what our compression tests actually showed.
Try your video →Measured files. Visible failures. A small study, with room to improve.
01 / A size target is a request
Turning the bitrate down did not always turn the bytes down.
We encoded the same 10-second synthetic portrait clip four ways. Its source was 2,562,891 bytes at 720 × 1280. Three full-dimension outputs missed their requested targets. Reducing dimensions reached 500 KB in this example, with fewer pixels to preserve detail.
0 MB1.5 MB
Constant bitrate · full dimensions1.357 MB
720 × 1280 · Missed 1.000 MB target
Variable bitrate · full dimensions1.345 MB
720 × 1280 · Missed 1.000 MB target
Stricter target · full dimensions1.326 MB
720 × 1280 · Missed 0.500 MB target
Smaller dimensions · explicit choice0.478 MB
360 × 640 · Met 0.500 MB target
Vertical marks show requested limits. These are separate single encodes, not a quality ranking or a prediction for your file.
That result shaped the tool: measure the completed file, adjust bitrate within a bounded number of attempts, and report a miss honestly. A resolution limit is your choice. Retrying cannot promise the same detail at any requested size.
02 / Check the picture, too
Bytes are easy to count. Quality needs more than one check.
We added FFmpeg structural similarity (SSIM) comparisons for two synthetic clips. The source and prepared videos have matching dimensions. We aligned their starting timestamps and compared all 96 frames at 24 fps for the silent clip, and all 240 frames at 30 fps for the clip with sound.
| Clip | Source → output | SSIM (All) | What the check leaves open |
|---|---|---|---|
| Silent pattern · 4 seconds · 640 × 480 | 551,790 → 375,885 bytes | 0.984575 | No sound to assess. Not a test of small text or faces. |
| Motion pattern + tone · 8 seconds · 1280 × 720 | 4,080,132 → 1,028,855 bytes | 0.945047 | Missed 500 KB after two attempts. Sound track retained; human quality and sync unreviewed. |
SSIM measures structural similarity; it is not a percentage of quality preserved. Neither score certifies legible captions, natural faces, HDR brightness or acceptable sound. These are synthetic patterns, not representative evidence for every real video. FFmpeg documents the metric and its options.
One clip, three different trade-offs
A follow-up compared three outputs from the same 8-second motion-and-tone source, keeping 1280 × 720 and 30 fps. The earlier parts allocator requested up to 8 Mbps even for this already compact source. A source-average ceiling reduced that waste. Lower bytes still came with a measurable similarity loss.
| Method | Actual output | SSIM (All) |
|---|---|---|
| Earlier parts allocation | 8,030,602 bytes | 0.976276 |
| Revised source-bounded allocation | 3,687,046 bytes | 0.971348 |
| Strict 500 KB target, missed after two attempts | 1,028,855 bytes | 0.945047 |
The revised part is 54.1% smaller than the earlier part output, and 9.6% smaller than the 4,080,132-byte source. This one-clip result does not establish a general quality advantage. Requested bitrate is not measured output bitrate, and the source-average estimate does not understand faces, text or individual scenes.
03 / Larger files, bounded work
A 1.66 GB recording does not need to become a 1.66 GB browser download.
In the live parts workflow, we selected an owner-provided 1,661,223,995-byte screen recording. The first minute downloaded as 40,255,684 bytes. A second local interval from 60 to 120 seconds downloaded as 41,746,974 bytes after a Stop and retry. Both saved files fully decoded with H.264 video and AAC audio.
| Run | Measured output | Evidence boundary |
|---|---|---|
| Live parts · first minute | 40.256 MB · 1920 × 1246 · 30 fps | Public bitepdf.com flow, download and full decode passed. |
| Local parts · second minute | 41.747 MB · 1920 × 1246 · 30 fps | Stop → retry → download and full decode passed. |
| Earlier whole-file diagnostic | 222.357 MB · 747.633 seconds | Local browser experiment. Not the public parts workflow; no whole-file public export claim. |
The part workflow supports selecting a source up to 2 GB and 30 minutes, then preparing one 1-, 2- or 5-minute part at a time. Each completed part has a hard 100 MB write cap. The first two intervals above do not prove that every interval, codec, device or 2 GB boundary succeeds. Container durations were about 60.074 seconds per tested part, so these are not sample-exact audio cuts.
Part files are encoded independently; they are not byte fragments that need reassembly. Download each one before preparing the next. Temporary parts use private browser storage. An unexpected tab closure can leave temporary storage; clearing BitePDF’s site data removes it.
Make playable parts from a large video →04 / Pick the trade-off
The right settings depend on what someone needs to see.
Portrait creator videos
Keep the portrait shape. Check small subtitles and moving faces. More saturation or brighter pixels do not establish better compression. This tool does not add AI detail, repair faces or create HDR.
A strict upload limit
Use target-size mode and leave headroom for the destination. A measured miss means it still does not fit. Consider a shorter clip, an explicitly lower resolution, or a permission-controlled sharing link.
An already compact clip
Re-encoding can make it larger. Start from the original on every attempt. The parts allocator now uses the source’s average bitrate as a ceiling estimate instead of assigning every short clip 8 Mbps. It still cannot guarantee a smaller or equally detailed result.
05 / Methods, limits & next checks
A reproducible starting point.
Browser tests used Chrome on one Mac and Mediabunny 1.61.3 with browser codecs. The portrait experiment used H.264, re-encoded AAC at 128 kbps and a 5% budget reserve. Its initialization-plus-encode observations were 1,855 / 1,077 / 1,137 / 789 ms in table order. Each ran once; these are not reliable speed estimates for another device.
The released target controller uses a 6% reserve, 128 kbps audio when present, measured output sizes and at most two attempts for free access or three with a verified active pass/Pro. Silent sources reserve no audio bitrate. The selected resolution limit applies only with permission. Unsupported tracks stop the conversion.
Parts use H.264 and AAC, 30 fps and a 1920-pixel long-edge limit. Their bitrate is bounded by duration, a 95 MB working budget, an 8 Mbps ceiling and a file-average source estimate. Actual writes stop at 100 MB. An estimate does not prove picture quality or universal browser compatibility. No AWS GPU or hosted AI model was used in these tests.
Missing coverage: representative human review, physical phones, HDR, subtitles, many codecs, precise audio boundaries, long-run memory measurements and a complete public conversion of every part of the large recording. No customer or competitor performance claims are derived from this study.
Mediabunny format and codec documentation · Chrome file-system documentation · Download measured data (JSON)
Updated as new evidence is collected. We have not measured an SEO ranking or revenue effect from this page.