SRT & WebRTC: Low-Latency Streaming Server Setup

Why Low Latency Matters: From RTMP to a Self-Hosted WebRTC Streaming Server

To achieve low-latency streaming (hundreds of milliseconds for SRT and sub-second for WebRTC) on a self-hosted server, a VPS requires a minimum of 2 vCPU, 4 GB RAM, software like SRS or MediaMTX, and open UDP ports for stable protocol operation. In today's interactive world, where instant feedback is the norm, traditional video delivery protocols like RTMP often fall short of the increasing demands for minimal latency. Understanding the differences between RTMP, SRT, and WebRTC, along with their proper configuration on your own server, is crucial for building highly efficient streaming solutions.

The Evolution of Streaming Protocols: RTMP, SRT, and WebRTC

The history of video streaming protocols is a journey from maximum compatibility to minimal latency. * **RTMP (Real-Time Messaging Protocol):** Developed by Adobe, RTMP was long the de facto standard for video content delivery. It uses TCP, which ensures reliable, but not always fast, delivery. Typical latency for RTMP is **2-10 seconds**, which is acceptable for traditional broadcasting but completely unsuitable for interactive scenarios such as online conferences or esports. Its simplicity and broad support made it popular for sending streams to platforms like YouTube or Twitch. However, due to high latency and performance issues over HTTP/HTTPS, many browsers have ceased supporting it, and it is gradually being replaced by more modern solutions. * **SRT (Secure Reliable Transport):** This protocol, developed by Haivision, represents a significant step forward in low-latency streaming. SRT is built on UDP but adds a layer of reliability similar to TCP. It includes error correction mechanisms (ARQ - Automatic Repeat Request) and adaptive bitrate adjustment, allowing it to work effectively in unstable networks, recovering lost packets and minimizing latency. SRT can achieve latency in the range of **hundreds of milliseconds (200-800 ms)**, making it ideal for live broadcasts, sports streaming, and other scenarios where delivery speed is critical but high reliability is required. SRT also supports encryption, adding security. * **WebRTC (Web Real-Time Communication):** This is an open standard developed by Google that allows browsers and mobile applications to perform real-time audio, video, and data transmission without installing additional plugins. WebRTC also uses UDP for primary data transfer but focuses on the lowest possible latency — **sub-second (50-300 ms)**. Its key feature is a P2P (peer-to-peer) architecture when possible, or the use of SFU/MCU servers for multiple participants. WebRTC is ideal for video conferencing, online gaming, interactive webinars, and video surveillance, where every millisecond counts.

The Trade-offs of Low-Latency Streaming

The transition to low-latency protocols is not without cost and requires certain compromises: * **Configuration Complexity:** SRT and WebRTC require more complex server setup, including working with UDP ports, NAT, and firewalls, compared to RTMP. * **Server Requirements:** For WebRTC, especially with a large number of concurrent viewers, significantly more powerful CPUs are needed for transcoding and connection management. SRT is less CPU-intensive but more sensitive to network channel quality. * **Compatibility:** RTMP is still widely supported by broadcasting platforms. SRT is gaining popularity but is not as universal as RTMP. WebRTC is natively supported in most modern browsers but requires specialized servers (SFU/MCU) for scaling to a large number of viewers. * **Buffering:** Low latency means less buffering. In the event of brief network issues, this can lead to noticeable artifacts or temporary video interruptions, whereas RTMP, with its larger buffer, can smooth out such moments.

Choosing the Right Protocol: When to Use an SRT Streaming Server vs. a WebRTC Streaming Server

The choice of protocol for your VPS or dedicated server directly depends on your tasks and priorities. Each protocol has its strengths and applications.

SRT: Reliability and Quality for Unstable Networks

SRT is the ideal choice for professional broadcasting where high-quality video transmission with minimal latency is required, even over less-than-ideal communication channels. * **Applications:** * **Sports Broadcasting:** Transmitting signals from event locations to studios or directly to viewers with latency in hundreds of milliseconds. * **Live News Broadcasts:** Rapid transmission of reports from anywhere in the world. * **Broadcasting to Platforms:** If your platform supports SRT, it's an excellent way to send a high-quality, low-latency stream. * **High-Resolution Video Surveillance:** Where minimal latency is crucial for reacting to events. * **Advantages:** Reliable UDP delivery, error correction, adaptive bitrate, encryption. * **Disadvantages:** Requires support on both the source and receiver sides, not native to browsers.

