Every time we tell a customer that Connect records to WebM, someone asks: "Why not MP4? MP4 is what everyone uses." Fair question. Here\'s the technical answer, then the pragmatic answer.

The technical answer

WebRTC in modern browsers negotiates a small handful of codecs by default:

Audio: Opus — universally supported, low-latency, high-quality.
Video: VP8 or H.264. Both are supported by most browsers. mediasoup, our SFU, defaults to VP8.

Container formats:

WebM — natively holds VP8/VP9 video and Opus audio. No transcoding required.
MP4 — historically holds H.264 video and AAC audio. Opus support in MP4 is technically possible but not universally playable.

If we output to MP4, we\'d need to transcode:

VP8 → H.264
Opus → AAC

Transcoding at 15fps with 720p video for one call is on the order of 30% of a single CPU core per participant per recording. On a 2-core VPS with the main DeskTrust app + connect-server + mediasoup workers + potentially multiple concurrent recordings — that\'s untenable.

Pass-through WebM

Because WebM natively holds the codecs mediasoup emits, ffmpeg becomes a router, not an encoder. Command:

ffmpeg -protocol_whitelist file,udp,rtp \
  -i session.sdp \
  -c copy \
  -f webm \
  session-<timestamp>.webm

The -c copy flag tells ffmpeg to remux the streams without re-encoding. CPU usage: negligible. RAM usage: negligible. This is why Connect can run recording on a small VPS without pinning cores.

The playback answer

"But MP4 plays everywhere and WebM doesn\'t." That was true in 2015. In 2026:

Chrome, Edge, Firefox — WebM has native support with hardware acceleration where available.
Safari (macOS) — WebM support since Safari 14.1 (April 2021).
Safari (iOS) — VP8 WebM support since iOS 14.5 (April 2021).
Android Chrome — WebM has been native since Android 5.

For any user on hardware <5 years old, WebM plays fine.

Where WebM still bites

Legal e-discovery tools often expect MP4 or MOV. If your law firm asks for MP4 as part of a discovery packet, we\'ll transcode on demand — that\'s a v1.1 feature.
Very old QuickTime installations and some corporate media players don\'t handle WebM.
Adobe Premiere and Final Cut Pro can import WebM but the workflow feels second-class compared to MP4.

The compromise plan

v1: record to WebM natively. Fast, cheap, plays in browsers.

v1.1: add an on-demand transcode-to-MP4 option. Recording stays WebM; when a user needs MP4 (for legal export, video editing, or an old media player), request the conversion. A background ffmpeg job transcodes VP8→H.264 and Opus→AAC into a sibling MP4 file.

This gives us the CPU efficiency of pass-through recording during high-volume live sessions AND the compatibility of MP4 for the smaller number of situations where it\'s needed.

What about the mediasoup H.264 path?

mediasoup can negotiate H.264 instead of VP8 if the peer prefers it (Safari does). In that case the video track IS H.264, and we could remux directly into MP4 with -c copy. We considered making the format adaptive — WebM for VP8 sessions, MP4 for H.264 sessions.

The added complexity (branching output paths, different file extensions per session, harder playback URL routing) wasn\'t worth the tiny compatibility gain. WebM everywhere is simpler, and Safari plays it fine.

TL;DR

WebM saves CPU. Every modern browser plays it. MP4 is available on demand when a specific workflow needs it. If your compliance team specifically requires MP4 for archival, tell us and we\'ll accelerate the transcode-on-demand feature.

Why Connect records to WebM (and why that saves your CPU)