Recording calls in the browser is about 25 times cheaper

When we added recording to Freesbe huddles and meetings, the obvious design was the one most video products use: the call server already has everyone’s audio and video, so record it there.

We did the math and went the other way. Freesbe records calls in the app of the person who pressed Record. Here’s why, and what it cost us.

The numbers

Recording on a server means getting every speaker’s raw stream out of the media server and into something that can mix and encode it. With the tools available to us, that stream comes out as uncompressed 48 kHz audio, about 48 times the size of the compressed audio the call itself uses. Every one of those bytes is billed as traffic leaving the media service, and then something has to run for the whole call to mix and encode it.

Adding it up, server-side recording came to about $0.08 an hour for a two-person call and $0.16 for four people, before storage.

Recording in the browser costs about $0.003 an hour, plus around a cent a month to store the file. The recorder’s computer is already receiving everyone’s audio and video, because it’s on the call. Encoding it again locally costs us nothing.

How it works

The recorder’s app builds the recording the way a TV studio would build a program feed:

• Audio: everyone’s voice, plus the recorder’s own microphone, is mixed into one track.
• Video: cameras and shared screens are drawn onto a 1280×720 canvas at 15 frames a second, with the screen large and the cameras in a strip beside it.
• The browser’s built-in MediaRecorder encodes that into WebM (VP8 video, Opus audio).

Every 10 seconds the app uploads what it has so far to object storage. When the recording stops, the server joins the chunks into one file, writes the correct duration into the file’s header (WebM files made this way don’t know their own length), and posts the recording into the channel.

A few details made it work in practice:

• Frames come straight from the tracks. A hidden <video> element stops updating while the page is in the background, which is exactly what happens when someone shares a different window. Reading frames directly from the track keeps the recording moving.
• The drawing clock runs in a Web Worker, because browsers slow down timers in background tabs.
• Uploads retry with backoff, from one second up to 30, so a short network blip doesn’t lose a chunk.
• A second, speech-only track at a low bitrate (about 15 MB an hour) goes to transcription, along with who was speaking when, so transcripts get speaker names.

The trade-offs we accepted

Recording on the client isn’t free of downsides, and we decided each one was worth it:

• If the recorder leaves, the recording stops. Anyone in the call can also stop it. Every chunk is already uploaded, so nothing recorded is lost.
• The recording is only as good as the recorder’s view. If their connection drops someone’s video, the recording does too. Our weak-connection mode keeps audio first, so the voices survive.
• It uses the recorder’s CPU. Encoding one 720p stream is light work for any laptop made in the last several years.

Consent works the same either way: everyone hears a tone, sees a REC badge, and the channel gets a line saying who started recording.

When the server makes sense

We haven’t ruled server recording out. It becomes worth it when you need something the client can’t give you: a separate clean track per speaker for editing, a recording that survives everyone leaving, or recordings of calls where nobody wants to keep a laptop open. When we run more calls on our own call servers, the audio is already there and the traffic cost disappears, which changes the math again.

What we’d tell another team

Before you build the server-side version of anything, check what the client already has. In a call, every participant already holds a full copy of the media. Using that copy turned a cost that grows with every call into one that rounds to zero.

See Recordings and notes in the help center for how recording works for your team.