WebRTC: Real-Time Interactivity

WebRTC is designed for situations where maximum interactivity is important, and latency must be virtually imperceptible to human perception. * **Applications:** * **Video Conferencing and Webinars:** Allows participants to communicate in real-time without noticeable delay. * **Online Gaming and Game Streaming:** Transmitting gameplay or screen with minimal latency for interactive engagement. * **Remote Control and Telemedicine:** Sub-second latency is critical for precise actions. * **Interactive Video Surveillance:** Where an operator needs to react instantly to what's happening. * **Advantages:** Ultra-low latency (sub-second), native browser support, P2P capabilities. * **Disadvantages:** High server CPU requirements for a large number of participants (especially for SFU/MCU), complexity in scaling, sensitivity to client network conditions.

RTMP: The Classic for Platform Broadcasting

Despite its latency drawbacks, RTMP remains relevant for certain tasks. * **Applications:** * **Broadcasting to Popular Streaming Platforms (Twitch, YouTube, Facebook Live):** Many of them still accept RTMP streams. * **Traditional Broadcasting:** Where a few seconds of latency is not critical, such as streaming lectures or pre-recorded content. * **Stream Transfer Between Servers:** Internal networks where stability is more important than speed. * **Advantages:** Wide support, ease of setup (for basic tasks), high stability due to TCP. * **Disadvantages:** High latency (2-10 seconds), lack of native support in modern browsers (requires conversion to HLS/DASH for viewing).

Software for a Low Latency Streaming Server: What to Install on Your VPS?

To deploy a low latency streaming server on your VPS, several powerful and flexible solutions are available. The choice depends on the protocols you plan to use and the required functionality.

SRS (Simple Realtime Server): A Universal Solution

SRS is a high-performance, open-source industrial media server written in C++. It supports RTMP, WebRTC, HLS, HTTP-FLV, and, of course, SRT. SRS is an excellent choice for creating a versatile streaming server. * **Features:** * Receiving RTMP/SRT streams, publishing them to WebRTC, HLS, DASH. * SRT support in Listener, Caller, Rendezvous modes. * Transcoding (with ffmpeg). * Scalability and stability. * **Installation Example (Ubuntu):**

sudo apt update && sudo apt upgrade -y
sudo apt install -y git build-essential cmake libssl-dev
git clone -b 5.0 https://github.com/ossrs/srs.git
cd srs/trunk
./configure --with-srt --with-ssl --with-hls --with-dvr --with-transcode --with-webrtc
make -j$(nproc)
sudo make install
./objs/srs -c conf/srs.conf

* **SRT Configuration in `conf/srs.conf` (or a separate file):**

listen              1935;
max_connections     1000;
daemon              off;
srs_log_tank        console;

vhost __default__ {
    srt {
        enabled     on;
        listen      10080; # Port for SRT
        latency     200; # Latency in ms
    }
    rtc_server {
        enabled     on;
        listen      8000; # Port for WebRTC
        candidate   0.0.0.0;
    }
}

MediaMTX (formerly RTMP-to-WebRTC): Lightweight and Fast

MediaMTX (formerly known as RTMP-to-WebRTC) is a modern, lightweight media server written in Go. It focuses on converting RTMP, RTSP, HLS streams to WebRTC, and also supports SRT. It is characterized by low resource consumption and high performance. * **Features:** * Receiving RTMP, RTSP, SRT. * Outputting streams via WebRTC, HLS, RTSP. * Easy configuration. * **Installation Example (Ubuntu):**

wget https://github.com/bluenviron/mediamtx/releases/latest/download/mediamtx_v1.7.0_linux_amd64.tar.gz
tar -xvzf mediamtx_v1.7.0_linux_amd64.tar.gz
cd mediamtx_v1.7.0_linux_amd64
./mediamtx

* **SRT Configuration in `mediamtx.yml`:**

paths:
  all:
    readUser: ""
    readPass: ""
    publishUser: ""
    publishPass: ""

