Custom RTMP streaming is an encoder connection in which you provide the destination’s ingest address and the authorisation value it requires, usually a stream key. It works only when the destination supports the protocol and the encoder’s output meets that destination’s current requirements.
The address tells your encoder where to send the stream; the key tells the receiving service which broadcast to associate it with and, in many services, authorises the connection. You retrieve both from the destination itself, enter them in OBS or another encoder, then verify the receiving preview before you publish or announce the broadcast.
What “custom RTMP” means
RTMP is a protocol used to send live audio and video from an encoder to an ingest service. The encoder captures and composes sources—perhaps a webcam, a desktop, a music visualisation or a capture card—encodes them, then sends the outgoing stream to the destination. That ingest point is the first receiving stage, not the finished viewer experience: the platform still has to authorise and prepare the stream before viewers can watch it.
“Custom” generally describes how you configure the encoder. Rather than selecting a built-in service preset, you choose a custom server option and enter the destination details yourself. In OBS the option is labelled “Custom Streaming Server”. The term does not mean that you can connect to any site or invent an address that will work. The receiving platform must explicitly provide a compatible ingest workflow.
The details differ between services. One may show a broadcast URL and a key in separate fields; another may expect a combined address, or use different labels. Even when two destinations both mention RTMP, their supported address formats, authorisation steps, codecs and transport options may not match. Treat the destination’s current dashboard or official instructions as authoritative, rather than copying a configuration from another platform.
This is a connection workflow, not a guarantee that every video source or encoding setting will be accepted. If your goal is to run a recorded loop rather than operate a live production continuously, first decide how the programme itself will be supplied. For example, a YouTube playlist running a 24/7 Indian music stream raises a different question from the encoder connection that delivers a live feed.
What the server URL and stream key do
The server URL identifies the ingest destination: the receiving endpoint to which the encoder opens its connection. A stream key, sometimes called a stream name or authorisation value, identifies the broadcast or channel session at that destination. In a typical setup you provide these separately, but the destination and encoder determine the exact arrangement.
A useful way to think about the two values is as an address and an access credential. The address points the outgoing media towards the receiving service. The key helps that service identify or authorise the feed. This is a practical description, not a universal rule for how every service handles credentials; follow the labels and instructions you were given.
Do not publish a stream key in a screenshot, tutorial, shared document or public chat. Someone who obtains it may be able to send a feed to your channel or otherwise interfere with the broadcast. Twitch’s official guidance on stream keys warns that sharing a key can compromise the channel. If a key has been exposed, use the destination’s account controls to reset or replace it, then update the encoder with the new value.
Some encoder screens accept a server URL and key in distinct boxes. Other workflows may place a stream name in a path or combine values into a single field. YouTube’s API documentation describes primary and backup ingestion addresses and stream names, and notes that an encoder may handle the URL and stream name separately or together. Do not treat a URL format seen in one platform’s documentation as a template for another. Copy the full values exactly as issued, including any path or protocol prefix, and avoid adding, removing or rearranging characters unless the destination specifically instructs you to.
Retrieve current destination details
Start in the destination’s own live dashboard or official documentation. Create or select the intended live broadcast, then find the current server or stream URL and its matching key. For YouTube, the Live Control Room instructions explain where to find the Stream URL and stream key. Other services may call the address an RTMP URL or broadcast URL and expose it in a broadcaster dashboard.
Check that the details belong to the broadcast you plan to send, not an old test, a different channel or a previous event. A destination may provide more than one ingest address, such as a primary and backup address. Use the one its current instructions designate for your encoder and workflow; do not swap in a backup merely because it looks similar. If you are unsure whether a key is reusable or event-specific, the dashboard or official help page should settle that point.
Before opening OBS, note the destination’s technical requirements too. Confirm which transport it accepts, the expected URL format, and supported video and audio encoding settings. Match resolution, frame rate, codec, keyframe interval and bitrate to the platform’s current guidance and the capacity of your upload connection. There is no universal RTMP profile that suits every destination. OBS’s streaming setup guide also makes clear that bitrate has to fit both the available upload speed and the service’s limits.
Keep the key private while doing this. If you need someone else to help configure OBS, use an appropriate account permission or a secure handover rather than sending credentials through a public support forum. When the destination offers a way to revoke or reset a key, know where that control is before you need it.
Enter the connection details in OBS
In OBS, open Settings → Stream. Select the custom streaming-server option, then enter the server URL and stream key in the fields provided. Labels can vary across OBS versions or related software, so match each value to the field description rather than assuming a field named “Server” always means the same thing in every application. OBS’s current streaming overview documents choosing “Custom Streaming Server” and supplying the URL and key.
If your destination provides one combined URL instead of separate values, follow its instructions for entering that format. Do not split a combined value or join separate values unless the platform or encoder documentation tells you to. This is a common source of silent configuration mistakes: a URL can look plausible while missing a path component or including a key in the wrong place.
Next, configure the output to meet the destination’s current requirements. The right choice depends on what that service accepts and what your connection can sustain. A high bitrate cannot compensate for an unsupported codec, and a supported codec does not prevent interruptions if the upload fluctuates. Where a service publishes a setup guide, use it rather than assuming a setting that worked on another platform will transfer.
If your programme is assembled in OBS from scenes and sources, check the programme before connecting: confirm the intended scene is active, audio is present at a sensible level, and any loop or overlay behaves as expected. A capture card can be useful for bringing an HDMI camera or other device into OBS, but it is an optional source accessory, not a requirement of RTMP itself. For a recorded loop built from OBS scenes, the guide to scene transitions between looped videos can help with the visual hand-off; it does not replace the destination’s connection instructions.
When you are ready, start streaming and watch the destination dashboard for evidence that it has received the feed. A local OBS indication that it is streaming means the encoder is sending, but the destination preview is the separate check that the platform is receiving and processing it. Keep the key out of any screen recording or screenshots you capture during setup.
When to use RTMPS
RTMPS is RTMP carried over a TLS/SSL connection. That encryption protects data in transit between the encoder and the ingest endpoint. If the destination offers RTMPS and your encoder supports it, use the destination’s RTMPS address where its guidance recommends it. YouTube recommends RTMPS for YouTube Live; Google’s RTMPS ingestion documentation specifies port 443 for its RTMPS connections.
Do not assume that changing rtmp to rtmps in a URL is enough. A valid secure connection depends on the exact hostname, port and TLS setup expected by the service. For YouTube, retrieve the RTMPS variant in Live Control Room rather than treating the ordinary RTMP URL as interchangeable; its help instructions explain how to reveal that address. A device or encoder that lacks RTMPS support needs a different supported path, which you should confirm in the encoder and destination documentation.
The trade-off is compatibility and correct configuration. RTMPS adds encryption, but a mismatch between the URL, port, hostname or encoder support can prevent a connection. If you receive an SSL or certificate error, check the official destination instructions before testing protocol changes. Do not disable certificate checks or substitute an unverified address just to make an error disappear.
The service’s other encoding requirements remain separate from transport security. YouTube’s published encoder settings are YouTube-specific: for example, that guidance includes support up to 60 fps and recommends a two-second keyframe interval, with a four-second maximum. Those figures should not be carried over to another destination unless its own guidance agrees. The same principle applies to codecs and resolutions: check the current page for the destination you are actually using.
Check the receiving preview
After you start the encoder, look at the destination’s live dashboard for an incoming signal, preview or stream-health indication. Confirm that the picture is the intended scene and that the audio is present. If the platform reports that it is receiving, but the preview is blank, delayed or shows the wrong scene, check the programme output in OBS and allow for any processing or preview delay described by the platform.
Do this before announcing the broadcast or treating it as live to your audience. A connection indicator in OBS alone does not prove that the destination has accepted the feed in a usable form. The service may still be checking the incoming media, or the broadcast may need a further action in its dashboard before it is public. The exact status labels and steps vary, so read what the destination currently shows rather than assuming every platform goes live in the same way.
Check both video and audio, including the first few moments after starting. If you are streaming a music or devotional loop, listen for silence or an unintended source; if it is a news or business feed, check that the right scene and title card are visible. A sensible preflight is to look at the picture, listen at the destination preview where available, and confirm the dashboard’s stream-health state before sharing the link.
For an always-on channel, distinguish a temporary preview check from a plan for keeping the programme running. OBS still depends on the computer, encoder configuration and local connection staying in working order. If the challenge is the continuity of a recorded programme rather than the connection fields themselves, a guide to playing event replays continuously on YouTube Live in India covers that separate operating problem. StreamNeo can remove the need to leave your own computer running for a file-based channel by taking an uploaded video and running it as a YouTube live stream, but it does not change the destination-specific requirements for a custom RTMP connection in OBS.
Troubleshoot common connection errors
When a connection fails, change one thing at a time. First compare the configured values with the destination’s current dashboard: correct broadcast, complete URL, right key, and the expected field arrangement. If the destination gives separate URL and key fields, do not paste a combined value into one field; if it gives a combined value, follow that workflow. Never post the key while asking for help.
For “Failed to connect” or “connection timed out”, check that the encoder has a working internet connection and that the destination address is current and correctly copied. A firewall, router rule or restricted network may also prevent the encoder reaching the endpoint. If you use a managed network, ask its administrator whether the documented destination connection is allowed. Avoid guessing a different port or endpoint; ask the platform’s support or consult its official connection guidance if the expected route remains unclear.
For “The RTMP server sent an invalid SSL certificate” on a YouTube RTMPS setup, verify that the URL is the RTMPS address, not the ordinary RTMP address, and check the hostname and port against YouTube’s current instructions. Confirm that the encoder supports RTMPS. Google’s API guidance also identifies correct server-name information for TLS authentication as relevant, particularly for custom encoder implementations. If the details match but the error persists, check the encoder’s documentation or destination support rather than disabling certificate validation.
If the encoder connects but the destination reports no incoming video, compare the selected output and the platform’s supported codecs and settings. Confirm that OBS is sending the intended programme and that video output is enabled. If video arrives without sound, check OBS’s audio mixer, selected devices and destination audio requirements. A stream can reach an ingest endpoint yet still fail the platform’s media checks, so do not treat successful connection as proof that all output settings are acceptable.
If the stream starts and then drops, look at the connection and stream-health indicators, and compare the selected bitrate with the stable upload capacity available to the encoder. A bitrate that exceeds what the connection can sustain can produce unstable delivery. Reduce it only in line with the destination’s supported range, then test again; do not trade one unsupported setting for another. For a YouTube-specific unstable-bitrate diagnosis, the stream health checks for an unstable bitrate provide a focused set of checks, but the destination’s live status and current requirements remain the authority.
A backup ingest address is not a general cure for every failure. Use one only when the destination provides it and its instructions say when and how to use it. Keep a short record of the encoder version, exact error text, time of the failure and non-secret settings when contacting support. That evidence helps distinguish a credential mismatch from a network, transport or media-compatibility problem without exposing the key.
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
Does custom RTMP work with every streaming platform?
No. The destination must support the connection workflow and provide compatible ingest details. Confirm its currently supported protocol, URL format, authorisation method and encoder settings in its own dashboard or official documentation.
Is the server URL the same as the stream key?
No. The URL identifies the ingest endpoint, while the key or equivalent value identifies or authorises the broadcast at that destination. Some services or encoders combine values, so follow the exact format and field labels in their instructions.
Should I choose RTMP or RTMPS?
Use the transport the destination currently supports and recommends, and make sure your encoder supports it. YouTube recommends RTMPS; use the address shown in Live Control Room and check the current YouTube instructions rather than assuming another destination uses the same address or port.
What should I do if my key may have been exposed?
Treat it as compromised: use the destination’s account controls to reset or replace it, then update your encoder. Do not include the replacement key in screenshots, public posts or support messages.