When FFmpeg reports that a YouTube stream key is rejected, first compare the current Stream URL and Stream key in the intended YouTube Live Control Room with FFmpeg’s complete output URL. A connection error is not, by itself, proof that the key is wrong: an outdated endpoint, malformed publishing URL, missing muxer, unsupported TLS setup or blocked connection can produce a similar failure.
Work through those checks in order, changing one thing at a time. Keep the key private while you diagnose the problem, and only reset it when there is a reason to suspect that it is stale, compromised or no longer accepted.
Start with the current YouTube key and server URL
Open YouTube Studio and select the live stream you mean to send from FFmpeg. In its Live Control Room, copy both the current Stream URL and the Stream key. They are separate settings: the key identifies the feed, while the URL tells the encoder where to publish it. A correct key paired with a remembered URL—or a correct URL paired with a key from another scheduled stream—can fail before you learn anything useful about the credential.
YouTube describes stream keys as password-like credentials. Treat yours accordingly: do not paste it into a public support post, screenshot, example command or unredacted log. In a command or note you intend to share, replace it with a label such as YOUR_STREAM_KEY. If you think it has been exposed, reset it in YouTube Studio and replace it everywhere that uses the old value.
Make the first comparison literal. Check that the FFmpeg destination uses the URL from the selected Live Control Room stream, and that the key is the one shown for that same stream. Look for accidental spaces, a missing character or a copied key that includes surrounding punctuation. Do not rely on an endpoint remembered from a previous broadcast; a current value in the selected stream’s control room is the better reference.
The step-by-step guide to going live on YouTube can help if you are unsure which stream settings you opened. If you are testing without an audience, the instructions for a private YouTube Live test are useful context. A test can show whether the current configuration connects, but it does not make the key and endpoint comparison optional.
Check FFmpeg’s output URL structure
A stream key is not a complete FFmpeg destination on its own. FFmpeg’s RTMP URL has distinct parts for the scheme, server, optional port, application and stream name, commonly called the playpath. YouTube supplies the endpoint for the chosen stream; your command must use it in the output position and preserve the arrangement required for that endpoint.
FFmpeg’s RTMP protocol documentation describes the URL components and publishing form. In practice, check the final output argument rather than only the place where you stored the key. A common configuration error is to put the key on the input side, leave out part of the publishing path, add an extra slash, or separate the server and stream name in a way that changes the destination.
The shape of a command may look like this:
ffmpeg -re -i input-file -c:v libx264 -c:a aac -f flv 'RTMP_OR_RTMPS_OUTPUT_URL_FROM_YOUTUBE'
This is a structure example, not a tested command for your particular FFmpeg build, input file, codecs or account. Replace the placeholder with the output URL and key arrangement required by the YouTube settings you selected. Do not run it unchanged, and do not put a real key into a command you plan to share. If your command has separate output options, make sure they belong to the output and appear before its destination.
Inspect for less obvious differences: a trailing space, a line break inserted inside the URL, shell quoting that is missing or mismatched, or a copied character that has changed. If you compose the URL from a server and key rather than copying a complete value, compare each component against YouTube’s current instructions instead of assuming that a familiar path is correct. The guide to creating a YouTube live stream offers a practical reminder to confirm the publishing destination as well as the media you are sending.
Verify the RTMP or RTMPS scheme
Check whether your command starts with the same protocol YouTube supplied for the endpoint you intend to use. rtmp:// and rtmps:// are not interchangeable labels for the same connection: RTMPS carries RTMP over TLS, so it also depends on the endpoint, port and TLS support being appropriate. YouTube recommends encrypted ingestion and documents how to reveal the RTMPS URL in Live Control Room; the regular RTMP address may be the one visible by default.
Use the RTMPS URL from the control room rather than changing only the letters at the start of an RTMP URL. The server value must match too. If FFmpeg reports an SSL certificate or negotiation error, investigate the scheme and server first, then check whether the client build supports the required protocol and whether the indicated port is reachable. YouTube’s RTMPS guidance has separate advice for SSL errors and timeouts, including trying port 443 for relevant SSL cases.
A timeout is not the same symptom as a credential rejection. It may mean that the endpoint is wrong, the route is blocked, or the client cannot establish the requested connection. Likewise, an SSL error points to connection setup that needs attention; it does not establish that the key is invalid. Keep the error category in view before changing credentials.
If you are choosing between the two schemes, follow the current URL shown for the stream and confirm that your particular FFmpeg build supports it. Do not assume every FFmpeg build supports RTMPS. A command can be syntactically plausible while the libraries or protocols in that build are insufficient for the requested TLS connection.
Check the output muxer and publishing form
For RTMP publishing, FFmpeg’s documented example uses the FLV muxer, specified with -f flv, followed by an RTMP output URL. Confirm that the command actually sets an output muxer appropriate to the publishing form. Omitting -f flv, placing it after the destination or accidentally applying an input option in the wrong place can cause FFmpeg to fail or send data in an unsuitable form.
The muxer decides how the encoded audio and video are packaged for delivery; it is distinct from the stream key and the protocol endpoint. That distinction helps you narrow the fault. If FFmpeg rejects an option or fails before opening the network connection, inspect command syntax and local build support. If it opens a connection but YouTube reports an encoder or stream compatibility problem, inspect the outgoing media and YouTube’s encoder guidance rather than repeatedly replacing the key.
YouTube’s live encoder settings discuss supported protocols, codecs and stream recommendations. Those settings matter to whether an established stream is compatible and healthy. They should not be presented as the direct cause of every key error. For example, changing bitrate or keyframe interval will not repair a mistyped server URL.
If a local file is the source, confirm that FFmpeg can read it and that the command reaches its output stage. A failure opening the input file is not a YouTube authentication issue. Similarly, if the command starts publishing but the preview is black, silent or unhealthy, move on to codec, audio and encoder checks. The guide to keeping music continuous across a loop is relevant once a connection works and you are addressing the behaviour of the programme itself.
Rule out a stale key
After matching the current URL and key, consider whether the stored key could be stale. Perhaps it was copied from a different stream, replaced after a reset, or retained in a script or configuration file that FFmpeg still reads. Search the actual command, environment variable or configuration source used by the running process; editing a note or a second script does not update the value that is being published.
If there is a specific reason to believe the credential has been exposed or invalidated, reset it through YouTube Studio and update the encoder with the new value. YouTube’s instructions for managing live stream settings explain key management. A reset makes the previous value unsuitable for this configuration, so find every FFmpeg process or saved setup that uses it before trying again.
Avoid resetting a key as the first response to every timeout or TLS message. It changes the credential, not the route to the endpoint or FFmpeg’s TLS capabilities, and can add another variable to the diagnosis. If the same connection error remains after updating the key, return to the URL, protocol and connectivity checks rather than resetting repeatedly.
When reporting the issue, provide the exact error text with the key redacted, the FFmpeg version and build configuration, and whether you copied the URL from the intended Live Control Room stream. State whether the chosen scheme is RTMP or RTMPS and whether you used a freshly copied or reset key, but never include the key itself. This gives another person useful evidence without exposing the credential.
Check FFmpeg protocol and TLS support
FFmpeg’s available protocols depend on how that particular build was compiled. Two machines can report the same FFmpeg version yet have different protocol support. Check the build you are actually running, not a different installation on the same machine. The command-line help and build configuration can help establish whether the relevant RTMP and TLS capabilities are present; consult the documentation for your package or distribution if the output is unclear.
This matters most when you select RTMPS. If the command cannot negotiate TLS, switching between keys will not supply the missing support. An SSL-related error, a protocol-not-found message or an immediate failure before a connection is opened should prompt you to verify the installed build and its enabled features. Do not infer from the fact that a command parses that its build can complete an RTMPS session.
If the required support is absent, use a build that includes the needed protocol and TLS capabilities or choose a supported publishing setup. Use a source you trust and check its documentation; the right choice depends on your operating system and how FFmpeg was installed. Do not download an unfamiliar binary merely because it promises to resolve a key error.
Keep local encoder health separate from connection support. If FFmpeg is consuming unusually high CPU, dropping frames or reporting encoder errors, those symptoms can affect the outgoing stream even when the URL is right. A practical guide to lowering CPU use on a continuous stream may help with that separate problem. First establish whether FFmpeg can open the selected output; then address the quality and stability of the media it sends.
Test outbound connectivity
When the URL, key, publishing form and protocol support all look right, check whether the machine can make an outbound connection to the selected endpoint. A firewall, router rule, managed network policy or hosting provider can block the required route. A timeout is a reason to test that path, not a verdict on the credential. Compare results from the same machine and network where possible, and note any proxy or restrictive network environment.
For RTMPS, follow YouTube’s troubleshooting guidance for the endpoint in use; it identifies port 443 as an option to try for relevant SSL errors. Do not substitute a different host or port from memory. If you are using RTMP, check that your network permits the outbound connection required by the URL YouTube gave you. A successful DNS lookup alone does not prove that the publishing connection can be established.
Separate local and remote evidence. Check whether FFmpeg reports that it opened the output connection, whether the Live Control Room receives a signal, and whether the local encode is healthy. If another supported encoder can reach the same endpoint from that network, that is useful evidence about FFmpeg’s build or command. If no encoder can reach it, investigate network egress and the endpoint before changing the key again.
For a useful support report, record the full error wording, the scheme, whether the destination came from the correct Live Control Room stream, the FFmpeg build details and the network context. Redact the key and, where necessary, the host. Note whether you tested the suggested port or another supported encoder. A generic “key rejected” summary is less useful than the first precise error FFmpeg prints.
If you want to avoid leaving a personal computer running for a continuous file-based broadcast after resolving the setup, StreamNeo can take away the need to keep FFmpeg open on your own machine: upload the video, provide the YouTube stream key, and the stream can continue from the cloud with monitoring and automatic restarts. It is YouTube-only, so it is not a substitute if you need a different destination or a custom FFmpeg pipeline.
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 a “stream key rejected” message prove the key is wrong?
No. Compare the current key and server URL from the intended Live Control Room stream, then check the output URL, scheme, muxer and connection path. A timeout or SSL error especially calls for endpoint, network or client-support checks before you conclude that the credential is invalid.
Should I change rtmp:// to rtmps:// in my command?
Only if you use the RTMPS endpoint YouTube supplies and your FFmpeg build supports the required TLS connection. Changing the scheme alone may leave the server or port wrong, and not every FFmpeg build has the same protocol support.
When should I reset the YouTube stream key?
Reset it when it may have been exposed, is known to be stale, or YouTube still rejects it after you have verified the current endpoint and publishing configuration. Then replace the old value in every process or saved configuration that uses it, and keep the new value out of public logs and screenshots.
What information can I share when asking for help?
Share the exact error text, FFmpeg version and build details, the RTMP or RTMPS scheme, and whether the URL and key came from the intended Live Control Room stream. Redact the key, and include relevant connection tests or network restrictions without posting a usable credential.