rtmp:
  listen: ":1935"

srt:
  listen: ":8000" # Port for SRT
  readUser: ""
  readPass: ""
  publishUser: ""
  publishPass: ""

webrtc:
  listen: ":8888" # Port for WebRTC
  iceHost: "0.0.0.0"
  iceCandidate: "YOUR_PUBLIC_IP" # Replace with your VPS's public IP

OvenMediaEngine: A Powerful WebRTC Solution

OvenMediaEngine is a comprehensive open-source media server solution optimized for WebRTC. It supports virtually all input and output protocols, including RTMP, SRT, RTSP, WebRTC, HLS, DASH. * **Features:** * Scalability to thousands of concurrent WebRTC viewers. * Automatic transcoding and adaptive bitrate. * DRM, CDN support. * Very rich functionality, but also more complex configuration. * **Installation:** It is recommended to use Docker or their installation script due to dependency complexity. * **Configuration:** Multi-layered, via YAML files for various components.

Janus Gateway: Focus on WebRTC SFU/MCU

Janus Gateway is a versatile open-source WebRTC server focused on creating interactive real-time applications. It acts as an SFU (Selective Forwarding Unit) or MCU (Multipoint Control Unit), making it ideal for video conferencing and interactive broadcasts with a large number of participants. * **Features:** * Support for various plugins for specific tasks (video conferencing, streaming, video calls). * SFU/MCU functionality. * Low latency. * **Installation:**

sudo apt update && sudo apt upgrade -y
sudo apt install -y libmicrohttpd-dev libjansson-dev libnice-dev libssl-dev libsrtp2-dev libsofia-sip-ua-dev libglib2.0-dev libopus-dev libogg-dev libcurl4-openssl-dev libusrsctp-dev libtool automake cmake meson ninja-build
git clone https://github.com/meetecho/janus-gateway.git
cd janus-gateway
sh autogen.sh
./configure --prefix=/opt/janus
make
sudo make install
sudo make configs

* **Configuration:** In `janus.jcfg` and plugin files.

SRT Server Setup and WebRTC Server Streaming: VPS Requirements and Configuration Estimates

Setting up an SRT server or WebRTC server streaming requires a careful approach to VPS configuration. Requirements vary significantly depending on the protocol, the number of concurrent viewers, and the need for transcoding.

Protocol Dependencies: CPU, RAM, and Network Bandwidth

* **SRT Streaming Server:** * **CPU:** Less demanding than WebRTC. The main load is on the network stack and ARQ processing. If no transcoding is involved, 2-4 vCPU are sufficient for hundreds of concurrent streams. If transcoding is required (e.g., from one SRT stream to several with different bitrates), CPU requirements increase significantly. * **RAM:** 4-8 GB is usually enough for most SRT tasks, provided there's no intensive transcoding or a large number of buffers. * **Network Bandwidth:** This is the most critical resource for SRT. A stable channel with high throughput is needed (minimum 1 Gbps, preferably 10 Gbps for large volumes). For a single HD stream, 5-10 Mbps; for 4K, 25-50 Mbps. Multiply by the number of outgoing streams. * **WebRTC Streaming Server:** * **CPU:** This is the primary limiting factor. For each outgoing WebRTC stream, the server needs to perform encoding/decoding, mixing (for MCU), or forwarding (for SFU). The more concurrent viewers and the higher the video quality, the more CPU cores will be required. For SFU (Selective Forwarding Unit), where the server only forwards streams without re-encoding them, the load is lower but still significant. For MCU (Multipoint Control Unit), where the server mixes multiple streams into one, CPU requirements are extremely high. * **RAM:** 8-16 GB and higher. WebRTC servers can consume a significant amount of memory for buffering, storing connection metadata, and, during transcoding, for handling video frames. * **Network Bandwidth:** Also important. Each WebRTC viewer receives their own data stream. For 50-100 HD content viewers, a 1 Gbps channel will be needed. For thousands of viewers, 10 Gbps or a distributed architecture is required. * **General Disk Recommendations:** NVMe SSD is mandatory for any streaming platform. Although video streams are often processed in RAM, a fast disk is needed for the operating system, logs, temporary files, and potentially archive recording. 40-80 GB NVMe will suffice for most servers without archiving.

