Local recording vs cloud recording

What is the difference between local and cloud recording?

A remote call has two separate things happening at once. There is the live stream — heavily compressed, resized on the fly, and dropping frames whenever the network asks it to, because its only job is to arrive now. And there is the raw camera track sitting on each participant's machine, which nothing has touched.

Cloud recording saves the first one. Local recording saves the second one and moves it afterwards.

Why does local recording look better?

Because a live stream is optimised for a deadline and a recording is not. To hold a call together, the encoder drops resolution, drops frame rate and raises compression the moment bandwidth tightens — and every one of those decisions is baked into a cloud recording forever. The same twenty seconds of a shaky connection cost you a stutter on a local recording and a permanently blurry face on a cloud one.

Recording from the raw track also means the master can be higher resolution than the call ever was. In RealPodcast the recorder reads the untouched camera track, so the deliverable is not limited by what your guest's connection could carry.

What can go wrong with local recording?

One thing, and it is the thing that matters: the file is on your guest's laptop, and it has to get to you. Every real horror story in this category is a variation on that.

• The guest closes the tab. The interview is over, they say goodbye, they close the window — and whatever had not uploaded is gone.
• The browser evicts the data. Recordings held only in memory disappear when the tab is discarded under memory pressure.
• The upload is all-or-nothing. A single large file that fails at 90% starts again at 0%.
• Nobody notices until later. With no progress visible during the call, a silently failing upload is discovered days after the guest is unreachable.

How do you make the upload survive?

You stop treating the recording as one file that moves at the end, and start treating it as a stream of parts that move during the call. Three properties do the work:

1. Upload while recording, in fixed parts. The browser's recorder emits blobs at irregular sizes; a buffer turns them into uniform parts (8 MiB in our case — object storage requires every non-final part to be the same size and at least 5 MiB). Because those parts are byte ranges of one continuous stream rather than standalone files, completing the upload reconstructs the original recording exactly, with no server-side stitching step to go wrong.
2. Write every part to disk before uploading it. Parts go to the browser's origin-private file system with a manifest beside them. The bytes then outlive the tab that made them.
3. Let any later tab finish the job. Because the parts and the manifest are on disk rather than in one page's memory, a tab opened afterwards can read the manifest, push what is still pending, and complete the upload. Closing the window becomes a delay instead of a loss.

The failure mode that remains is honest and visible: an upload that has not finished yet. That is a progress bar, not a lost interview.

Which one should you choose?

• Publishing video, or audio you care about? Local, every time. The quality difference is not subtle and it cannot be fixed afterwards.
• Interviewing people once, who you will never get back? Local, but only with a recorder that uploads during the call. Local recording without resumable upload is the riskiest option on this page.
• Streaming live, or recording purely for reference? Cloud is fine and simpler. The recording is done when the call is.

In practice the question is rarely local or cloud — it is whether the local recording is actually going to arrive. Ask any tool you are evaluating what happens when a guest closes the tab mid-upload. The answer tells you most of what you need to know.