Integrating Live Streaming into a Mobile App

When trying to add live streaming to a fitness app, our client faced a delay of over 20 seconds on HLS. The trainer performed an exercise, but viewers saw his actions with a lag — destroying interactivity. We proposed an alternative: WebRTC with 500 ms latency and HLS for recording. WebRTC provides 30x lower delay than HLS. In 4 weeks, we deployed a system that handled 10,000 concurrent viewers. Request an audit of your app — we will determine the optimal architecture.

Main Technical Problems

Latency and buffering. HLS chops the stream into 6-second segments, resulting in 15–30 s delay. For interactivity (voting, chat), this is unacceptable. LL-HLS reduces to 2–5 s, but requires server support and iOS 14+. WebRTC solves the problem radically but is harder to scale.

Audio/video synchronization. When encoding on a mobile device, it is important to set GOP size and bitrate. In our project on Android, we used MediaCodec with a fixed GOP=2 and bitrate of 2 Mbps — this gave a stable picture even when speed dropped to 1 Mbps.

Media server scaling. One Wowza server handles up to 1000 connections. For 10,000 viewers, we configured a cluster of 4 nodes with load balancing via AWS ALB. Cloudflare Stream removes this pain but is more expensive.

How We Do It: Stack and Configurations

We start with an audit of requirements: target latency, expected audience, budget. For MVP, choose RTMP → HLS. For production low latency, choose WebRTC + LL-HLS fallback.

iOS streaming. Basic stack: Swift 5.9, HaishinKit (RTMP/SRT/HLS). Example configuration:

let rtmpStream = RTMPStream(connection: RTMPConnection()) rtmpStream.videoSettings = VideoCodecSettings( videoSize: CGSize(width: 1280, height: 720), bitRate: 2_000_000, frameInterval: 2, frameRate: 30 ) rtmpStream.audioSettings = AudioCodecSettings(bitRate: 128_000) 

Android streaming. Streampack or custom code on CameraX + MediaCodec + RTMP client.

val streamer = CameraStreamer(context, enableAudio = true) streamer.configure( AudioConfig(startBitrate = 128_000, sampleRate = 44100, channelConfig = CHANNEL_IN_STEREO), VideoConfig(startBitrate = 2_000_000, resolution = Size(1280, 720), fps = 30) ) 

Media server. Use Wowza Streaming Engine or Ant Media Server. For WebRTC — Ant Media or Janus.

How to Reduce Stream Latency to 500 ms?

Switching to WebRTC is the only way to get latency < 1 s. Key steps:

1. Deploy a signaling server (e.g., Node.js + Socket.io).
2. Set up a TURN server (coturn) for NAT traversal.
3. Choose a media server that supports WHIP ingest (Cloudflare Stream, Ant Media 2.x).
4. On the mobile client, use WebRTC.org SDK (Google for Android, native for iOS).

For mass viewing (1000+ viewers), WebRTC overloads the server — use an SFU (Selective Forwarding Unit). Ant Media and Janus support SFU. Source: WebRTC

Why WebRTC Is Not Always Suitable for Mass Broadcasts?

WebRTC requires a persistent P2P connection or SFU. Each viewer consumes about 2 Mbps downstream. For 10,000 viewers, you need 20 Gbps — expensive. Alternative: transcode the stream to HLS on the server and distribute via CDN. This increases latency but saves resources. We use a hybrid scheme: interactive scenarios (voting) via WebRTC for a small group, mass viewing via HLS.

Protocol Comparison

Media Server Comparison

Process

1. Analytics — measure latency requirements, audience size, device types. Determine protocol and server.
2. Design — client-server architecture, stream flow, media server configuration.
3. Implementation — write code in Swift/Kotlin/Flutter, configure server, test on real devices.
4. Testing — load testing (up to 10,000 virtual viewers) and network testing (3G, 4G, Wi-Fi).
5. Deployment — CI/CD, monitoring (Prometheus + Grafana), documentation.

What's Included

• Audit of the current app and architecture selection.
• Streaming integration on one platform (iOS or Android) with RTMP.
• Media server deployment (Wowza or Ant Media).
• WebSocket/Firebase chat with basic moderation.
• Load testing and optimization.
• Instructions for developers and administrators.

Estimated Timeline

• MVP (one protocol, one platform, no chat) — 2–3 weeks.
• Full system (two platforms, LL-HLS/WebRTC, chat, recording) — 2–3 months.

The cost is calculated individually after the audit. Contact us for an accurate quote.

Typical Mistakes

• Using HLS for interactivity — latency kills UX.
• Not setting GOP — packet loss causes artifacts.
• Forgetting the TURN server for WebRTC — clients behind NAT won't connect.
• Skimping on the media server — as audience grows, everything crashes.

Contact us for a consultation — we will select the optimal solution for your budget and timeline. We guarantee stable operation even under peak loads.