An RTMP server receives a live stream from an encoder such as OBS, then makes that stream available for reading, forwarding, recording, or conversion. It is the receiving part of a live-stream system, not automatically the service that delivers video efficiently to every viewer.
To set one up, run a media server that listens for RTMP, publish to its address and stream path, and then check the output using a suitable playback protocol. A small Docker example can prove that the connection works, but a public, always-on channel also needs authentication, TLS, firewall decisions, monitoring, storage, and a plan for viewer delivery.
What an RTMP server does
RTMP, or Real-Time Messaging Protocol, was designed to carry live audio and video between a publisher and a media server. The publisher might be OBS, FFmpeg, a camera encoder, or another streaming application. The server accepts that incoming connection and associates it with a stream path.
That path gives the stream an address within the server. A simple example might use live/livestream, while another server may use a single path such as mystream. The exact arrangement depends on the software and its configuration, so do not assume that a URL copied from one server will work unchanged on another.
Once a stream arrives, the server can perform several jobs:
- accept a publication from an encoder
- let another application read the stream
- forward the stream to another server or platform
- record the incoming media
- convert it into another protocol or format
- authenticate publishers and viewers
MediaMTX describes this broader role as publishing, reading, proxying, recording, playback, and protocol conversion. Its official introduction is useful because it presents a media server as a routing point rather than merely a place where viewers connect.
For a YouTube channel, the RTMP server may sit between your encoder and YouTube. OBS publishes to your server, and the server forwards or republishes the stream to YouTube. Alternatively, the server may receive a feed from a camera and make that feed available through HLS or WebRTC to a separate audience. These are different jobs even when one application performs them.
The server does not create the content. It also does not guarantee that the stream will reach YouTube, that viewers will see a particular resolution, or that a long-running channel will recover from every failure. Those outcomes depend on the encoder, network, server configuration, destination platform, and monitoring around the system.
Ingest is not viewer delivery
The most important distinction is between ingest and delivery.
Ingest is the path from the source to the media server or platform. OBS captures your desktop, camera, devotional playlist, or ambient video and sends it to an ingest address. RTMP remains common here because encoders support it and because it provides a practical contribution path.
Viewer delivery is the path from the media system to the audience. A viewer may watch through a browser, mobile app, smart television, or a platform player. Those devices and networks may be better served by HLS, WebRTC, HTTP-FLV, HTTP-TS, or another delivery method, depending on latency, compatibility, and distribution requirements.
The SRS documentation describes RTMP as useful for contribution and identifies HLS as broadly supported, with several seconds of latency in its general guidance. It also discusses WebRTC and other protocols for lower-latency delivery. Treat that as project guidance rather than a universal performance measurement: the result depends on encoding, buffering, network conditions, and the player.
| Part of the pipeline | Typical question | Possible technology | Main trade-off |
|---|---|---|---|
| Source capture | How do I create the live feed? | OBS, FFmpeg, camera encoder | Capture quality and local reliability |
| Ingest | How does the server receive it? | RTMP or RTMPS | Encoder support, security, network exposure |
| Internal routing | How do I move or transform it? | Media server routes, forwarding, transcoding | Configuration and resource use |
| Viewer delivery | How do audiences watch? | HLS, WebRTC, HTTP-FLV, platform delivery | Compatibility, latency, and distribution complexity |
If your aim is to send a bhajan loop or lofi visual to YouTube, YouTube is the viewer-delivery platform. You normally use its current stream URL and key as the destination for an encoder or relay. If you are building your own player for a private audience, you must make a separate delivery choice instead of assuming that exposing an RTMP port is enough.
This separation also helps with troubleshooting. If OBS cannot publish, investigate the source, address, port, credentials, firewall, and server logs. If OBS publishes successfully but a browser cannot play the stream, the problem may be the delivery protocol or player rather than RTMP ingest.
Before changing protocols, check the practical settings of the source. The bitrate guide for long-run streams explains why a stable, suitable output often matters more than choosing a more elaborate server arrangement.
What a small self-hosted setup involves
A minimal self-hosted setup has four parts: a machine to run the media server, media-server software, a reachable network path, and a publisher such as OBS.
Start by deciding whether the server is local or public. If OBS and the server run on the same machine, localhost can refer to the server. If OBS runs on a laptop and the server runs on another computer, you need the server's local network address. If the publisher is outside your home or office network, the server needs a reachable address and a network configuration that permits the intended connection.
You then choose software according to the work it must do. Useful comparison questions include:
- Which ingest protocols can the software accept?
- Can it forward or convert the stream?
- Can you require authentication for publishing and reading?
- Does it record the incoming feed?
- Which delivery protocols can it provide?
- How will you monitor failures and restart the process?
- Can it run in the environment you can maintain?
MediaMTX and SRS are examples of projects with official documentation for this type of work. They are not interchangeable recipes. Their paths, configuration files, ports, authentication methods, and TLS settings can differ, so follow the documentation for the version you install.
For a local proof of concept, SRS documents this Docker command pattern:
docker run --rm -it -p 1935:1935 ossrs/srs:5 \\
./objs/srs -c conf/rtmp.conf
The command publishes port 1935 from the container and starts SRS with an RTMP configuration. SRS also documents a sample publishing address of rtmp://localhost/live/livestream. The useful lesson is the relationship between the listening port, the server address, and the application and stream name.
Do not treat this command as a production deployment. It is a quick way to test whether a server can start and accept a local stream. It does not, by itself, decide who may publish, protect the endpoint with encryption, provide a durable service manager, define capacity, configure backups, restrict public access, or create a viewer-delivery strategy.
A first test should therefore be deliberately small. Run the server on a machine you control, publish a short local source, and confirm that the server sees the stream. Read the software's logs while testing. Record the exact address that worked, whether a key was required, and which playback method confirmed the result.
If you need a public server, write down the intended traffic before opening ports. Decide who is allowed to publish, whether viewers connect directly, whether the stream is forwarded to YouTube, and what happens when the publisher disconnects. For a 24/7 channel, also decide where the source restarts after a reboot and who receives an alert when the feed has stopped.
Connect OBS to the server
In OBS, open the stream settings and choose a custom service or custom server arrangement. The fields normally represent a server address and a stream key, although the exact names vary by application and server.
A URL has several parts:
rtmp://host:port/application/path
The scheme is rtmp://. The host is a name or IP address. The port is optional when the software uses its default. The remaining part identifies an application, path, or stream name. Some systems also expect a separate stream key, while others include the full path in the server field and leave the key empty.
MediaMTX's OBS example uses rtmp://localhost/mystream as the custom server and leaves the stream-key field empty. In that arrangement, the path is mystream. This is a documented example for that software, not a universal OBS rule.
Use this sequence for a first connection:
- Start the media server and confirm that it is listening.
- Copy the address and path required by that server's documentation.
- Enter the server address in OBS.
- Enter a stream key only if the server expects one.
- Start streaming in OBS.
- Check the server log or status page for a new publisher.
- Test the stream through the server's documented read or playback method.
If the server and OBS are on different machines, replace localhost with the server's reachable address. A common mistake is to copy a local example unchanged. localhost always means the machine on which the publishing application is running, not automatically the computer where the media server is installed.
When publishing remotely, check the route in stages. First confirm that the server is running. Then check whether the listening port is reachable from the publisher's network. Next check authentication and the path. Finally check the media itself. A connection can be accepted while the output remains unusable because of an unsupported codec, missing audio, an invalid keyframe arrangement, or a server-side conversion problem.
OBS settings still matter after the connection works. For a YouTube destination, use the platform's current guidance for resolution, bitrate, keyframes, and supported formats. The YouTube settings guide for 1440p and 60fps covers the destination side, while your self-hosted server may have separate limits or conversion requirements.
For a long-running channel, test the complete path rather than only the first connection. Leave the source running long enough to expose network drops, confirm what happens when OBS stops, and check whether a restart produces a second publisher cleanly. A local success lasting a few minutes does not establish that an unattended overnight setup will recover correctly.
Where RTMPS matters
RTMPS is RTMP carried over an encrypted TLS connection. YouTube describes it as the secure extension of RTMP and provides guidance for encoders that need a server URL rather than a built-in YouTube preset. Use the YouTube Help guidance for RTMPS when configuring a YouTube destination, because platform endpoints and instructions can change.
The distinction is practical. With plain RTMP, the connection is not protected by TLS. With RTMPS, the connection between the publisher and the endpoint is encrypted, subject to correct certificate and hostname validation. Encryption does not authenticate your content by itself, and it does not protect other parts of the pipeline that use different protocols.
A simplified RTMPS address looks like this:
rtmps://host:port/application/path
MediaMTX documents an OBS arrangement using an address such as rtmps://localhost:1936/mystream, together with a server configuration that allows RTMP encryption. Its guidance also notes that OBS expects a publicly trusted certificate in that arrangement. A self-signed certificate may be rejected unless the publisher machine has been configured to trust the local certificate authority and the certificate has been validated correctly.
That certificate detail is easy to miss during a first test. A plain RTMP connection may work locally, while the RTMPS version fails because the certificate name, trust chain, port, or server configuration is wrong. Read the current documentation for the software version you are using before copying exact configuration keys.
For a public endpoint, decide whether unencrypted RTMP should be exposed at all. You may use RTMP on a controlled internal network and RTMPS for a connection crossing an untrusted network, but the correct choice depends on your threat model, software support, and how the stream is forwarded. Also remember that RTMPS encrypts the connection; it does not replace publisher authentication, access controls, monitoring, or safe handling of stream keys.
Why the Docker example is not production-ready
A sample container command answers one narrow question: can this software start with a basic RTMP listener? Production operation asks several harder questions that the command leaves open.
Identity and access. Decide who can publish and whether a random person who discovers the address can read the stream. Use the authentication features documented by the chosen server. MediaMTX documents internal, HTTP, and JWT-based authentication options, but the right method depends on the rest of your system.
Network exposure. Publishing port 1935 from a container does not define a safe firewall policy. You still need to decide which addresses may reach it, whether the port is exposed to the public internet, and whether RTMPS uses a separate listener. Only expose the protocols needed for the intended path.
TLS and certificates. If publishers connect through RTMPS, provision and renew a certificate that the client trusts. Test renewal before the current certificate expires. A certificate that is valid on one machine may not be trusted on another.
Persistence and restarts. A command run interactively is not an unattended service plan. Decide how the server starts after a host reboot, how configuration is stored, and whether recordings need persistent storage. A container that exits can leave the channel offline unless an appropriate restart and alerting arrangement exists.
Capacity. The number of publishers and viewers, the output protocols, recording, transcoding, forwarding, and bitrate all affect resource use. The sample proves no performance limit. There is no fair conclusion about capacity without testing the exact software, configuration, media, network, and expected load.
Observability. You need more than a green process. Watch for publisher disconnects, authentication failures, dropped connections, storage problems, and forwarding failures. Keep logs long enough to investigate an overnight interruption, while avoiding accidental exposure of stream keys or other credentials.
Delivery. An RTMP listener is not automatically a browser player or a CDN. If your own viewers will connect, configure a suitable delivery protocol and player. If YouTube is the destination, test the forwarding or publishing path to YouTube separately from local ingest.
The safer progression is to use the Docker example for a local proof of concept, then write down the production requirements before changing the endpoint from private to public. For a channel owner who does not want to maintain a reachable server, certificates, restarts, and monitoring, a managed route may remove that operational work. StreamNeo removes the need to keep your own computer running for a YouTube-only uploaded-video stream, while you still need to prepare the file, stream key, and channel settings correctly.
Choosing the right arrangement for a 24/7 channel
Self-hosting is most useful when you need control over the ingest path, forwarding, recording, protocol conversion, or a private audience. It also gives you responsibility for every layer. That can be a sensible choice for a technical team, but it may be an unnecessary maintenance burden for a small devotional, study, or ambience channel whose main destination is YouTube.
Ask these questions before choosing:
- Is the source live, or is it a prepared file or playlist?
- Does one encoder publish locally, or do remote contributors need access?
- Is YouTube the only audience, or do you need your own player?
- Do you need RTMPS from the publisher to the server?
- Must the server forward, record, transcode, or only receive?
- Who will respond when the stream stops at night?
- Can you test certificate renewal, reboots, and network loss before launch?
For a local OBS-to-server test, keep the design simple: one publisher, one path, one playback check, and clear logs. For a public service, add authentication and TLS before inviting remote publishers. For a YouTube relay, verify the destination separately and make sure you understand which component is responsible for restarting the feed.
A prepared 24/7 stream often has a different operational shape from a live camera. If the source is a finished video, a managed upload-and-stream workflow may be easier than operating an RTMP server solely to relay the file. If you are comparing workflows rather than protocols, the guide to running archived broadcasts to YouTube Live gives a relevant example of the source and destination decisions.
Do not use a server choice to solve a content or platform problem. You still need to check music rights, channel policies, stream settings, and what happens when the source ends. The restart guide for a YouTube bhajan stream focuses on one of the failures that matters most to an unattended channel: reconnecting after a break rather than assuming the first successful publish will continue indefinitely.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Is an RTMP server the same as YouTube Live?
No. An RTMP server receives or routes a contribution stream, while YouTube Live is a platform that ingests the stream and delivers it to viewers through YouTube's systems. You can publish from an RTMP server to YouTube, but the two roles are not interchangeable.
Can I run an RTMP server on the same computer as OBS?
Yes, for a small local test, provided the software can run and the machine has enough resources for both tasks. Use localhost only in that same-machine arrangement. A public or unattended setup needs additional work around access, TLS, restarts, monitoring, and capacity.
Does RTMPS make the whole stream secure?
RTMPS encrypts the connection on which it is used. It does not automatically secure later forwarding, viewer delivery, stored recordings, credentials, or other links in the pipeline. Check each connection separately and use authentication as well as encryption where appropriate.
Can I use the sample Docker command for a public 24/7 channel?
Use it as a local starting point, not as a production recipe. A public channel needs a deployment plan covering authentication, firewall rules, certificates, persistence, restarts, monitoring, delivery, and expected load.