Category: basic knowledge (Page 1 of 4)

A data report from RedPanda Compress. All statistics are aggregates over tens of thousands of real-world video files analyzed in August 2026 — percent-only, no user-level data. Reuse welcome with attribution (see the end of the post).

Methodology & privacy, up front

RedPanda Compress is a browser-based video compressor: files are processed entirely on the user’s device and never uploaded. The telemetry behind this report is deliberately coarse — pre-bucketed ranges (resolution class, duration range, bitrate range), codec names, and connection-quality classes. No filenames, no file contents, no metadata atoms (camera model, GPS), and no per-user profiles; the categories match our public privacy page.

Known biases: this is not a census of “all video” — it is a census of video people need to shrink, so heavy formats are overrepresented. Orientation and resolution could not be determined for roughly a third of files; those are excluded from the orientation and resolution figures. Connection classes come from the browser’s Network Information API, which estimates effective quality — “3G” means “performs like 3G,” not a cell contract. Encoder provenance was measured on a large subsample.

Finding 1 — H.264 is still 82% of everything. AV1 is statistically invisible.

Codec	Share of files
H.264/AVC	82.1%
HEVC/H.265	13.2%
MJPEG	1.6%
MPEG-4 Part 2 (the DivX/Xvid era)	1.4%
ProRes	0.23%
AV1	0.22%
VP9	0.18%
VP8	0.08%

Twenty-three years after standardization, H.264 remains the water everyone swims in. The striking pair: files encoded with ~2003-era MPEG-4 Part 2 still outnumber AV1 files six to one. AV1 has won the streaming-platform war — YouTube and Netflix serve it billions of times a day — but in the world of files people actually hold (camera output, exports, downloads, old archives) it has essentially no presence. Codec adoption in personal files is generational, not technological: files outlive the codecs that made them, and the encoder defaults of cameras and apps — not the preferences of standards bodies — decide what the world’s disks look like. The one codec visibly gaining is HEVC, and it is gaining the same way H.264 did: by being a phone camera default.

Finding 2 — “Video” no longer means “clip”

Duration	Share
< 15 s	11.8%
15–60 s	22.5%
1–5 min	30.1%
5–20 min	17.1%
20–60 min	10.5%
≥ 1 hour	7.8%

Nearly one file in five runs longer than 20 minutes, and roughly one in thirteen exceeds an hour — lectures, meetings, screen recordings, gameplay sessions. The mental model of compression as “shrink this phone clip” misses a fifth of the real workload: video is now also a document format, the recording of something that took an hour because the thing itself took an hour.

Finding 3 — Nearly a quarter of desktop video is vertical

Orientation of files processed on desktop computers (where orientation could be determined):

Orientation	Share of desktop files
Landscape	70.5%
Portrait	23.2%
Square	6.3%

Vertical video was born on phones, but it now flows routinely through desktop workflows — footage synced, transferred, or downloaded to a PC for editing and sharing. Desktop software that treats portrait video as an edge case is failing nearly a quarter of real files.

Inside the square segment hides this report’s favorite curiosity: 61% of all square videos are below 360p, and 71% run under 15 seconds — a distinct, many-user cluster consistent with animated chat-sticker and emote culture. Even a three-second looping sticker is worth compressing when a chat app enforces a size cap.

Finding 4 — The 5–10 Mbps world, and the quarter that’s already been compressed

Container bitrate (size × 8 ÷ duration) of source files:

Bitrate	Share
< 1 Mbps	10.7%
1–2 Mbps	14.2%
2–5 Mbps	16.1%
5–10 Mbps	23.2% (modal)
10–20 Mbps	20.4%
20–50 Mbps	9.3%
≥ 50 Mbps	5.8%

The modal file arrives at 5–10 Mbps — the default output of phone cameras and screen recorders. But the tails tell the story. One file in seven exceeds 20 Mbps — modern phones shooting high-bitrate 4K their owners immediately need to shrink. And a full quarter of files arrive below 2 Mbps: video that has already been compressed once, being compressed again to squeeze under some app’s attachment limit. Both tails are artifacts of the same mismatch — recording defaults and sharing limits are set by different companies, and users are stuck reconciling them.

Finding 5 — The users the cloud forgets

Roughly one compression job in ten starts on a connection the browser classifies as 3G-class or slower (per the Network Information API’s effective-quality estimate); on desktop alone the share is about one in twelve. The label surprises until you remember what the API measures: effective throughput, which sweeps congested Wi-Fi, VPNs, tethering, and ISP throttling into the same bucket as genuine 3G.