Table: Optimal VPS Configuration for Low-Latency Streaming

For 50 concurrent viewers, a VPS with 4 vCPU, 8 GB RAM, and an 80 GB NVMe disk is typically sufficient.

Concurrent Viewers (1080p, 5 Mbps)	vCPU	RAM (GB)	Disk (GB, NVMe)	Network Port	Estimated Valebyte Price ($/month)
10-20 (SRT/WebRTC SFU)	2	4	40	1 Gbps	От $10
30-50 (SRT/WebRTC SFU)	4	8	80	1 Gbps	От $25
50-100 (SRT/WebRTC SFU)	6	16	160	1 Gbps	От $50
100-200 (SRT/WebRTC SFU)	8	32	240	10 Gbps	От $90
200-500+ (SRT/WebRTC SFU, distributed)	12-16+	64+	500+	10 Gbps+	От $150 (несколько VPS)
10-20 (WebRTC MCU)	8	16	80	1 Gbps	От $50

*Prices are indicative for Valebyte tariffs as of January 2024 and may vary depending on promotions and region.

Example: Configuring SRS for SRT and WebRTC

To demonstrate how to set up an SRT server and WebRTC server streaming on a VPS, we'll use SRS. Assume you have a clean Ubuntu 22.04 VPS. 1. **Install SRS (as shown above):**

sudo apt update && sudo apt upgrade -y
sudo apt install -y git build-essential cmake libssl-dev
git clone -b 5.0 https://github.com/ossrs/srs.git
cd srs/trunk
./configure --with-srt --with-ssl --with-hls --with-dvr --with-transcode --with-webrtc
make -j$(nproc)
sudo make install

2. **Configure SRS for SRT and WebRTC:** Edit `conf/srs.conf`. Find the `vhost __default__` section and ensure it looks approximately like this:

# Minimal SRT/WebRTC config for SRS
listen              1935; # RTMP
max_connections     1000;
daemon              off;
srs_log_tank        console;

vhost __default__ {
    srt {
        enabled     on;
        listen      10080; # Port for receiving SRT streams
        latency     200; # Latency in ms
        # max_bw_mbps 100; # Max bandwidth for SRT
    }
    rtc_server {
        enabled     on;
        listen      8000; # Port for WebRTC signaling server
        candidate   0.0.0.0; # Or your public IP address
    }
    # Allow RTMP publishing (e.g., from OBS)
    # And viewing via WebRTC
    dvr {
        enabled on;
        dvr_path ./objs/dvr/[app]/[stream]/[date].flv;
    }
}

Replace `0.0.0.0` with your public IP address if you encounter NAT issues. 3. **Launch SRS:**

./objs/srs -c conf/srs.conf

To run in the background, use `nohup ./objs/srs -c conf/srs.conf &`. 4. **Publish an SRT Stream:** Use OBS Studio or ffmpeg to send an SRT stream to your server. * **OBS Studio:** Settings -> Stream -> Service: Custom. Server: `srt://YOUR_PUBLIC_IP:10080/live/stream` (or `srt://YOUR_PUBLIC_IP:10080?mode=listener`). Stream Key: `stream`. * **ffmpeg:**

ffmpeg -i input.mp4 -c:v libx264 -preset veryfast -b:v 3000k -maxrate 3000k -bufsize 6000k -c:a aac -ar 44100 -b:a 128k -f srt "srt://YOUR_PUBLIC_IP:10080?streamid=live/stream"

5. **View the WebRTC Stream:** SRS provides a web interface for WebRTC viewing. Open `http://YOUR_PUBLIC_IP:8080/players/rtc_player.html` in your browser. Enter `webrtc://YOUR_PUBLIC_IP:8000/live/stream` in the URL field and click Play.

Network Configuration: Ports, UDP, NAT, and Firewall

Proper network configuration is a key aspect for the stable operation of an SRT streaming server and WebRTC streaming server. Both protocols actively use UDP, which requires special attention to firewalls and NAT.

Opening Ports for SRT and WebRTC

