A custom RTMP stream needs the ingest address and publishing credential supplied by the destination. Get both from that destination’s current live-control or encoder instructions, enter them in the correct fields in your encoder, then confirm reception on the destination side before relying on the stream.
The exact address, protocol, port and credential format vary. Do not copy settings from another platform or guess at a URL: the steps below give you a reliable process while leaving those values to the service receiving your feed.
Get the ingest details from the destination
Sign in to the service where you intend to publish, then create or select the live event, channel or stream that will receive your encoder feed. Look for current encoder instructions, often shown in a live-control room or creator dashboard. The destination should provide an ingest URL and a stream key or an equivalent credential. Treat these as a matched set for that destination and, sometimes, for that particular event.
A generic custom destination does not have a universal ingest address. The host, path, protocol and any port are service-specific, and an old event’s key may no longer be valid. Retrieve the details for the actual destination you plan to use. For YouTube, the Live Streaming API documentation describes ingestion information associated with a live stream; for another platform, follow its own current creator instructions.
Read the labels around the values before copying them. A destination may show a server URL and a stream key separately, or explain that the credential belongs in a particular part of a URL. YouTube’s API documentation, for example, describes an ingestion address and stream name, and explains that they may be entered separately or combined as STREAM_URL/STREAM_NAME depending on the encoder. That example is not a template for another destination.
Copy values carefully, without adding spaces, punctuation or quotation marks. If the interface offers separate copy controls, use them rather than retyping. Keep the details in a private place while you configure the encoder; avoid notes synced to a shared account or pasted into a public support conversation.
Also check the destination’s current requirements for video and audio format, bitrate and whether it expects a preview or event to be prepared before transmission. Requirements can change, and this guide does not prescribe a universal bitrate or codec. The OBS overview likewise explains that output choices depend on both upload capacity and service restrictions. Consult the receiving service before setting a ceiling or diagnosing quality.
If you are building a channel that repeats material rather than sending a one-off event, the destination setup is still only one part of the work. A separate guide to streaming scheduled videos as a continuous YouTube Live channel covers the content workflow; its YouTube-specific framing should not be mistaken for custom settings on another service.
Choose RTMP or RTMPS when offered
Use the protocol and endpoint that the destination tells you to use, and first confirm that your encoder supports it. RTMP is a common live-ingest protocol. RTMPS carries RTMP over a TLS connection, adding transport encryption between the encoder and a supported receiving endpoint. The choice is not simply a switch to make without checking the matching address and connection requirements.
If the destination offers both options, compare compatibility, security and the needs of your programme. RTMPS is appropriate when the destination provides a secure endpoint and your encoder can connect to it. A plain RTMP endpoint may be required by a particular workflow or older encoder. Neither choice overrides the platform’s current instructions, and support on one destination does not establish support on another.
For YouTube specifically, Google recommends RTMPS for ordinary content, particularly where low latency matters. Its RTMPS ingestion guide specifies YouTube-specific connection requirements, including use of an RTMPS endpoint, TLS and port 443. Those details apply to the documented YouTube workflow, not to a custom destination in general. If your receiver is not YouTube, do not transfer YouTube’s endpoint or port assumptions to it.
A protocol mismatch can look like an encoder fault. For example, a secure endpoint may reject a connection sent without TLS, while an RTMP endpoint is not made secure simply because you selected a setting labelled secure in the encoder. Check the full endpoint instruction, including any port or hostname requirement, before changing unrelated video settings.
There can also be a format reason to use something other than RTMP. YouTube documents HLS ingestion as an alternative for certain HDR or codec needs, provided the encoder supports HLS; that does not mean HLS is universally available or suitable. If the destination specifies a different protocol, follow its workflow rather than forcing a custom RTMP setup.
Enter the server and key in your encoder
In OBS Studio, open Settings > Stream. Choose the option for a custom streaming server, then enter the destination’s server URL and stream key in their corresponding fields. OBS’s custom server overview describes this arrangement. Menu wording can change between versions, so use the current OBS interface and help if a label differs.
Do not assume every encoder presents the same fields. Some ask for a server and key separately; others may expect a combined address or offer a service-specific preset. Follow the destination’s field format and the encoder’s documentation together. If the destination says the key is already part of a URL, avoid appending it again unless the encoder instructions explicitly require that. Duplicating or omitting a key can prevent authentication.
Before saving, compare what you entered with the destination’s instructions one component at a time: protocol, host, path, port if specified, and credential placement. Avoid sharing a screenshot of the settings, because it may reveal the key. If someone else is helping, show a redacted view or describe the field labels without exposing the secret.
Next check the encoder’s output configuration. Set resolution, frame rate, audio format and bitrate to values supported by both the destination and your available upload capacity. Upload speed fluctuates, particularly on a home or shared connection, so do not set the bitrate solely from a speed test taken once. Leave room for other traffic and watch the receiver’s health indicators after the first test.
The receiving service’s documented limits take precedence over a remembered number from an old tutorial. OBS’s overview notes that the upload connection and service restrictions both affect bitrate. If you use a detailed settings guide such as FFmpeg settings for YouTube Live at 4K, treat it as a YouTube-specific workflow, not a set of values to copy into an unrelated destination or encoder.
If you run a continuous channel from a computer at home, the encoder must remain online and sending the feed for the channel to continue. A guide to running a continuous YouTube stream on a rented Indian VPS discusses a different operating arrangement. Choose an arrangement based on your own destination, equipment, connection and need for continuous operation rather than assuming that its settings transfer to this setup.
Protect and rotate the stream key
A stream key is a credential, not a harmless label. Anyone who obtains a valid key may be able to send a feed to the associated channel or event, subject to the destination’s controls. Twitch’s Stream Key FAQ explicitly warns broadcasters not to share their key. Keep it out of screen recordings, screenshots, public chat, shared documents and support tickets unless the platform provides a secure method for doing so.
When you configure a shared workstation, remember that settings may persist after the session ends. Limit access to the encoder profile and the account that can view the key. Do not place the key in a public script, repository, command transcript or file that other people can download. If you must send configuration instructions to a colleague, describe where to retrieve the key rather than sending the credential itself.
If the key appears in a stream recording, screenshot, public message or log that others can access, treat it as exposed. Use the destination’s current refresh, reset or revoke process, then update the encoder with the replacement credential. A reset can interrupt an active broadcast, so plan the change and confirm which event or channel it affects before applying it.
Check for other authorised publishing access as well. Some services distinguish a broadcaster’s key from keys or permissions issued to guests or collaborators. Refreshing one credential may not revoke the others. Review the destination’s access controls and remove any old access that should no longer be active.
If you are unsure whether a key was exposed, avoid pasting it into a search engine or sending it to support for inspection. Use the destination’s account controls and official help material to decide whether to rotate it. Once rotated, verify reception using the new value and make sure any stored copies of the old one are removed or clearly marked unusable.
Start sending and confirm reception
Prepare the destination first. Some services require the event to be created, scheduled or placed in a ready state before they will accept the incoming feed. Keep the destination’s live-control page open, then start streaming from the encoder. The encoder indicating that it is connected is useful, but it is not the only confirmation you need.
Look for a preview, ingest status, health indicator or other receiving confirmation on the destination’s own page. Check that the picture and sound are present and that the correct event or channel is selected. If the destination offers a preview before going live, use it to inspect framing, audio levels and any overlays before making the broadcast public. The exact status labels and timing are platform-specific, so follow that service’s instructions rather than relying on a fixed wait time.
Keep the encoder’s status and destination’s status in view during an initial test. A local preview proves that the encoder can render the scene; it does not prove that the destination is receiving it. Likewise, a connected indicator may not prove that the correct event is selected or that the audience sees the intended output. Confirm both ends before leaving the setup unattended.
For an always-on channel, test the workflow during a period when you can observe it. Confirm the stream remains active, audio does not disappear, and the destination continues to report healthy reception. The feed may be correct while a separate issue, such as a sleeping computer or changing network connection, stops it later. Continuous operation needs its own monitoring and recovery plan; the guide to looping a folder of videos on YouTube Live addresses one content pattern, but does not replace destination-specific ingest checks.
If reception is confirmed but the picture or sound is poor, diagnose the output settings and connection capacity against the destination’s current requirements. Change one setting at a time and observe the result. This makes it easier to identify whether a problem comes from the source, encoder, upload path or receiving service.
Troubleshoot connection and key errors
Start with the destination’s current instructions, not a guess. Compare the server field character by character, including protocol, hostname, path and any port the destination specifies. Then check that the credential belongs to the selected event or channel and is in the expected field. A mismatch in any one of these can produce a connection failure that looks similar to an incorrect password.
Use the error message to narrow the check. An authentication or key error points you towards the credential, its placement, or whether it has been rotated. A connection timeout suggests checking the endpoint, protocol, port where specified, network access and whether the destination is accepting ingest. A successful connection with no visible preview may point to event readiness, an incorrect destination selection or an unsupported output format. These are diagnostic possibilities, not guaranteed meanings; consult the receiving service’s error guidance.
For YouTube RTMPS, Google’s documentation gives more specific checks: verify the RTMPS endpoint, TLS connection and port 443. If certificate or TLS errors persist, the guide also discusses checking the endpoint and connection details, including Server Name Indication (SNI). Do not apply these YouTube-specific diagnostics to a different custom service unless its documentation calls for them.
If the destination receives a signal but reports a format or health issue, check video and audio settings against its current specifications. Then assess upload capacity and competing traffic. The OBS guide to bitrate and output settings is a useful starting point for understanding why available upload speed and service limits both matter, but the receiver’s own limits must govern the final values.
Keep a private note of the successful configuration without recording the live credential in plain text. You can record the encoder version, destination name, protocol, non-sensitive output choices and date you last checked the destination’s instructions. If a later change breaks reception, this gives you a comparison point while keeping the key secret.
Stop the stream and secure the setup
When the test or broadcast is over, stop transmission from the encoder and confirm that the destination has ended or returned to the expected ready state. Some services distinguish between stopping the incoming feed and ending the event; use the destination’s own controls if you need to close the event rather than leave it waiting for another feed.
On a shared computer, remove access to the saved profile or sign out of the destination account when appropriate. Do not delete a profile you need for future broadcasts before noting its non-sensitive settings. If you used a temporary key or a one-off event, check whether the destination expects you to revoke it or whether it expires with the event.
For a continuing channel, document who is allowed to retrieve the credential, where the current destination instructions live, and who can rotate the key if needed. Keep the procedure current: a platform can change menu names, endpoint details or supported formats. Recheck the official instructions before a major broadcast rather than assuming last season’s setup remains valid.
If your broader aim is to keep a 24/7 YouTube channel running without leaving a personal computer on, the operating model matters as much as the ingest fields. StreamNeo turns an uploaded video into a YouTube live stream that can continue with your computer switched off, removing the need to keep a local encoder running for that specific workflow. It is YouTube-only and is not a custom RTMP destination, so use the receiving platform’s own setup when you need to publish elsewhere.
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 the custom RTMP URL and stream key?
Find them in the destination’s current creator dashboard, live-control room or official encoder instructions after selecting or creating the relevant event. The address and credential are destination-specific; do not use a URL or key copied from another service or an old event.
Where do I enter the URL and key in OBS?
Open Settings > Stream, choose the custom server option, and enter the server URL and key in the fields OBS provides. If your destination specifies a combined format or a different credential arrangement, follow its instructions rather than assuming the separate-field example applies.
Should I choose RTMP or RTMPS?
Choose the protocol that the destination supports and recommends, and confirm that your encoder supports the matching endpoint. RTMPS uses TLS, but you need the receiver’s exact secure endpoint and any specified connection requirements; there is no universal RTMPS setting for every destination.
What should I do if the stream key may have leaked?
Use the destination’s official refresh, reset or revoke process, then replace the credential in the encoder and confirm reception again. Review guest or collaborator access separately, since rotating one key may not revoke other authorised credentials.