For this population, uploading a gigabyte of video to a cloud service is somewhere between painful and impossible. Client-side processing isn’t a privacy preference for them; it is the only version of the product that works at all.

Finding 6 — 41% of everyday video has been touched by FFmpeg

Video files carry faint fingerprints of the last software that wrote them. Classifying those fingerprints on a large subsample:

Last writer	Share
FFmpeg-family (Lavf muxer)	41.0%
Other/indeterminate tools	28.8%
Video editors	12.4%
Android phone cameras	7.7%
Unclassifiable	4.2%
Apple cameras	2.8%
Platform downloads (YouTube-style)	2.2%
Action cameras	1.0%

Two things stand out. First, FFmpeg — one open-source project — was the last tool to touch two files in five. It is the invisible plumbing inside converters, downloaders, editors, transcoding pipelines and apps that never mention it; no other single piece of software comes close.

Second, read the camera rows together: only about one file in nine still carries a camera’s own fingerprint. Everything else has already been through at least one piece of software — trimmed, converted, downloaded, re-muxed — before reaching us. The “original” straight-off-the-camera video is, by the time anyone needs to share it, a minority artifact.

Honest limits: the fingerprint only names the last writer, not the chain; “Lavf” is a giant catch-all for anything built on FFmpeg; and a missing fingerprint does not prove a file came straight from a camera.

Finding 7 — .mp4 is a monoculture, and one MP4 in seven is lying to you

By file extension, everyday video is astonishingly uniform: nine files in ten are named .mp4. MOV takes most of the rest (7%); MKV, AVI and WebM are all below 1% each. The container war is over.

But the label has quietly stopped meaning what people think it means:

What’s actually inside a .mp4	Share
H.264 (plays everywhere)	85.2%
HEVC	11.6%
MPEG-4 Part 2	1.3%
MJPEG	1.2%
AV1 + others	0.7%

14.8% of .mp4 files — one in seven — don’t contain H.264, and most of those carry HEVC, which still fails to play in many browsers and on many non-Apple devices. “It’s an MP4, it’ll play anywhere” was true for fifteen years; phone cameras defaulting to HEVC-in-mp4 have silently broken it. The extension names the box, not the contents — and the box is no longer a guarantee.

(A small aside for trivia lovers: 3% of files have no audio track at all — mostly screen recordings and camera timelapses.)

Summary for the impatient

1. H.264 is 82% of personal video; AV1 is 0.22% — still outnumbered 6:1 by DivX-era MPEG-4.
2. Nearly 1 in 5 files exceeds 20 minutes — compression is now a meetings-and-lectures workload.
3. 23% of desktop video is vertical — and 61% of square video is sub-360p chat stickers.
4. The modal file is 5–10 Mbps, but a quarter of files are re-compressions of already-compressed video.
5. ~10% of compression jobs start on ≤3G-class connections — the population client-side tools exist for.
6. FFmpeg was the last tool to touch 41% of files; only ~1 in 9 still carries a camera fingerprint.
7. 90% of files are named .mp4 — but one MP4 in seven doesn’t contain H.264 and may not play everywhere.

Reuse this data

Data and charts may be reused with attribution and a link to redpandacompress.com. Questions about methodology: support@redpandacompress.com. All statistics are aggregates over coarse buckets; no user-level data exists to share. If you’re curious how a browser can analyze and compress video without uploading it, we’ve written up how the in-browser pipeline works and how to verify no upload happens.

The single most common complaint about browser-based video compression has never been quality, privacy or file size. It’s the wait. You pick a file, you hit start, and then you sit there watching a progress bar creep across a 40-minute recording.

We just shipped an upgrade to the engine that does that work. On the same file, on the same machine, encoding now runs roughly three times faster than it did before. Nothing about your workflow changes — same page, same buttons, same output file. It simply finishes sooner.

What actually changed

RedPandaCompress runs a real video encoder inside your browser, compiled to WebAssembly. That’s what makes the privacy guarantee possible in the first place: your file is processed by code running on your own device, so there is no upload step and nothing to store on a server.

The trade-off has always been that a browser sandbox is a more constrained place to run an encoder than a native app. This release is a substantial rework of how that engine executes — enough of a change that we’re measuring around a 3× improvement in encoding throughput on typical hardware. We’re keeping the implementation details to ourselves for now, but the part that matters to you is simple and measurable: the same job, finished in about a third of the time.

