Skip to main content
The broadcast example demonstrates how to implement a Selective Forwarding Unit (SFU) pattern where one broadcaster uploads video once, and the server forwards it to multiple viewers. This is essential for building scalable video streaming applications, webinars, or live broadcasting platforms.

Overview

This example creates a simple SFU (Selective Forwarding Unit) that accepts one video stream from a broadcaster and distributes it to multiple viewers. The broadcaster only uploads once, dramatically reducing bandwidth requirements compared to peer-to-peer mesh architectures.

Key Features

  • One-to-many video distribution
  • Minimal bandwidth usage for broadcaster
  • HTTP server for easy SDP exchange
  • Automatic track forwarding to all connected viewers
  • Support for unlimited viewers
  • Interval PLI for keyframe management

Architecture

How It Works

1

Start HTTP Server

The example starts an HTTP server to receive SDP offers:
2

Accept Broadcaster Connection

Create the first PeerConnection to receive the broadcast:
3

Create Local Track for Distribution

When receiving the remote track, create a local track to forward to viewers:
4

Add Viewers

For each viewer, create a new PeerConnection and add the local track:

Complete Source Code

Important Implementation Details

The example uses TrackLocalStaticRTP to forward packets:
Why StaticRTP?
  • Direct packet forwarding without re-encoding
  • Low CPU usage
  • Preserves original quality
  • No transcoding overhead
The same local track instance is added to all viewer PeerConnections.
When no viewers are connected, writing to the local track returns io.ErrClosedPipe:
This is expected and should not cause the application to panic. Once viewers connect, packets will be successfully delivered.
This example uses HTTP POST for signaling:
For production, implement:
  • WebSocket signaling for bidirectional communication
  • Authentication and authorization
  • Session management
  • Proper error handling
Current implementation:
  • Single server process
  • Unlimited viewers (limited by server resources)
  • No load balancing
For production scale:
  • Implement clustering with multiple SFU servers
  • Use cascading SFUs for geographic distribution
  • Add bandwidth estimation and adaptive bitrate
  • Monitor server resources and connection health
  • Consider using established SFU solutions like Pion SFU

Running the Example

1

Start the server

2

Connect broadcaster

  1. Open the broadcast page in a browser
  2. Enable your webcam
  3. Generate and copy the offer
  4. Send it via curl:
  1. Copy the answer from terminal and paste in browser
3

Connect viewers

For each viewer:
  1. Open the viewer page in a new browser/tab
  2. Generate and copy the offer
  3. Send via curl (same command as broadcaster)
  4. Copy the answer and paste in browser
  5. Video should start playing
4

Add more viewers

Repeat step 3 for as many viewers as needed. Each viewer receives the same broadcast stream.

Bandwidth Comparison

Mesh (P2P)

For 10 viewers:
  • Broadcaster upload: 10x bandwidth
  • Each viewer: 1x bandwidth
  • Total: 20x bandwidth

SFU (This Example)

For 10 viewers:
  • Broadcaster upload: 1x bandwidth
  • Server processing: Packet forwarding only
  • Total: 11x bandwidth (10x viewer download + 1x upload)
The SFU pattern dramatically reduces broadcaster bandwidth requirements. With 100 viewers, mesh would require 100x upload bandwidth, while SFU still only requires 1x!

Use Cases

  • Live streaming events and webinars
  • Video conferencing (with modifications for multi-publisher)
  • Online education and virtual classrooms
  • Live sports broadcasting
  • Concert and performance streaming