Mobile live streaming is fundamentally different from on-demand video. Latency matters — viewers expect their reactions to reach the streamer in seconds, not minutes. The interview tests whether you understand the ingest path, transcoding pipeline, and the tradeoff between buffering for smooth playback and minimizing glass-to-glass latency.
Functional requirements
- Mobile streamer broadcasts video from camera. Focus on the capture-and-encode path on the phone: the app grabs frames from the camera, encodes them on-device, and pushes them upstream. Interviewers probe how you handle orientation changes and switching between front and back cameras mid-stream.
- Thousands to millions of viewers. The read side dwarfs the write side — one broadcaster feeds an enormous fan-out. Be ready to explain why viewer scale is a CDN problem, not an origin problem.
- Live chat alongside the stream. Chat runs on its own pipeline so a chat spike never stalls the video path. Expect follow-ups on message ordering and moderation at scale.
- Reactions and donations / subs. Reactions are high-volume and can be aggregated or sampled; donations and subs touch money, so they need durable writes and idempotency. Interviewers watch whether you treat a payment differently from a heart emoji.
- VOD (video on demand) replay after the stream ends. The live segments you already produced become the VOD source, so you rarely re-encode from scratch. Discuss retention and when a live stream is promoted to a permanent asset.
Non-functional
- Glass-to-glass latency: 5–10 seconds for HLS, <3 seconds for low-latency variants
- Smooth playback even when network fluctuates
- Streamer battery: 30+ minute streams without overheating
Architecture
Three pipelines: ingest, transcoding, delivery.
Ingest
Streamer mobile app encodes video (H.264 or HEVC) and sends it to an ingest server via RTMP, SRT, or WebRTC.
- RTMP: standard, high latency (5+ seconds)
- SRT: better tolerance for poor networks, similar latency to RTMP
- WebRTC: sub-second latency but harder to scale fan-out
Most platforms use RTMP for ingest with the option of SRT for pro broadcasters.
Transcoding
The ingest server forwards the stream to a transcoding cluster. Each incoming stream is re-encoded into multiple resolutions (1080p, 720p, 480p, 360p, audio-only) for ABR delivery.
Transcoding is GPU-accelerated. Latency adds 1–3 seconds to the pipeline but enables broad device compatibility.
Delivery
Two main protocols:
- HLS: 2–4 second segments, ~10s glass-to-glass latency, works on every device
- Low-Latency HLS (LL-HLS) / DASH-LL: sub-3-second latency with proper CDN support
- WebRTC: sub-second but limited to direct connections; requires SFUs at scale
CDN distributes segments globally. Each viewer pulls from the nearest edge.
Chat
Separate from the video pipeline. WebSocket-based chat server handles thousands of messages per second per stream.
Sync chat with stream: messages timestamped to stream-time, displayed at the appropriate moment. Subtle but important — viewers comment on what they just saw, not what is happening server-side now.
VOD
While the stream is live, segments are saved. After the stream ends, a VOD pipeline stitches segments into a single playable file with chapters, optionally adds AI-generated captions.
Streamer battery
- Use hardware-accelerated encoders. Dedicated encoder blocks on the phone’s SoC draw far less power than software H.264. Naming this shows you understand mobile constraints, not just server-side scaling.
- Lower bitrate / resolution when battery low. Tie encoder settings to battery and thermal state, not only network conditions — a 1080p60 stream drains a phone much faster than 720p30.
- Detect overheating; warn streamer to reduce settings. Phones throttle when hot, which degrades the stream anyway; a proactive warning lets the streamer step down before frames start dropping.
Frequently Asked Questions
What if the streamer’s connection is unstable?
Adaptive bitrate during ingest — encoder reduces resolution if upload bandwidth drops. SRT handles brief outages with retransmission. Severe drops result in stream disconnection; viewers see a “reconnecting” indicator.
How is chat ordered across millions of viewers?
Server-side ordering with a single source of truth. Chat is fanned out via WebSocket; clients receive in server-order. Some platforms shard chat into rooms when a stream gets very large.
Why do some platforms feel laggier than others?
Tradeoff between resilience (more buffer = smoother but laggier) and interactivity (less buffer = snappier but more rebuffers). Twitch is known for low latency but more rebuffers; YouTube Live is the opposite.
Keep sharpening your system design:
