Co-streaming in a mobile app: WebRTC + RTMP

Co-streaming in a mobile app: where the broadcast breaks

Co-streaming in a mobile app is when several devices simultaneously send video and audio into a single broadcast: a host and a guest, two correspondents from different locations, a phone camera plus a second angle.

The task looks simple until a real network comes into play: each participant has their own channel, their own latency, and their own drops. It is exactly at the junction of these streams that simultaneous broadcasting breaks.

The first common failure is audio-video desync. Video travels over one channel, audio over another, their buffers have different depths, and when the network drops, the picture lags behind the voice by seconds.

The viewer sees lip movement before the sound or vice versa — the broadcast becomes unreadable, and the defect remains in the recording forever.

The second is connection loss when switching networks. The phone moves from Wi-Fi to mobile internet, the address changes, and the session drops at exactly the moment when there are the most viewers. Without reconnection and catch-up synchronization, the stream has to be brought back up manually.

The third is server load. When each participant sends their stream separately, the server side transcodes and distributes them according to the number of viewers, and audience growth multiplies the load. This is where quality drops appear for everyone at once.

We break down how this is solved at the architecture level: a single timeline for audio and picture, resilient reconnection when switching networks, and a distribution scheme that does not grow linearly with the number of viewers.

What a well-tuned co-streaming delivers: the effect in metrics

A well-tuned co-streaming setup is measured not by "works/doesn't work" but by specific metrics that the product team sees.

Connection time to the stream — from pressing "start" to the first frame for the viewer — we keep within 2-3 seconds on a normal network and up to 5 seconds on a weak connection: that is the threshold beyond which the viewer leaves without waiting for the picture.

The share of successful sessions (the viewer connected and watched through without interruption) is the key metric: on a well-tuned setup it reaches 97-99%, whereas a "raw" integration on real traffic drops to 80-85% because of mobile networks.

Broadcast stability is ensured by adaptation to the channel: bitrate and resolution are adjusted on the fly, and when the network degrades, the picture degrades smoothly (quality reduction) rather than breaking into a black screen.

On a weak channel — subway, elevator, congested Wi-Fi — this is the difference between "the viewer watched through" and "the viewer left." We build in buffering and connection recovery so that a brief network drop doesn't kill the session: reconnection happens unnoticed by the user, without restarting the stream.

Output picture quality is a separate metric: resolution and sharpness are preserved as much as the channel allows, without "mush" and compression artifacts.

We measure this by the share of frames without loss and the recovery time after degradation — both metrics go into monitoring rather than remaining just words.

The bottom line in numbers: connection time is reduced severalfold versus an unoptimized setup, the share of successful sessions grows by 10-15 percentage points, and drop-offs on a weak network fall by a multiple.

We capture these metrics on real devices and real channels, not in ideal test-bench conditions — which is exactly why they match what the user sees.

Co-streaming organization approaches: a comparison of methods

Co-streaming can be built in three ways, and the choice between them determines not the "beauty" of the picture, but how the application behaves under load: how many viewers a broadcast can handle, how quickly the host sees the audience's reaction, and what happens when one of the participants goes into the subway.

Below is a comparison by latency, scalability, and maintenance cost, without tying it to a specific stack.

A direct connection gives minimal latency — participants see each other almost without a pause, but each new interlocutor adds a channel, and on a weak mobile internet connection the picture starts to "fall apart." A relay server removes this problem: the host sends out a single stream, and the server distributes it to viewers, so scalability is limited by the infrastructure, not by the phone.

The hybrid scheme takes the best of both: latency between hosts stays low, while the audience connects through the server.

In practice, the scenario dictates the choice. If it's a joint stream of two or three bloggers with an active chat, a direct connection is enough. If a mass audience is watching the broadcast and recording is needed, a relay server is indispensable.

We select the scheme for the task and build in headroom: the application must survive a transition between networks and not interrupt the broadcast when the host changes.

How we build co-streaming: stages of work

Co-streaming is almost never built "from scratch": the client already has an app, authentication, profiles, and analytics, and the new scheme must fit into this infrastructure without breaking current releases.

That is why we run the work as an engineering project with fixed stages — from assessment to handover of guidelines, so the client's team understands what will appear in the product and when.

