Simple Realtime Server (SRS) For RTMP Streaming | Original

Home PDF

Let’s dive into using Simple Realtime Server (SRS) to deploy an edge server for RTMP streaming, with a focus on understanding and configuring it effectively, including the rtmp.conf file. SRS is a powerful, high-performance media server designed for real-time streaming protocols like RTMP, HLS, and HTTP-FLV. It’s particularly well-suited for scenarios requiring scalability, such as content delivery networks (CDNs), where an edge server can efficiently distribute streams to many clients while fetching content from an origin server. I’ll walk you through the process step-by-step, explain the edge deployment concept, and clarify how to work with configurations like rtmp.conf.

What is SRS and Edge Deployment?

SRS is an open-source server built to handle real-time media streaming with a focus on simplicity and efficiency. It supports RTMP (Real-Time Messaging Protocol) for low-latency live streaming, alongside other protocols like HLS and WebRTC. In SRS, an “edge” server acts as an intermediary between clients (viewers or publishers) and an “origin” server (where the stream originates). The edge fetches streams from the origin only when requested by clients, reducing the load on the origin and enabling scalable distribution—think of it like a CDN’s caching layer tailored for live streams.

Deploying an edge server with SRS is ideal when you need to:

Step-by-Step: Deploying an Edge Server with SRS for RTMP

Here’s how to set up SRS as an edge server for RTMP streaming. I’ll assume you’re working on a Linux system (e.g., Ubuntu), as SRS is optimized for such environments.

1. Install SRS

First, you’ll need to get SRS running on your machine:

2. Understand the Edge Concept

In SRS, an edge server operates in “remote” mode, meaning it doesn’t generate streams itself but pulls them from an origin server when a client requests them (for playback) or pushes streams to the origin (for publishing). This on-demand fetching is what makes edge servers efficient for scaling RTMP delivery.

For this example, let’s assume you have an origin server already running SRS at 192.168.1.100:1935 (replace this with your actual origin IP).

3. Configure the Edge Server

SRS uses configuration files to define its behavior. The default srs.conf is a good starting point, but for edge deployment, you’ll create a specific config—let’s call it edge.conf. Here’s how to set it up:

4. Start the Edge Server

Run SRS with your edge config:

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

Check the logs (./objs/edge.log) to confirm it’s running and connected to the origin.

5. Test the Setup

6. Exploring rtmp.conf

SRS doesn’t ship with an rtmp.conf file by default, but you might encounter references to it in tutorials or custom setups. It’s essentially a naming convention for an RTMP-specific config file. For example, the SRS documentation (ossrs.net) provides a sample rtmp.conf for real-time RTMP streaming:

listen              1935;
max_connections     1000;
vhost __defaultVhost__ {
    tcp_nodelay     on;
    min_latency     on;
    play {
        gop_cache   off;
        queue_length 10;
    }
    publish {
        mr          off;
    }
}

For an edge, you’d combine this with the cluster settings rather than using it standalone.

Explaining More: Edge Mechanics and RTMP

Tips and Troubleshooting

Wrapping Up

Deploying an SRS edge server for RTMP is straightforward once you grasp the origin-edge relationship. The edge.conf sets up the edge to fetch or push streams dynamically, while an rtmp.conf-style config could fine-tune RTMP performance if needed. With this setup, you’re ready to scale live streaming efficiently—whether for a handful of viewers or a global audience. Want to tweak it further or integrate HLS alongside RTMP? Just let me know!


Back 2025.04.02 Donate