For SRT and WebRTC, you need to ensure that the corresponding ports are open on your VPS. * **SRT:** Uses a single UDP port for data transmission. This is typically `10080` (as in the SRS example) or any other you choose. * **WebRTC:** More complex. It uses several ports: * **Signaling Server:** Usually TCP port `8000` (for SRS) or `8888` (for MediaMTX) for exchanging connection metadata. * **RTP/RTCP (Media Data):** A wide range of UDP ports. WebRTC attempts to establish a direct P2P connection, but if it fails, media data passes through an SFU/MCU server. A range of 200-300 ports is usually allocated, for example, `10000-12000` UDP. **Example of opening ports with UFW (Uncomplicated Firewall) on Ubuntu:**

sudo ufw allow 1935/tcp  # For RTMP (if used)
sudo ufw allow 10080/udp # For SRT
sudo ufw allow 8000/tcp  # For WebRTC signaling server (if SRS)
sudo ufw allow 8888/tcp  # For WebRTC signaling server (if MediaMTX)
sudo ufw allow 10000:12000/udp # For WebRTC media data (range)
sudo ufw enable
sudo ufw status verbose

If you are using `firewalld` (e.g., on CentOS/RHEL):

sudo firewall-cmd --zone=public --add-port=1935/tcp --permanent
sudo firewall-cmd --zone=public --add-port=10080/udp --permanent
sudo firewall-cmd --zone=public --add-port=8000/tcp --permanent
sudo firewall-cmd --zone=public --add-port=10000-12000/udp --permanent
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

NAT Issues and Their Solutions

NAT (Network Address Translation) can cause problems with UDP protocols because it modifies IP addresses and ports, making it difficult to establish direct connections. * **STUN/TURN Servers:** * **STUN (Session Traversal Utilities for NAT):** Helps clients determine their public IP address and port so they can communicate it to other participants. Most WebRTC servers have built-in STUN support or allow you to specify an external STUN server (e.g., `stun.l.google.com:19302`). * **TURN (Traversal Using Relays around NAT):** If a direct P2P connection is not possible due to strict NAT restrictions (e.g., symmetric NAT), a TURN server acts as a relay through which all media data passes. This increases latency and server load but ensures reliable delivery. For WebRTC servers like Janus or OvenMediaEngine, configuring your own TURN server is often necessary if you expect clients behind complex NATs. * **Public IP Address:** Always use your VPS's public IP address in server configurations (e.g., `candidate` in SRS or `iceCandidate` in MediaMTX) so that the server correctly advertises its network details.

Firewall Configuration (UFW/firewalld)

In addition to opening ports, ensure that your firewall does not block outgoing UDP connections that may be required for STUN/TURN or for SRT feedback (e.g., ARQ packets). Regularly check firewall logs if connection problems arise to ensure that traffic is not being blocked.

Common Problems and Diagnostics for Low-Latency Streaming

When working with a low latency streaming server, problems inevitably arise. It is important to know how to diagnose and resolve them to ensure uninterrupted operation.

How to Reduce High Stream Latency: A Checklist

If you observe that stream latency is higher than expected, go through the following checklist: 1. **Protocol:** Make sure you are actually using SRT or WebRTC, not RTMP or HLS, which inherently have higher latency. 2. **Server Settings:** * **SRT:** Check the `latency` parameter in your SRT server's configuration (e.g., in SRS). It should be set to a low value (e.g., 200-400 ms). Ensure that the SRT `mode` (listener, caller, rendezvous) matches your scenario. * **WebRTC:** Make sure your WebRTC server (SRS, MediaMTX, Janus) is correctly configured and not using transcoding if it's not required. Transcoding always increases latency. 3. **Source Settings (OBS/ffmpeg):** * **Buffer:** Reduce buffers in OBS Studio or ffmpeg. For example, for OBS: Settings -> Output -> Advanced -> Stream Delay. For ffmpeg: ` -bufsize` and ` -probesize` parameters. * **Keyframe Interval (GOP):** Set a low keyframe interval (e.g., 1-2 seconds). `keyint=1s` or `g=30` (for 30 fps). * **Encoder Profile/Preset:** Use faster presets (e.g., `veryfast` or `ultrafast` for x264/x265), which reduce CPU load but may slightly degrade quality at the same bitrate. 4. **Network Conditions:** * **Bandwidth:** Ensure you have sufficient bandwidth on both the source side and the VPS. Insufficient bandwidth will lead to packet loss and re-requests, increasing latency. * **Ping/Network Latency:** Measure ping between the source and VPS, and between the VPS and the viewer. High ping directly affects the minimum achievable latency. * **Packet Loss:** Even a small percentage of packet loss (more than 0.5-1%) can significantly increase latency, especially for SRT. Use tools like `iperf3` for diagnostics. 5. **Server Load:** * **CPU:** Check CPU utilization on the VPS (`htop`, `top`). If the CPU is constantly at 90-100% load, this can cause delays, especially for WebRTC. Scale up your VPS or optimize the configuration. * **RAM:** Insufficient RAM can lead to swapping, which slows down server operation. 6. **Firewall/NAT:** Ensure all necessary ports are open and there are no NAT issues that might force traffic to take a longer route (through TURN servers).