1. Assessment. We review the current app: platforms, architecture, the authentication and notification services in use, and load constraints. We record how many simultaneous streams and viewers the solution must handle at launch and with headroom for growth.
2. Scheme design. We determine where the media server lives, how the roles of host and viewers are distributed, and how broadcast rooms, recording, and moderation are structured. At this stage we agree on the stream scheme and failure scenarios — what happens when the host or a viewer loses connection.
3. Stream setup. We deploy video ingest and delivery, configure adaptive quality profiles for mobile networks, latency, and switching between communication channels. We separately work through the app's behavior under weak signal and when switching between networks.
4. App integration. We embed the streaming module into existing screens and connect it with authentication, profiles, push notifications, and analytics. The user should not notice the seam between the old and new functionality.
5. Testing. We run scenarios on real devices and networks: mass viewer entry, simultaneous streams, disconnections, weak channel, long sessions. We check the load and behavior during peak connections.
6. Documentation handover. We deliver the configured scheme, configuration description, support guidelines, and instructions for the client's team — so that further changes do not require us as the sole holders of knowledge.

The scope and timeline of each stage depend on the current state of the app and the load requirements. Describe your task — we will come back with an estimate and a work plan for your product.

Access policies and roles in co-streaming

Co-streaming breaks not on the codec, but on permissions: if any participant in a room can impersonate the host or connect to someone else's stream, no amount of picture stability will save you.

That is why we design the access model before the first line of streaming code — roles, rooms, and tokens are described as a single schema rather than patched together in response to incidents.

We fix roles at the level of the authorization service, not in the client: host, co-host, guest, and viewer receive different sets of permissions for publishing audio and video, for managing the scene, and for moderating chat.

The client only displays what is permitted — spoofing a role in the app does not grant access, because the server verifies it on every connection to the room.

• Host — publishes the stream, opens and closes the room, assigns co-hosts, removes participants.
• Co-host — publishes the stream and moderates, but does not change the room's composition and does not end the broadcast.
• Guest — publishes audio and video only after the host's confirmation, with no moderation rights.
• Viewer — receives the stream, can write in chat and react, publishing is prohibited.
• Observer — access to statistics and recordings without the right to enter the broadcast, for analytics and support.

We build room management around the lifecycle: a room is created for a specific broadcast, lives for a limited time, and closes automatically when idle.

This eliminates "dangling" rooms that can be connected to via an old link, and simplifies incident investigation — the room identifier shows who entered it and when.

Stream protection rests on short-lived access tokens: each is issued for a specific room, role, and duration, and is verified on entry and when publication is renewed.

A token cannot be reused in another room or after expiration, and access revocation takes effect without restarting the broadcast — the participant is disconnected from publishing without interrupting the stream for everyone else.

Case study: how we eliminated desync in a co-streaming app

The client came with a product for co-streaming: two or more hosts broadcast from the app simultaneously, and viewers see a shared scene.

Support complaints followed a single pattern — one host's audio lagged behind another host's video, and on a weak network the session dropped entirely, even though losing just one participant should have been enough.

Completion rates for such streams were falling: viewers left in the first minutes as soon as the picture started to stutter.

We chose WebRTC for the interactive part — latency between hosts matters there — and routed distribution to a broad audience via RTMP to a media server.

The desync occurred at the junction: streams arrived with different timestamps, and the mixer assembled the scene without a single reference clock.

We introduced a common time source for all incoming streams and an alignment buffer that absorbs network jitter without accumulating latency.

Dropouts were handled separately: reconnecting a participant became a local operation — their track is reassembled while the stream continues for viewers.

What we changed in the architecture

We separated the roles: receiving streams from hosts, mixing the scene, and distributing to viewers became independent nodes. A failure or restart of one does not bring down the others.

For each participant we maintain a backup channel: when the network degrades, the stream switches to an alternate route, and the viewer sees a quality switch rather than a dropout.

Session state is stored separately from the media stream — after a failure, the host returns to the same stream instead of creating a new one.

Metrics before and after

A separate note on diagnostics: we added end-to-end markers at every stage — from camera capture to the frame at the viewer's end. Now, when a complaint comes in, it's clear at which segment the time was lost, instead of cycling through hypotheses.

This is what turns a one-off fix into a manageable process: the next incident is analyzed based on data, not gut feeling.

How is co-streaming different from a regular broadcast?

