Why does dual camera video look worse after you send it?

What DualCam actually wrote, before anything else touched it

The moment you stop recording, DualCam has already produced a finished file: an MP4 with H.264 video, composited at a fixed bitrate of roughly 10 Mbps, and — unless you recorded muted — a single mono AAC audio track. That file does not change after the fact. Saving it to Photos writes a copy into the same library the stock Camera app uses; sharing it opens the ordinary iOS share sheet and hands the same file to whatever you pick next. Neither step re-encodes anything on DualCam’s side.

So the video you are looking at immediately after recording, in DualCam’s own library, is as good as that file ever gets. Any softness or blockiness that shows up later was added downstream, by the app that carried it the rest of the way.

Why the app you send it through re-encodes it at all

Messaging and social apps are built to move video quickly and reliably over a network that is not always fast, and a phone-shot video can easily be tens or hundreds of megabytes. Sending that file byte for byte would be slow on an ordinary connection and would blow past the size limits most of these apps enforce, so they re-encode it first — a fresh, usually more aggressive compression pass aimed at a small delivery size rather than at preserving every pixel you recorded.

This is true of a video from the stock Camera app just as much as one from DualCam. It is a property of how the app you are using chooses to move data, not a judgment about where the video came from.

Why a dual-camera file has less room to give

A re-encode is lossy no matter what it is applied to, but how much it costs you depends on how much detail the source already has to spare. A single camera on the same iPhone can reach 4K; a multi-camera session cannot, because two live streams plus a real-time composite have to fit inside one shared hardware budget, and DualCam’s canvas tops out at 1080 pixels wide. A 4K file being squeezed down for sending still has a large surplus of real detail to throw away before the loss is visible. A file that started at a lower resolution and a fixed, modest bitrate does not have that surplus, so the same re-encode shows up sooner — as softness, or as blocky patches in busier parts of the frame.

It shows up least evenly, too. The picture-in-picture inset is already a smaller crop sampled down from the source frame, and a left/right split has already lost roughly a quarter of each source frame off the edges. Both are thinner on detail than the main frame before a second compression pass ever runs, so that is usually where a re-encode looks worst first.

What actually keeps more of the quality when you share

AirDrop, when the recipient can use it

AirDrop moves the file itself between two Apple devices rather than routing it through a server built around a message size limit, so it generally has far less reason to re-encode what you send. Between two nearby iPhones, it is the closest thing to handing someone the original file DualCam wrote.

Wi-Fi over cellular, when the app gives you the choice

Some apps trade quality for speed more aggressively on a cellular connection than on Wi-Fi, because a cellular network is more likely to be slow or metered. If quality matters for a particular clip and you have the option, sending it over Wi-Fi tends to leave more of it intact.

Send the original, not a copy of a copy

Every re-encode is lossy, and re-encodes compound: a video downloaded from one platform and then uploaded to a second one has already lost detail once before the second platform gets to compress it again. Sharing straight from DualCam’s library or from Photos, rather than passing along a file someone already downloaded from somewhere else, means only one re-encode happens instead of several stacked on top of each other.