Connection and Video Quality Issues

* **Unable to connect to the server:** * Check if the media server (SRS, MediaMTX, etc.) is running. * Check server logs for errors. * Ensure ports are open on the VPS firewall. * Verify the IP address and port in the connection URL. * **Video interrupts, freezes, or has artifacts:** * **Low bitrate/high compression:** Increase the bitrate or decrease the compression level at the source. * **Packet loss:** Check network stability between the source and server, and between the server and viewer. Use `ping`, `mtr` for diagnostics. * **Server overload:** Too many concurrent streams or intensive transcoding can overload the server's CPU or network channel. * **Incorrect encoding settings:** Ensure encoding settings (profile, level, B-frames) are compatible with your clients. * **Audio/video desynchronization:** * This often occurs due to encoding issues at the source or an unstable network. Check audio and video bitrate, sample rate settings. * Restarting the source and server sometimes helps.

Frequently Asked Questions

How many vCPUs are needed for WebRTC streaming with 50 concurrent viewers?

For WebRTC streaming with 50 concurrent viewers in SFU (Selective Forwarding Unit) mode, at least 4-6 vCPUs are required. If you are using MCU (Multipoint Control Unit) mode, which demands transcoding and mixing multiple streams into one, then 50 participants may require 8 vCPUs or more, depending on the resolution and bitrate of the streams.

Can RTMP be used for low-latency streaming?

RTMP is not designed for low-latency streaming. Its typical latency is 2-10 seconds due to its use of TCP and buffering mechanisms. To achieve latency in the range of hundreds of milliseconds or sub-second, you must use SRT or WebRTC protocols, which are optimized for speed and operate over UDP.

Which firewall ports need to be opened for SRT and WebRTC?

For SRT, one UDP port, such as 10080, typically needs to be opened. For WebRTC, a TCP port for the signaling server (e.g., 8000 or 8888) and a wide range of UDP ports for media data, usually 200-300 ports in the 10000-12000 range, must be opened. This enables direct connections and NAT traversal.

How can I reduce stream latency if I'm using SRT?

To reduce SRT stream latency, ensure that the `latency` parameter in your SRT server's configuration is set to the minimum acceptable value (e.g., 200-400 ms). Network channel stability is also critical: the less packet loss and jitter, the lower the latency can be set without quality degradation. Check the buffer settings on the source side.

Why does WebRTC require more CPU than SRT?

WebRTC often demands more CPU because it is designed for interactive, two-way communication and may involve transcoding, mixing streams (in MCU mode), or managing numerous simultaneous P2P connections. SRT, on the other hand, primarily focuses on reliable unidirectional transmission of high-quality video, and its CPU load is lower if transcoding is not required.

Conclusion

The choice between SRT and WebRTC for low-latency streaming on your own server depends on your project's specific requirements: SRT is ideal for reliable delivery of high-quality video over unstable channels with latency in hundreds of milliseconds, while WebRTC is indispensable for interactive applications where sub-second latency is critical. For most low-latency tasks, a VPS with 4-8 vCPU, 8-16 GB RAM, and an NVMe disk will suffice, but scaling to hundreds and thousands of viewers will require a more powerful dedicated server or a cluster of several VPS instances with a 10 Gbps network port.