A regular broadcast is a single source that publishes a stream to a server, and no matter how many viewers connect, everyone sees the same picture.

Co-streaming flips the scheme: there are multiple broadcasters, each sends their own stream from their own device, and the server merges them into a shared live feed.

The viewer sees not one window but a composition — the host, the co-host, the guest, the phone screen — and switches between angles without restarting the player.

The key difference lies in the publishing model. With a solo broadcast, a single upstream session is enough: the app captures the camera and microphone, encodes, and sends the stream.

In a joint live feed, there are as many such sessions as there are participants, and each one lives on its own channel with unpredictable network quality.

The app's job is not just to send its own stream, but to receive the others', merge them into a single scene, and deliver them to viewers in one container.

This gives rise to requirements for multiple devices: each has its own bitrate, its own latency, its own moment of joining and leaving the air.

Synchronization is what distinguishes working co-streaming from a collection of separate videos. The host's voice and the guest's reaction must coincide in time, otherwise the dialogue falls apart into echo and overlap.

To achieve this, streams are aligned by common timestamps, and the discrepancy between audio and video is kept within limits that the ear does not notice. If a guest joins with a poor connection, their track is held in a buffer rather than dropped into the air seconds late.

The requirements for the app grow accordingly.

You need resilience to network switching — moving from Wi-Fi to mobile without a dropout — bitrate adaptation for each participant separately rather than for the overall stream, and a distinction of roles: who broadcasts, who only watches, who can be brought on air by invitation.

A solo broadcast requires none of this — there is nothing to synchronize and no one to share the air with.

Common technical concerns about co-streaming

Co-streaming almost always comes down not to the fact of broadcasting itself, but to four technical questions: how it works across different devices, what happens to the load as the number of participants grows, how to secure access, and what to do when the internet connection is weak. Below are answers to the ones that most often come up during the evaluation stage.

How will the app handle the load if the number of viewers grows several times over?

The architecture is built so that the number of viewers doesn't affect the load on the host's phone: signaling and stream distribution are moved to the server side, and the client only sends a single outbound stream.

As the audience grows, distribution nodes are added, not the streamer's device capacity. This eliminates the classic problem where, at 50+ viewers, the phone starts to heat up and drop frames.

How are access and broadcast protection secured?

Access is granted through short-lived tokens tied to the session and device: the link can't be forwarded and viewed from someone else's account. Streams are encrypted along the entire path, and recording and chat moderation are configured through separate policies. For paid broadcasts, a check of viewing rights is added on the server side, not in the app.

What happens when the streamer or viewer has a weak internet connection?

The channel adapts based on feedback: bitrate and resolution are reduced in steps, packet loss triggers retransmission, and a complete drop causes the session to recover without restarting the broadcast.

A viewer on a weak network receives a stream with more buffering — the image lags slightly but doesn't fall apart. The streamer sees a quality indicator and understands when it's worth switching to the backup channel.

If your question isn't here — describe the scenario, and we'll come back with an estimate and a plan for your specific load and device fleet.

Let's discuss your co-streaming task

To come back with an estimate and a work plan rather than generalities, we need a substantive conversation.

Co-streaming is rarely "just add a button": it has requirements around latency, the number of simultaneous participants, and where the video lives — on your own hardware or with an external provider.

The more precisely you describe the current application and its constraints, the more concrete the next step will be.

What we need to understand up front so the estimate is based on facts rather than assumptions:

• Current application: platforms, what it's built on, how authentication and media handling are structured — this determines whether we embed co-streaming into the existing architecture or rewrite part of it.
• Broadcast scenario: how many hosts are on simultaneously, how many viewers, whether chat, reactions, moderation, and stream recording are needed.
• Latency requirements: interactive conversation between hosts and passive viewing are different video delivery schemes, and the choice affects the entire design.
• Quality and network: target platforms, mobile and slow channels, behavior when the connection degrades — the quality-switching logic depends on this.
• Infrastructure and access: whether you have your own media servers, CDN, and any constraints on storage and recording privacy.
• Timeline and phasing: what's needed for the first launch and what can be moved to a second phase without reworking the foundation.

Based on the conversation, we come back with an estimate and a work plan: the phases, what we do in each, which requirements we cover, and where the result checkpoints are.

Describe the task — the current application, the broadcast scenario, and the constraints — and we'll come back with a concrete proposal and the next step.