What 3× looks like on real files

Encoding time scales with how many pixels there are to process, so the absolute saving grows with the length and resolution of your video. The relative saving is what stays roughly constant. A rough guide, based on the speedup applied to jobs of each size:

Source file	Before	Now (approx.)	Time you get back
1 min, 1080p phone clip	~45 s	~15 s	half a minute
10 min, 1080p screen recording	~7 min	~2.5 min	~4.5 min
12 min, 4K drone footage	~24 min	~8 min	~16 min
45 min, 1080p lecture	~32 min	~11 min	~21 min

Treat those as a shape rather than a promise. Your actual numbers depend on your CPU, how many other tabs are competing for it, and what codec the source file is in. But the pattern holds: the longer the video, the more real time the upgrade hands back to you.

A worked example

Say you have a 1.2 GB, 12-minute 4K clip off a drone, and you need it under 200 MB to share with a client.

The output is identical to what you’d have got last month: an H.264 MP4 at roughly 180 MB that plays on any phone, laptop, TV or editor you hand it to. The difference is that the job that used to occupy the better part of half an hour — long enough that you’d start it and go do something else, then forget about it — now finishes inside a coffee break, with the tab still open in front of you. For anyone compressing several files in a sitting, that’s the difference between a background chore and something you just do.

What did not change

This is a speed release, and it was important to us that it stayed only a speed release. Specifically:

• Your files still never leave your device. There is no upload, no server-side processing, no temporary copy sitting in someone’s bucket waiting on a deletion timer. Faster local work is still local work. If you want to verify that yourself rather than take our word for it, we wrote up three ways to check whether a converter uploads your files — including the numbers we measured on our own tool.
• Output is still universally compatible H.264 MP4. We didn’t buy speed by switching you to a more exotic codec that half your devices won’t play.
• Quality and file size targets are unchanged. Ask for the same target size and you get the same result — this isn’t a case of going faster by encoding worse.
• Large files are still supported. Multi-gigabyte sources keep working the way they did.
• Nothing to install or update. Reload the page and you have it. There’s no version to pick and no setting to turn on.

Where you’ll notice it most

Not every job feels three times faster, because not every job was encoding-bound to begin with. The upgrade pays off most on:

• Long recordings — lectures, webinars, gameplay, anything measured in tens of minutes.
• High-resolution sources — 4K footage has four times the pixels of 1080p, so it was the most painful case and gains the most.
• Modern multi-core laptops and desktops — machines with cores to spare see the biggest improvement.

It pays off least on very short clips, where a few seconds of setup is most of the total time anyway, and on older or low-core devices, where the ceiling is the hardware rather than the software. Phones benefit, but less dramatically than a desktop does — a phone has fewer cores and throttles itself when it gets warm.

One practical tip either way: keep the tab in the foreground while it works. Browsers aggressively deprioritise background tabs, and that will cost you more time than any engine upgrade can give back.

Frequently asked questions

Will my compressed videos look different now?

No. Same encoder settings, same target sizes, same H.264 MP4 output. If you re-run a file you compressed last month at the same target, you should get a comparable result — just sooner. If you do see a difference in quality or size that you can’t explain, we’d genuinely like to know about it.

Why isn’t my machine hitting 3×?

Three times is what we see on typical multi-core hardware, not a guarantee for every device. An older laptop, a low-end phone, a machine already busy with a video call, or a very short clip will all land below that. It should still be faster than it was, on the same file and the same machine.

Does this affect the converters and audio tools too?

The improvement is in video encoding, so it shows up wherever video is re-encoded — format conversion included. Jobs that never re-encode video in the first place, like pulling the audio track out of a video, were already fast because they were mostly reading and copying data, not encoding it.

Do I need to do anything to get it?

No. It’s live for everyone. If you had the site open in a tab from before the update, reload it once and you’re on the new engine.

Found a problem? Tell us

A change this deep in the engine touches every file that goes through the site, and real-world video is endlessly varied — odd codecs, unusual frame rates, files from cameras we’ve never seen. If something that used to work now doesn’t, if a file fails, or if a result looks wrong to you, please email us at support@redpandacompress.com. Telling us the file format, roughly how big it was, and which browser and device you were on is enough for us to start looking. Feature requests and “why does it do this” questions are welcome at the same address.

Otherwise, there’s nothing to do but use it. Drop a file on RedPandaCompress and watch it finish sooner than you expect — still free, still entirely in your browser, still without your video ever leaving your computer.