RTMP Ingest: How to Set Up a Streaming Server

RTMP ingest is the step where an encoder such as OBS Studio, a hardware encoder or FFmpeg pushes a live stream to a server. The server accepts it and then records, relays or repackages it for viewers. This guide covers running your own RTMP ingest server with nginx and the RTMP module, and how to confirm that it receives a usable stream.

Before you start

First decide where ingest will happen. A streaming platform runs its own ingest servers and only gives you a server address and a stream key. In that case you need no server setup and can skip to the encoder settings. A self-hosted ingest server runs on a machine you control, either on your local network or on a remote host. You install and maintain it yourself.

• A Linux machine or virtual server where you can install packages and edit configuration files with administrator rights.
• nginx with the RTMP module. The module is not part of standard nginx. On Debian and Ubuntu it is usually packaged as a dynamic module named libnginx-mod-rtmp. On other systems you may need to build nginx with the module.
• TCP port 1935 reachable from the encoder. This is the default RTMP port, so check the host firewall and any router or cloud security rules.
• An encoder that can send RTMP, such as OBS Studio or FFmpeg.
• Enough upload bandwidth on the encoder side for the bitrate you plan to send.

Plain RTMP is not encrypted, so the stream key and the media travel in clear text. If the encoder and server communicate over the public internet, consider RTMPS, a VPN or a private network. Check which of these your server software actually supports before relying on them.

Step-by-step instructions

• Install nginx and the RTMP module with your distribution's package manager, or build it from source if no package exists.
• Back up the main nginx configuration file before editing it. Restoring that copy undoes the change.
• Add a top-level rtmp block. Do not put it inside the http block. Inside the rtmp block, add a server block with listen 1935 and an application block named, for example, live. In the application block, set live on to accept live streams and record off to skip writing files to disk.
• Restrict who can publish. Inside the application block, add allow publish followed by your encoder's IP address, then deny publish all. If encoders use changing addresses, use the module's on_publish callback to validate stream keys through your own HTTP endpoint instead.
• Run nginx -t to check the configuration syntax, then reload nginx. If the test fails, fix the reported line or restore the backup.
• Open TCP port 1935 in the firewall for the encoder's address only, rather than for everyone, where possible.
• In OBS Studio, open Settings, then Stream, and choose Custom as the service. In Server, enter the rtmp scheme followed by your server's IP address or host name and the application name, for example live. In Stream Key, enter any name you choose; it becomes the stream's identifier within that application.
• Set the encoder to H.264 video and AAC audio, which classic RTMP servers expect. Use a keyframe interval of about 2 seconds and a bitrate your upload connection can sustain.
• Start streaming and watch the encoder's status for connection errors or dropped frames.

Newer encoders, including recent OBS Studio versions, can send HEVC or AV1 over Enhanced RTMP. The classic nginx RTMP module was built around H.264 and AAC. Use the newer codecs only if your server software documents support for them.

Other ingest servers, such as SRS or MediaMTX, follow the same model of an application path plus a stream key. Their configuration syntax and default settings differ, so follow their own documentation.

Check the output

The simplest check is to play the stream back from another device while the encoder is live. In VLC, open a network stream and enter the same server address, then a slash and the stream key. With FFmpeg installed, run ffplay or ffprobe on that same address. ffprobe lists the video codec, resolution, frame rate and audio format, so you can confirm they match your encoder settings.

• Picture and sound both play: ingest is working.
• Playback starts after a long delay: some delay is normal for RTMP. A long keyframe interval increases the wait before the first frame appears.
• Audio but no video, or the reverse: check that the codecs are ones the server and player support.
• The nginx error log shows publish or play errors: compare the application name and stream key with the encoder settings.

An ingest server passes the stream through as received unless you configure transcoding. Quality, resolution and bitrate therefore depend on the encoder. Many browsers cannot play RTMP directly. For viewers in a browser, the server usually has to repackage the stream, for example into HLS, which requires additional configuration.

Common problems and next steps

• Failed to connect: confirm that nginx is running and listening on port 1935. Check that firewalls allow the encoder's address, and that the server field uses the correct host and application name.
• Connection drops immediately after starting: an allow or deny publish rule or an on_publish check may be rejecting the encoder. The nginx error log usually shows the reason.
• Dropped frames in the encoder: the upload connection cannot sustain the bitrate. Lower the bitrate or resolution, or use a wired connection.
• Stream plays locally but not remotely: the port is probably open only on the local network. Check port forwarding or cloud firewall rules.
• No playback in a web page: RTMP is an ingest protocol here. Add HLS or another browser-compatible output on the server.

Choose between a platform's ingest server and your own based on what happens after ingest. If the stream only goes to one platform, its ingest server is simpler and handles delivery to viewers. A self-hosted RTMP ingest server is useful for recording, relaying one input to several destinations, or processing the stream before publishing. In that case you are responsible for its security, updates and capacity.