You find the RTMPS URL for a particular broadcast in that stream’s settings in YouTube Live Control Room. Copy the RTMPS address, not the ordinary RTMP address shown by default, and use it with the matching stream key in the format your FFmpeg build accepts.
There is no single URL and key that works for every channel or stream. The endpoint and key are stream-specific credentials; FFmpeg packages can also differ in whether they support RTMPS. The steps below show where to retrieve the values, how to configure output, and what to check if the connection fails.
What the RTMPS URL and key do
A live encoder sends a video and audio feed to YouTube’s ingest service. The RTMPS URL identifies the secure ingest endpoint for your stream; the key identifies the stream configuration YouTube should associate with the incoming feed. Both values need to correspond to the same stream.
RTMPS is RTMP carried over TLS/SSL. The secure connection protects the transport between the encoder and YouTube, but it does not replace the key. Think of the URL as the destination and the key as the stream-specific credential used at that destination. YouTube’s RTMPS ingestion guide documents the secure ingest requirements and API fields.
An encoder’s interface determines how you enter the two values. Some ask for a server URL and stream key in separate fields. Others accept one output address in which the key or stream name is appended to the URL. FFmpeg commands commonly express the combined destination as a URL followed by the key, but you should use the exact RTMPS address YouTube provides and preserve the arrangement expected by your FFmpeg build.
If you are running a continuous channel, there is a separate operational question: what happens when the process, computer, or connection stops. For an FFmpeg setup, the guide to keeping a Hindi devotional stream online when FFmpeg crashes covers recovery planning. It does not change how you retrieve the ingest URL or key.
Find the current URL in Live Control Room
Open YouTube Studio and go to Live Control Room. Choose the Stream tab for an existing stream, or schedule a stream first if you are preparing a broadcast for later. In the stream settings, find the Stream URL field. The regular RTMP address may be what YouTube shows initially; use the lock control or equivalent reveal option to display the RTMPS URL, then copy it.
Copy the stream key associated with that same stream as well. Avoid relying on an old note, command, or screenshot: a key may have been changed or reset, and a scheduled stream can have settings distinct from another broadcast on the channel. YouTube Help’s instructions for encrypting a stream using RTMPS describe the Live Control Room workflow and note the need for an encoder that supports RTMPS.
Check the address before pasting it into FFmpeg. It should be the secure address revealed for the active stream, not the default RTMP address and not a value copied from a tutorial. Do not add a guessed host, path, or port to make it look like an example you found elsewhere. YouTube’s ingest value can vary by stream and account context, so the current value in your own stream settings is the useful one.
If you manage streams through the YouTube Live Streaming API rather than the Studio interface, the LiveStreams resource provides ingestion information. Its cdn.ingestionInfo.rtmpsIngestionAddress field is the primary secure address; cdn.ingestionInfo.rtmpsBackupIngestionAddress is the backup address where the workflow supports redundant ingest. The LiveStreams resource reference describes these fields. Most basic FFmpeg configurations should begin with the primary address, not attempt to combine primary and backup values.
| How you retrieve it | Address to use | What else to copy or check |
|---|---|---|
| Live Control Room | Reveal and copy the stream’s RTMPS URL | Copy the key for that same stream |
| YouTube Live Streaming API | Read the primary rtmpsIngestionAddress field |
Treat the backup address as a separate redundant-ingest option |
The names in the API are useful when building a custom integration, but they are not a substitute for the current stream’s returned values. If your goal is to start a single FFmpeg output, the Live Control Room method is usually the more direct way to inspect and copy the destination and credential.
Pair the URL with the stream key
For an output that expects a single destination string, the usual shape is the copied RTMPS URL followed by a slash and the matching key. In the command pattern below, all three uppercase placeholders are replacements, not literal values:
ffmpeg -re -i INPUT -c:v libx264 -c:a aac -f flv 'RTMPS_URL/STREAM_KEY'
Replace INPUT with your local media source, RTMPS_URL with the exact secure address from Live Control Room, and STREAM_KEY with the key for that stream. The command is a configuration pattern, not a guarantee that every FFmpeg package, operating system, input format, or account will work unchanged. In particular, do not publish your actual URL and key as a public example.
The -re option paces a file input in real time; it is a practical choice for a prerecorded file, not a YouTube requirement. A live capture source needs its own input options and a check of the codecs available from that source. If a wrapper or custom encoder has separate URL and key fields, follow that program’s documented arrangement rather than appending the key manually. YouTube’s API documentation describes the stream name as a separate value and notes that an encoder may request it separately or append it as STREAM_URL/STREAM_NAME.
Do not add quotes around a value in a way your shell interprets incorrectly. In the pattern above, the single quotes protect the combined destination string from shell parsing, but the right quoting rules depend on your shell and on how the command is launched. If you store the command in a script or a service definition, test how it handles special characters in the key rather than assuming a copied command will preserve them.
The media encoding settings are independent of the ingest URL/key pairing. For a prerecorded devotional loop, for example, the destination tells YouTube where to receive the stream and the key associates it with the chosen broadcast; codec, resolution, bitrate, and keyframe behaviour still need to suit the stream profile. YouTube’s current encoder settings guidance lists supported formats and recommendations, including CBR and a two-second keyframe interval, which should not exceed four seconds. Consult the current guidance for the profile you intend to send rather than copying settings blindly.
Configure FFmpeg output fields
In a command-line FFmpeg workflow, output options appear before the final output destination. The -f flv setting in the example makes the output container explicit for this common RTMP-family use. The codecs shown are a pattern, not mandatory values for every input or stream. You may need to select different encoding options if your source has a different frame rate, aspect ratio, audio layout, or target quality.
If the file is a playlist or a long pre-recorded loop, first confirm that the input handling is doing what you expect before troubleshooting the network destination. The article on scheduling different FFmpeg playlists by time of day is relevant when the challenge is programme scheduling rather than the RTMPS handshake. Keep these concerns separate: a valid URL and key do not fix an invalid media input, and a healthy file loop does not fix an incorrect ingest address.
For a continuous output, verify that your input is paced appropriately, that audio is present if expected, and that the chosen output profile is compatible with the platform’s current encoder guidance. YouTube’s published recommendations include H.264, H.265/HEVC, and AV1 in supported contexts, AAC or MP3 audio, frame rates up to 60 fps, CBR, and the keyframe guidance noted above. Choose bitrate and resolution from YouTube’s table for the intended profile. These settings can affect stream health, but they do not alter the stream-specific URL or key.
Once the destination and encoding choices are in place, start with a controlled test in the Live Control Room rather than assuming that a process which stays open is necessarily ingesting healthy video. Check the stream preview or status and confirm that YouTube sees the expected feed. If your stream carries multiple audio sources, verify the mix separately; the guide to recording multiple audio sources at once concerns source capture and mixing, not the ingest credential.
Check whether the FFmpeg build supports RTMPS
FFmpeg’s protocol documentation describes RTMPS as RTMP over a secure SSL connection. Support depends on the implementation available in the build. The documented librtmp RTMPS variant requires a build configured with --enable-librtmp and with the relevant librtmp headers and library available. That requirement does not mean every FFmpeg package uses librtmp or has the same protocol capabilities.
Inspect the protocols exposed by your local build before spending time changing URL syntax. FFmpeg’s protocol listing can show what that package recognises; consult the documentation or packaging notes for the exact build if RTMPS does not appear or the connection attempt reports an unsupported protocol. A build can differ from another build with the same FFmpeg version label because it was compiled with different libraries or options. The FFmpeg protocol documentation is the primary reference for the protocol implementation and build notes.
If your installed build does not support the required secure protocol, changing the destination to plain RTMP is not a sound fix when you intend to use YouTube’s RTMPS endpoint. Use a build that supports RTMPS or another encoder that explicitly supports YouTube’s secure ingest. The practical choice depends on how you install and maintain software: a packaged build may be simpler to update, while a custom build offers control but adds responsibility for dependencies and future updates.
Do not infer protocol support from the fact that FFmpeg can send to some RTMP destinations. RTMP and RTMPS are related, but the secure TLS connection adds requirements. This distinction is especially useful when troubleshooting on a small always-on computer: if a command works with a non-secure test destination but fails at YouTube’s secure endpoint, check actual RTMPS support before changing codecs or media files.
Verify the secure scheme and port
Use the rtmps scheme in the address supplied by YouTube. Do not replace it with rtmp, and do not copy the ordinary RTMP URL that may be visible by default. YouTube’s RTMPS guidance requires a secure connection on port 443. If you are assembling a URL or configuring a custom client rather than pasting the exact Studio value, confirm that the host and port are the ones supplied or required by the current YouTube documentation.
A common failure is to have a plausible-looking URL that points to the wrong scheme or port. TLS setup may then fail before the stream key is relevant. Re-copy the entire RTMPS URL rather than repairing it from memory, and check that no character was clipped during copying. If the URL already contains a port, do not append a second one without a documented reason.
For an API-based custom encoder, YouTube’s RTMPS instructions also call out Server Name Indication (SNI) during TLS server authentication. In practical terms, the TLS client needs to identify the hostname it is connecting to as part of the handshake. Ordinary FFmpeg users should begin by using a supported build and the complete URL YouTube provides; SNI becomes a specific thing to investigate when developing or debugging a custom TLS client.
Test the connection and inspect errors
Start with the short checks that distinguish a credential issue from a transport issue. Confirm that the endpoint and key came from the same stream settings, that the URL uses RTMPS, and that the connection uses port 443. Then establish whether the local FFmpeg build supports RTMPS. These checks address the common causes of SSL errors and timeouts that YouTube identifies in its help material.
Read the first relevant error from FFmpeg rather than focusing only on the final exit message. A TLS or certificate error points towards the scheme, host, port, or protocol support. A timeout can also indicate a wrong URL or an encoder without RTMPS support. An authentication or publishing error makes it worth checking the key and whether the intended stream is available in Live Control Room. Error text is not always specific enough to identify one cause, so change one variable at a time.
A useful sequence is to recopy the primary URL and matching key, run a test, check the build’s protocol support, then verify the port and TLS behaviour. Avoid switching several settings at once; otherwise, a successful retry will not tell you which issue was responsible. Do not share full logs publicly without checking them for the stream key, private host details, or other sensitive values.
If the connection establishes but the stream is unhealthy, inspect the preview and stream health in Live Control Room. A successful handshake only proves that FFmpeg reached an ingest destination; it does not confirm that the encoded video has the expected resolution, that audio is present, or that bitrate and keyframe settings suit the profile. Compare those settings with YouTube’s current encoder guidance. If the stream becomes unstable only after running for a long time, investigate local input, network stability, and process recovery separately from the initial URL setup.
Protect stream-specific credentials
Treat the stream key as a password for publishing to that stream. Anyone who obtains it may be able to send content to the associated broadcast, so keep it out of public screenshots, blog examples, support posts, and shared command histories. If you suspect it has been exposed, use YouTube’s current controls to reset or replace it, then update the encoder with the new value.
Shell commands can leave traces in terminal history, process listings, monitoring dashboards, and logs. A private machine used only by you may make direct command entry acceptable, but shared accounts and hosted environments call for more careful handling. Restrict access to scripts and configuration files containing credentials, and avoid echoing the full output destination as part of routine diagnostics.
The endpoint itself is stream-specific account information even if it is not as sensitive as the key. Do not publish both values together or include them in a public issue report. When asking for help, redact the key and any unique portions of the URL that could identify your ingest configuration. Keep a private note of which stream the credentials belong to, so you do not accidentally reuse one stream’s key with another broadcast.
For people who want a continuous prerecorded channel without leaving their own computer to run FFmpeg overnight, StreamNeo removes the need to keep that local machine running by turning an uploaded video into a YouTube live stream; you still provide your own stream key and should protect it as carefully as any publishing credential. It is YouTube-only, so consider whether that matches your workflow before relying on it.
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 YouTube RTMPS URL for FFmpeg?
Open the relevant stream in YouTube Live Control Room and reveal the RTMPS address in its Stream URL setting. YouTube may show the ordinary RTMP URL by default, so make sure you copy the secure URL and the key for that same stream.
Can I use the same YouTube RTMPS URL for every stream?
No. Use the address and key associated with the stream you are configuring; do not substitute an endpoint or key from a tutorial or another channel. API-managed workflows can retrieve primary and backup secure addresses from the stream’s ingestion information.
Why does FFmpeg report a TLS or timeout error?
Check that the address is the RTMPS value, that the connection uses port 443, and that your FFmpeg build supports RTMPS. Then recopy the URL and matching key from the same stream settings. A timeout or TLS error can arise before the key is evaluated, so confirm transport details first.
Does every FFmpeg build support RTMPS?
No. FFmpeg protocol availability depends on how a package was built, and the documented librtmp RTMPS option has its own build requirements. Inspect your local build’s protocol support and consult its build documentation if RTMPS is unavailable.