A custom RTMP stream connects an encoder such as OBS to a destination using the ingest URL and stream key that destination provides. Get both from the destination’s live dashboard, enter them in the matching encoder fields, then confirm the destination reports that it is receiving video.
The details are not interchangeable: a URL or key copied from another service, event or channel may fail even if it looks plausible. Prefer RTMPS when the destination supplies and supports it, and follow that destination’s own requirements for video settings and connection checks.
What a custom RTMP destination needs
The destination must accept an encoder connection and provide two values: an ingest or server URL, and a stream key. The URL identifies where the encoder should send the stream; the key identifies or authorises the specific stream at the destination. Some services expose them when you create a live event or input, while others provide persistent or reusable credentials through their live dashboard. The screens and credential lifetime vary by service.
Think of the URL as the delivery address and the key as the credential for that delivery. You need the pair issued for the destination and input you intend to use. A URL found in a forum post, a key from an earlier event, or a remembered address from a different platform is not a safe substitute. Do not assume that two destinations which both use RTMP accept the same endpoint format.
You will also need an encoder that can send to the supplied protocol and endpoint, along with audio and video sources. OBS is a common software encoder, but the steps are similar in other encoders: select the destination or custom server option, enter the credentials, set output properties accepted by the destination, and start sending. The destination’s incoming status—not merely a “streaming” indicator in the encoder—is the evidence that the connection reached the service.
RTMPS is RTMP carried over a TLS/SSL connection, which encrypts the connection. If the destination offers RTMPS and your encoder supports it, use the secure endpoint it supplies. YouTube’s RTMPS guidance recommends using the secure stream URL. This does not mean every platform uses the same URL, port, or exact setup; use the values shown for your own destination.
Before you begin, decide which event or input you are configuring and keep its dashboard open. If you are broadcasting a prerecorded loop, remember that this setup only covers getting the encoder connected; source selection and continuous operation are separate concerns. For example, this guide to running a nonstop YouTube stream with OBS on a Windows cloud PC covers a broader operating arrangement.
Find the server URL and stream key
Sign in to the platform where you want viewers to watch, then create or select its live event, input, or broadcast. Look for a section labelled live settings, encoder settings, ingest settings, or similar. Copy the server or ingest URL and stream key from that exact destination. If the destination offers multiple URLs or protocols, note which one you selected and check that the encoder can use it.
For YouTube, open Live Control Room and go to the stream settings for the event. YouTube may show an ordinary RTMP URL and provide an RTMPS URL as well; its instructions describe revealing and copying the RTMPS URL. Select a YouTube preset in the encoder if available, or copy the appropriate URL and key from that event’s settings. Do not paste an ordinary RTMP address while believing it is the RTMPS endpoint.
The same principle applies elsewhere, but not necessarily the same screen flow. Cloudflare’s OBS live-stream walkthrough has you create a Live Input and record its RTMPS URL and unique key. Twitch provides ingest information and a stream key. These examples illustrate destination-specific setup; they are not instructions to reuse a Cloudflare or Twitch value on YouTube, or vice versa.
Some destinations issue a key per event; others let you use a persistent key or create a new one. Read the dashboard labels carefully. If you are not sure whether an existing key is still valid, create or select the intended input and copy the currently displayed values rather than relying on a screenshot or saved note from a previous broadcast.
Copy and paste instead of retyping. A missing character, extra space, or truncated value can be hard to spot, especially with long keys. Treat the key as private while copying it: avoid placing it in a public document, chat message, or screen recording. If the page offers a reveal control, use it only when necessary and close or hide the value once you have entered it.
Choose a service preset or Custom in OBS
In OBS, open the stream settings and inspect the Service menu. If the destination has a built-in preset that matches your service and desired protocol, use it. A preset can supply service-specific connection handling, but it does not remove the need to select the right account, event, protocol, or key. Confirm what OBS has populated before you go live.
If no suitable preset exists, choose Custom. In OBS, the Server field is for the destination’s ingest URL and the Stream Key field is for the destination-issued key. Some encoders label these fields differently, so check the encoder’s help if you cannot identify their purpose. Do not put the key into the server field or append a guessed path to a URL unless the destination explicitly tells you to do so.
The preset-versus-custom choice is about how the encoder receives connection details, not whether a stream is accepted. A preset may be simpler when it matches the service. Custom is useful when the destination gives you a manual URL and key or when there is no matching preset. Either way, the destination dashboard remains the source of truth for credentials and supported settings.
In OBS, also check that the output mode and encoder settings are compatible with the destination. Resolution, frame rate, codec, rate control, bitrate and keyframe interval are not universal RTMP settings. They are properties of the video being sent and must fit the receiving service, the content and the available upload connection. The YouTube encoder settings page gives YouTube-specific recommendations; do not treat those recommendations as a specification for every custom endpoint.
When selecting a preset, protocol support matters. If the destination supplies RTMPS but a particular preset or encoder cannot use it, do not silently replace the URL with a guessed alternative. Check the encoder’s current documentation or choose a compatible custom connection method. For a broader view of the software and workflow choices involved, see essential tools for live streamers.
Enter the destination details
With the correct destination and input selected, paste the URL into Server and the key into Stream Key. Before saving, compare the protocol at the start of the URL with the one shown in the destination dashboard. rtmp:// and rtmps:// are different connection choices. Use exactly what the destination supplied, rather than changing the prefix because another tutorial used a different one.
Check for accidental whitespace at the start or end of each pasted value. Do not add quotation marks, spaces or a second copy of the key. Avoid editing the URL’s path or port. If a destination provides separate server and key fields, follow that arrangement; if it supplies a combined format, consult its instructions for how your encoder should use it.
Now set video and audio output to values the destination accepts and your connection can sustain. A higher resolution or frame rate requires more data to be sent; if the upload connection cannot sustain the chosen output, the stream may stutter or drop frames even when the credentials are correct. If you are unsure, use a modest configuration supported by the destination and test it before an important broadcast. A bandwidth-use guide can help you think through data demand, though the destination’s encoder guidance is the authority for its accepted settings.
As an example of why values should remain destination-specific, YouTube’s current guidance recommends CBR, a two-second keyframe interval and says not to exceed four seconds. Its published bitrate recommendations also vary by codec, resolution and frame rate. For 1080p at 30 fps, the cited recommendations are 10 Mbps for AV1 or H.265 and 14 Mbps for H.264; at 60 fps, they are 12 Mbps for AV1 or H.265 and 17 Mbps for H.264. These are YouTube recommendations, not universal requirements for custom RTMP.
| Check | What to enter or compare | Why it matters |
|---|---|---|
| Destination | The service, event or input you intend to use | Credentials belong to a destination and may be tied to a particular input |
| Server | The exact ingest URL shown there | The encoder must send to the receiving endpoint, not a guessed address |
| Stream key | The current key for that input | The key authorises or identifies the broadcast at the destination |
| Protocol | RTMPS if supplied and supported; otherwise follow the service’s instructions | The encoder and destination must agree on the connection type |
| Output | Settings accepted by that destination and sustainable on your upload | A valid connection alone does not ensure smooth video |
Start the encoder and check the destination preview
Before starting, make sure the intended video and audio sources are active in the encoder. Check that OBS is showing the expected picture and audio meter response. If you are testing a loop or a still image, confirm the source is visible in the programme output rather than only in a preview that is not being sent.
Start streaming from OBS. Watch both sides: the encoder should report that it is sending, and the destination should show an incoming or connected state. If the service offers a test player or preview, use it to check that the actual incoming picture and sound look right. A connected status confirms that data reached the input; it does not by itself establish that viewers can see the intended content or that every output setting is ideal.
Allow for the destination’s own processing and preview delay. If the preview does not appear immediately, check the dashboard status and encoder log before repeatedly changing settings. For a planned broadcast, a short private or test run gives you a chance to confirm video, audio, aspect ratio and the selected event without making last-minute changes during the real session. Cloudflare’s guide, for instance, has you check the Live Input status and test player after starting OBS.
Do not conclude that setup is complete solely because the encoder’s timer is advancing. If the destination still reports no input, the stream has not been verified at its receiving end. Likewise, a destination preview with black video or missing sound points to a source or output issue even if the connection credentials are accepted. Check the sources and output path separately from the URL and key.
For a channel intended to run for long periods, test the whole operating path, not just the first connection. Confirm what happens if the encoder is restarted, whether the event remains usable, and how you will notice a later disconnect. If you are working towards a continuous YouTube channel, compare the implications of a local computer, cloud PC or other operating model in the low-cost VPS guide for a 24/7 prerecorded YouTube stream in India; it addresses a different decision from entering custom RTMP credentials.
Fix common URL, key and protocol mistakes
If the destination does not show an incoming connection, start with the basics and change one item at a time. Confirm that you selected the right live event or input, copied that input’s current URL and key, and placed each value in the matching encoder field. A key from the right platform but the wrong event can still be the wrong credential.
Next, compare the URL character by character with the dashboard. Check the protocol (rtmp or rtmps), hostname, path and any port shown. Do not substitute the hostname from another service or follow a URL pattern found in a general tutorial. Twitch’s developer documentation, for example, describes a Twitch-specific broadcast URL shape; it does not define a universal custom RTMP address.
If you selected RTMPS, confirm that the encoder supports it and that the supplied URL is genuinely the secure endpoint. For YouTube RTMPS connection problems, YouTube’s documentation specifies port 443 and use of the server hostname for SNI authentication. Those details matter particularly for lower-level encoder or API integrations; in a normal OBS setup, first ensure you used the exact YouTube RTMPS URL and a compatible encoder. Do not add SNI settings or change ports by guesswork.
A connection refusal, SSL error or timeout can point to a protocol mismatch, unsupported RTMPS, an incorrect port or an unreachable endpoint. Check the destination’s current documentation and the encoder’s logs for the actual error. If the destination offers an RTMP endpoint as an alternative, use it only if that destination documents it for your input and your security requirements allow it. A secure endpoint is preferable when supplied and supported, but troubleshooting does not justify inventing an endpoint.
If the destination accepts the connection but video is black, frozen or silent, the URL and key may already be correct. Check the selected scene, media source playback, audio routing, encoder output and destination preview. If video arrives but drops frames, examine whether the upload can sustain the chosen bitrate and whether the receiving service accepts the codec and frame rate. Lowering output can be a useful test, but use the destination’s specifications to choose a final setting.
For Twitch, its documentation describes an optional bandwidthtest=true query parameter for testing with Twitch Inspector without enabling live viewing. That is a Twitch-specific testing method, not a generic addition for other destinations. Only follow a testing procedure documented by the platform you are using.
Protect and rotate stream credentials
A stream key is an authorization credential, not a harmless label. Twitch explains that its key identifies and authorises the stream entering its ingest system. Treat keys for other services with the same practical care: do not show them on stream, include them in screenshots you share, paste them into public support posts or send them to someone who does not need access.
If you record a setup checklist, write down where to find the key rather than the key itself. Restrict access to saved encoder profiles and account dashboards. When sharing a screen, hide the settings page or conceal the key field first. If a key is exposed, use the destination’s controls to reset or replace it, then update the encoder with the new value and test that the destination receives it.
Credential rotation should follow the destination’s options and your circumstances. There is no universal rotation schedule or single reset process: some services issue keys for an event, while others offer a persistent key that you can regenerate. Check the current official help page before changing a key that a running channel depends on, since a replacement may interrupt an encoder that still has the previous value saved.
A second person helping with a broadcast may need access to the encoder, but that does not automatically mean they need a copy of the key in chat or a document. Prefer controlled access to the account or a carefully managed encoder profile. After a test, remove temporary screenshots, notes or recordings that contain credentials, especially on a shared computer.
If your setup uses StreamNeo to send an uploaded video to a 24/7 YouTube live stream, the destination-specific key still needs to be copied into the connection setup; using it means you do not have to keep your own computer running for that broadcast. Keep the key private and verify the YouTube destination reports incoming video before treating the connection as ready.
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
Where do I find my RTMP URL and stream key?
Open the live dashboard for the service where you want to broadcast, then select or create the event or input you are configuring. Copy both values from that destination’s encoder or ingest settings; do not reuse values from another platform or an old event without checking that they still apply.
What should I put in OBS for a custom server?
Choose Custom in OBS when there is no suitable destination preset, then paste the destination’s server URL into Server and its key into Stream Key. If the service offers a matching preset, you can use it instead, but verify that its protocol and event details are correct.
Should I use RTMP or RTMPS?
Use RTMPS when the destination supplies it and your encoder supports it. It carries RTMP over TLS/SSL; the endpoint, port and any lower-level connection requirements remain destination-specific, so follow the current official instructions.
OBS says it is streaming, but the destination shows no video. What should I check?
Confirm that the destination selected in its dashboard matches the event or input whose URL and key you entered. Then check the protocol, exact URL and key, encoder logs, source output and destination preview; an encoder sending indicator alone does not verify that the destination received usable video.