Developing a Live Streaming Platform from Scratch

Architecture of a Live Streaming Platform

We often face the challenge: a company wants to launch its own streaming service, similar to Twitch, but with its own monetization rules and content. A typical problem is increased latency reaching up to 10 seconds at peak, quality drops, and infrastructure cannot handle the load. Over 5+ years we have developed more than 15 streaming projects, from small educational platforms to large media. Let's break down how to build a reliable live system from scratch, considering latency requirements, device compatibility, and scaling to thousands of viewers. The choice of protocols is based on criteria such as latency, CDN support, and browser compatibility.

Delivery Scheme and Protocols

Streamer → Ingest → Transcoding → CDN → Viewer

Incoming stream from the streamer is typically RTMP (OBS, StreamLabs, XSplit all support RTMP out of the box). On the viewer side, we use HLS or DASH for browsers, WebRTC for ultra-low latency (< 1 s).

RTMP provides low latency during ingestion but is not suitable for delivery due to firewall blocking. HLS is the de facto standard, works over HTTP and is easily cached on CDNs.

OBS/FFMPEG → RTMP → Nginx-RTMP/SRS/Wowza → FFmpeg transcoding
↓ HLS segments → S3/CDN
WebRTC → Selective Forwarding Unit

Why SRS is Better Than Other Ingest Servers

SRS (Simple Realtime Server) is open source, written in Go, and handles up to 10K+ connections on a single server. In our projects, SRS showed 30% higher performance than Wowza under identical configuration. Configuration via a single config file:

# srs.conf
listen 1935;
max_connections 1000;
daemon off;
http_server {
    enabled on;
    listen 8080;
    dir ./objs/nginx/html;
}
vhost __defaultVhost__ {
    # Hook: notify backend on stream start/end
    http_hooks {
        enabled on;
        on_publish http://api:8000/hooks/stream/start;
        on_unpublish http://api:8000/hooks/stream/stop;
        on_play http://api:8000/hooks/stream/view;
    }
    hls {
        enabled on;
        hls_path ./objs/nginx/html;
        hls_fragment 2; # 2 seconds — balance between latency and stability
        hls_window 10; # 10 segments in window
    }
    transcode {
        enabled on;
        ffmpeg /usr/local/bin/ffmpeg;
        engine hd {
            enabled on;
            vcodec libx264;
            vbitrate 2000;
            vfps 30;
            vwidth 1280;
            vheight 720;
            acodec aac;
            abitrate 128;
            output rtmp://localhost:1935/[app]/[stream]_720p;
        }
        engine sd {
            enabled on;
            vcodec libx264;
            vbitrate 800;
            vfps 30;
            vwidth 854;
            vheight 480;
            acodec aac;
            abitrate 96;
            output rtmp://localhost:1935/[app]/[stream]_480p;
        }
    }
}

Streamer Authentication

The streamer publishes the stream using a stream key. We must not accept RTMP from unknown sources:

# FastAPI: hook for SRS on_publish
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

class PublishHook(BaseModel):
    action: str
    app: str
    stream: str  # stream key from streamer
    param: str   # query string

@app.post("/hooks/stream/start")
async def on_stream_start(hook: PublishHook):
    # Validate stream key
    streamer = await db.fetchrow(
        "SELECT id, user_id, is_active FROM stream_keys WHERE key = $1",
        hook.stream
    )
    if not streamer or not streamer['is_active']:
        raise HTTPException(status_code=403, detail="Invalid stream key")

    # Start stream in DB
    await db.execute("""
        INSERT INTO live_streams (user_id, stream_key_id, started_at, status)
        VALUES ($1, $2, NOW(), 'live')
        ON CONFLICT (stream_key_id) DO UPDATE SET started_at = NOW(), status = 'live'
    """, streamer['user_id'], streamer['id'])

    # Notify followers via WebSocket
    await notify_followers(streamer['user_id'], 'stream_started')

    return {"code": 0}  # SRS expects code=0 to allow"}

How Real-Time Chat Works

Stream chat is a must-have. WebSocket via Redis Pub/Sub with rate limiting and a sliding window of messages:

// Node.js: WebSocket server for chat
import { WebSocketServer } from 'ws';
import { createClient } from 'redis';

const wss = new WebSocketServer({ port: 3001 });
const redis = createClient({ url: process.env.REDIS_URL });
const redisSub = redis.duplicate();

await redis.connect();
await redisSub.connect();

interface ChatMessage {
  type: 'message' | 'emote' | 'sub' | 'ban';
  streamId: string;
  userId: string;
  username: string;
  text: string;
  badges: string[];
  timestamp: number;
}

