Custom RTMP is the manual way to connect a streaming encoder, such as OBS, to a destination that accepts an encoder feed. You enter the destination’s ingest server URL and stream key rather than selecting a named service preset.
The destination provides those details; OBS does not create them. Before you go live, confirm the required protocol, copy the credentials for the correct broadcast, and test that the destination receives both picture and sound.
What custom RTMP means
RTMP is a protocol used to send a live audio and video feed from an encoder to a receiving service. “Custom RTMP” is not a separate protocol. It is common shorthand for configuring an encoder manually with the server address and key issued by the destination.
Think of the server URL as the address to which OBS sends the feed. The stream key is a credential or identifier that tells the receiving service which account or broadcast the feed belongs to and authorises it to accept the stream. You need the right pair, not a URL and key copied from an unrelated guide or another event.
OBS describes the manual option as “Custom Streaming Server”: you supply the server URL and stream key instead of choosing one of the listed services. The OBS streaming overview explains the service selection flow. The labels can vary in other encoders, but the distinction is the same: a preset may fill in destination details for you, while a custom destination asks you to provide them.
A custom setup is only useful when the receiving service supports an encoder connection using the specified protocol. The word “custom” does not make an unsupported destination compatible, nor does it mean every service accepts RTMP. Follow that destination’s current instructions, including any event, account, codec, or plan requirements.
When to choose a custom destination
Choose the custom option when your destination accepts an encoder feed but is not available as a named preset in OBS, or when the destination’s instructions tell you to enter a URL and key manually. That could be a hosted event, a platform account, a private relay, or another receiving system, provided it explicitly supports the protocol and workflow you intend to use.
A named preset is usually simpler if it is listed in OBS and the destination directs you to use it. A preset can reduce manual entry, but it does not remove the need to check which account or event is selected. Custom entry offers flexibility, but you are responsible for accurately copying the endpoint and key and matching protocol and output requirements.
| Setup route | What you enter or select | Useful when | Check before starting |
|---|---|---|---|
| Named service preset | Select the service and complete any requested account or stream details | OBS includes the destination and its instructions recommend the preset | Confirm the correct account, event, and destination status |
| Custom server | Enter the destination’s server URL and stream key in separate fields | The destination explicitly provides encoder credentials and asks for manual setup | Confirm protocol, event-specific details, output requirements, and key privacy |
Do not choose custom merely because it sounds more advanced. If a platform has a documented preset flow, use the route it recommends unless you have a specific reason to configure the server manually. Conversely, do not assume that a preset for one platform can be adapted to another by changing only the key.
For a 24/7 YouTube channel, it is worth separating the question of where OBS sends a feed from the question of how long your computer must remain on. The article on running a 24/7 story stream without leaving the desktop open discusses the latter problem; custom RTMP itself only describes how an encoder is pointed at a receiving destination.
Where to get the server URL and stream key
Open the destination’s own live control room, event setup, or encoder instructions. Create or select the broadcast there, then copy the current ingest or server URL and the stream key issued for that account or event. The exact page and labels depend on the service, so use its current help documentation rather than guessing from the wording in OBS.
Some destinations may issue a reusable key; others may associate credentials with a particular event or session. Do not assume either arrangement. If you are setting up a scheduled event, verify that the copied details belong to that event and that the destination is ready to receive it. A working key for one account or broadcast may not be valid for another.
Keep the two values in their own fields. The URL identifies the receiving endpoint; the key is the credential. Do not paste both into one field, add quotation marks, or alter punctuation unless the destination’s instructions specifically require it. If a service presents a combined value or a different configuration format, follow its directions rather than forcing it into an RTMP form.
The YouTube Live encoder settings documentation describes YouTube’s stream setup and connection details. Use the server and key shown for your broadcast, and check YouTube’s current protocol guidance before choosing a server variant. A URL example from a guide is not a substitute for the endpoint issued to your own channel.
If you are using a hosted destination, verify that your account or plan includes the live feature you need. For instance, Vimeo’s OBS setup instructions describe its own configuration, but eligibility and product terms can vary. Check the destination’s current terms directly before relying on a feature.
Set up a custom server in OBS
First, make sure OBS is installed and that you have a working video and audio source. A camera, webcam, capture card, or media source is a production choice, not a requirement of custom RTMP as such. OBS’s quick start guide covers adding sources and testing a scene; if your existing source works, you do not need to buy new capture equipment just to enter a server URL and key.
In OBS, open Settings → Stream. In the service selection, choose the custom streaming server option. Enter the destination-provided server URL in the server field and the matching stream key in the key field, then apply the settings. The destination, not OBS, supplies both values. If your interface uses different labels or groups protocol options separately, follow the version of OBS and the destination instructions you are actually using.
Before starting, compare the destination’s requirements with the output you have configured in OBS. Check the protocol, any required endpoint or port, video and audio formats, and any stated bitrate or resolution limits. These values are destination-specific and can change, so do not carry settings over from a different platform or an old tutorial without checking. YouTube, for example, publishes its own live encoder and ingestion guidance; use the current requirements for the receiving service.
When you are ready, start with a low-risk test rather than a public broadcast. If the destination offers private, unlisted, preview, or test modes, use the one appropriate to your situation. Watch the destination’s preview or status as well as OBS: OBS showing that it is sending does not by itself prove that the receiving service has accepted the feed or that viewers will see and hear it.
If your goal is a continuous recorded-video channel rather than a live camera session, choose the production method separately from the destination setup. A guide to streaming a playlist to YouTube Live with FFmpeg is relevant to that workflow, but its encoder commands and assumptions should not be substituted for the URL, key, and protocol instructions issued by your receiving service.
Keep your stream key private
Treat a stream key like a password. Anyone who obtains a valid key may be able to send a feed to the associated destination, so do not publish it in a video, social post, public document, screenshot, or support forum. The Twitch help page on stream keys explains the role of a unique key for its own service; the same basic credential-care principle applies wherever a destination issues a key.
Avoid showing the key while recording a setup tutorial or sharing your OBS settings. If you need help diagnosing a connection, describe the error and share only the non-sensitive information requested by the destination’s support team. Crop or obscure the key before sending a screenshot. Do not paste it into public chat or a public issue report, even if the broadcast is not yet live.
If you believe the key has been exposed, treat it as compromised. Use the destination’s account controls to regenerate, reset, or replace it, then update the encoder with the new value. Exact reset steps differ by platform. A key change can also interrupt a configured stream, so make sure the encoder and event setup use the same current credential before your next broadcast.
Access to an encoder computer matters too. Avoid leaving a settings window with credentials visible when others can use the machine, and be careful when sharing remote access. For a channel run by a small team, decide who is allowed to view or change stream credentials and how you will update them if the people responsible for the broadcast change.
RTMP, secure RTMP, and other ingest protocols
RTMP and RTMPS are related but not identical connection choices. RTMPS carries RTMP over TLS/SSL, which encrypts the connection in transit. Plain RTMP should not be described as encrypted. YouTube recommends RTMPS in its protocol guidance, and Vimeo explains the distinction in its streaming protocol documentation.
Prefer RTMPS when the receiving service offers it and your encoder supports the required configuration. But do not turn a preference into a guess: use the exact protocol and endpoint the destination specifies. If it supplies an RTMP URL, do not rewrite it as RTMPS by changing a few characters. The receiving service must support the chosen protocol, and the correct host, port, and any security settings have to match.
Other ingest protocols are not alternate names for RTMP. HLS and SRT have different connection behaviour and compatibility requirements. YouTube documents HLS ingestion for supported cases, including some workflows where codec needs differ from RTMP; Vimeo also documents SRT alongside RTMP and RTMPS, with its own constraints. See the destination’s protocol requirements and its current documentation before selecting anything beyond the instructed option.
| Protocol choice | What to take from the name | What you should do |
|---|---|---|
| RTMP | A protocol for sending an encoder feed; it is not inherently encrypted | Use it only when the destination specifies and supports it |
| RTMPS | RTMP carried over TLS/SSL for encryption in transit | Prefer it where the destination offers it and your encoder is configured for it |
| HLS or SRT | Different ingest protocols, not interchangeable RTMP labels | Check both destination support and encoder compatibility before using them |
Protocol choice affects more than a dropdown. It can determine which endpoint, port, codec, and encoder settings are appropriate, and what the destination can accept. A protocol that suits one platform or network situation may not suit another. Vimeo notes that SRT has its own compatibility and feature constraints; do not assume it will work with every platform or solve every unstable connection.
Test the connection and troubleshoot basics
A successful setup has two parts: the encoder sends the feed, and the destination receives it in a usable form. Start a test early enough to correct settings without an audience waiting. Check the destination’s preview or health status for both video and audio, then listen and look for the actual content you expect. A moving preview with no sound is not a complete test.
If OBS cannot connect or the destination shows no incoming feed, work through the details rather than changing several settings at once:
- Confirm the selected event or broadcast is active or ready to receive a stream.
- Re-copy the current URL and key from that destination and event; check that each is in the correct field.
- Verify that OBS is using the exact RTMP or RTMPS variant the destination requires, including the expected hostname and port.
- Check whether a copied character, extra space, or stale credential has changed the value.
- Look at the encoder log and the destination’s status message for a clue before trying another configuration.
For YouTube RTMPS, YouTube notes that incorrect server names, ports, or SSL settings can cause connection errors. That makes the endpoint and protocol worth checking before you assume the stream key is wrong. Do not copy a troubleshooting URL from a different platform; each destination’s endpoint is its own instruction.
If the destination receives video but not audio, inspect the audio source and OBS output settings, then check the destination preview or status again. Confirm that the intended microphone, desktop, or media audio is active and that the output is not muted. A picture on the destination does not establish that audio is being sent correctly; verify both before making the stream public.
If the feed connects but drops or becomes unstable, check the network and the destination’s stated output requirements. A weak or interrupted connection can affect an RTMP workflow; a different supported protocol may fit some network conditions, but only if the destination and encoder both support it. No protocol removes the need to test the actual connection at the location and time you plan to broadcast.
For a long-running channel, separate an ingest problem from an interruption later in the broadcast. If you are troubleshooting a YouTube stream that is already running but buffering, this guide to fixing buffering in a 24/7 YouTube music radio stream addresses a different part of the problem. Do not change credentials when the evidence points instead to network capacity, encoding load, or a destination-side issue.
A continuous channel also has an operational question: what happens if the machine running OBS is turned off or loses its connection? StreamNeo turns an uploaded video into a YouTube live stream, so you do not have to keep your own computer running for that file-based broadcast; that removes the specific burden of leaving an OBS machine on overnight. It is YouTube-only, so it is not a general-purpose destination for custom RTMP feeds to other platforms.
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
What does custom RTMP mean?
It means you manually configure an encoder with a destination’s ingest URL and stream key instead of selecting a named service preset. It is not a separate protocol, and it only works when that destination supports the connection method you are using.
How do I add a custom RTMP server in OBS?
Open Settings → Stream, select the custom streaming server option, and enter the destination-issued server URL and stream key in their separate fields. Then check protocol and output requirements against the destination’s current instructions and test the incoming audio and video before broadcasting publicly.
Where do I find my RTMP URL and stream key?
Find them in the receiving service’s live control room, event setup, or encoder documentation. Use the values for the account or event you are setting up; neither OBS nor a guide to another destination supplies the right credentials for your broadcast.
Should I use RTMP or RTMPS?
Use the protocol the destination specifies, and prefer RTMPS when it is offered and supported because it encrypts RTMP in transit. Do not assume that changing RTMP to RTMPS in a URL is enough; the endpoint and encoder configuration must match the receiving service.