// Subscribe to stream channel
wss.on('connection', (ws, req) => {
  const streamId = new URL(req.url!, 'ws://x').searchParams.get('stream');
  if (!streamId) return ws.close();

  const channel = `chat:${streamId}`;

  // Listen to Redis Pub/Sub for this stream
  redisSub.subscribe(channel, (message) => {
    if (ws.readyState === ws.OPEN) {
      ws.send(message);
    }
  });

  ws.on('message', async (data) => {
    const msg: ChatMessage = JSON.parse(data.toString());

    // Anti-spam: rate limit per user
    const key = `chat_limit:${msg.userId}:${streamId}`;
    const count = await redis.incr(key);
    if (count === 1) await redis.expire(key, 5);
    if (count > 20) {
      // 20 messages in 5 seconds is too many
      ws.send(JSON.stringify({ type: 'slowmode', waitMs: 5000 }));
      return;
    }

    // Store in Redis Stream (sliding window of 1000 messages)
    await redis.xAdd(`stream_chat:${streamId}`, '*', msg as any, {
      TRIM: { strategy: 'MAXLEN', threshold: 1000 }
    });

    // Publish to all connected clients
    await redis.publish(channel, JSON.stringify(msg));
  });

  ws.on('close', () => {
    redisSub.unsubscribe(channel);
  });
});

Recording Streams to VOD

After the stream ends, we concatenate the TS segments and re-encode with faststart for pseudo-streaming. Official FFmpeg documentation recommends using the -movflags +faststart flag to move the moov atom to the beginning of the file, which speeds up playback start.

# Celery task: conversion to VOD
@app.task
def process_vod(stream_id: int):
    stream = LiveStream.objects.get(id=stream_id)
    segments = sorted(
        glob(f"/var/srs/hls/{stream.stream_key}/*.ts"),
        key=lambda f: int(Path(f).stem.split('_')[-1])
    )
    concat_list = "/tmp/vod_concat.txt"
    with open(concat_list, 'w') as f:
        for s in segments:
            f.write(f"file '{s}'\n")
    raw_mp4 = f"/tmp/vod_{stream_id}_raw.mp4"
    subprocess.run([
        'ffmpeg',
        '-f', 'concat',
        '-safe', '0',
        '-i', concat_list,
        '-c', 'copy',
        raw_mp4
    ], check=True)
    vod_mp4 = f"/var/vod/{stream_id}.mp4"
    subprocess.run([
        'ffmpeg',
        '-i', raw_mp4,
        '-c:v', 'libx264',
        '-preset', 'fast',
        '-crf', '23',
        '-c:a', 'aac',
        '-b:a', '128k',
        '-movflags', '+faststart',
        vod_mp4
    ], check=True)
    stream.vod_path = vod_mp4
    stream.status = 'ended'
    stream.save()

How to Set Up Multi-Quality Transcoding: Step-by-Step

1. Install SRS and FFmpeg on the server.
2. In the SRS config, enable the transcode section and specify the paths to FFmpeg.
3. Define transcoding profiles (e.g., HD: 720p, 30fps, 2 Mbps; SD: 480p, 30fps, 800 Kbps).
4. In the output URLs, use [stream]_720p and [stream]_480p so SRS automatically adds the suffix.
5. Verify that HLS segments are created for each profile in separate subdirectories.
6. Test with OBS, sending the stream to the RTMP ingest. Ensure the player can switch between quality levels.

Delivery Protocol Comparison

Popular CDNs for HLS Delivery: Comparison

What's Included in Turnkey Platform Development

• Architectural design: protocol selection, CDN, capacity planning.
• Ingest server: SRS/Nginx-RTMP setup, multi-quality transcoding.
• Backend: API for stream management, authentication, monetization.
• Frontend: customizable player, streamer dashboard, chat.
• Infrastructure: Docker containerization, auto-scaling, monitoring.
• Documentation: full technical documentation, admin instructions.
• Training: session for your team, 2 weeks of post-launch support.
• Warranty: free bug fixes for one month after launch.

Scaling: Multi-Server Ingest

A single ingest server is a single point of failure. For production, you need a cluster with load balancing:

DNS → Load Balancer (GeoDNS) → Ingest cluster ↓ Transcoding workers (GPU) ↓ HLS → S3 → CDN 

Streamers are directed to the nearest ingest server via GeoDNS. Each ingest writes to a shared object store or replicates segments synchronously. Contact us to discuss your project architecture — we will find the optimal configuration for your needs.

Timelines

MVP with RTMP ingest, HLS delivery, WebSocket chat, and VOD recording — 10–12 weeks. Adding multi-quality transcoding, gift subscriptions, chat moderation, mobile player — another 8–10 weeks. Scaling to 10k+ concurrent viewers, load-balanced ingest, CDN with origin shield — a separate phase.

Ready to launch your own streaming service? Get a consultation — we'll evaluate your project in 2 days. Reach out to us.