If YouTube accepts your stream from OBS but not from FFmpeg, compare the actual server URL, key, protocol, FFmpeg build, command and error before settling on a cause. OBS working is useful evidence, but it does not prove that FFmpeg is using the same ingest address or supports the same protocol.
Start with the connection details, then separate a connection or authentication failure from an encoder or network problem. The checks below are intended to narrow the fault, not guess at a particular command you have not shared.
Why OBS can work while FFmpeg fails
A stream key is only one part of the configuration. YouTube’s encoder instructions treat the server URL and stream key as separate values: the URL identifies where the encoder sends the feed, while the key is used like a password for that stream. Two encoders can use the same key and still differ in URL, protocol, key formatting or client support. See YouTube’s encoder setup guidance when checking which values belong in each field.
OBS and FFmpeg are also different applications, and the details in one application do not automatically carry over to the other. OBS may have a current server address saved in its profile, while an FFmpeg invocation may use an older address or a different transport. Their error messages and build capabilities can differ too. A successful OBS test narrows the investigation to the path that differs; it does not establish that FFmpeg is configured correctly or that the network permits its connection.
Keep the first comparison factual. Write down the server URL and protocol shown in the working OBS profile, and compare them with the destination used by FFmpeg. Do the same for the key, but do not copy it into a public post or an unredacted log. Then note whether FFmpeg fails before connecting, reports an SSL or timeout error, or connects and produces a stream that YouTube flags as unhealthy. Those are different branches of the diagnosis.
Recheck the current URL and key
Open YouTube Live Control Room and copy the current stream URL and key again. Compare both values with the FFmpeg configuration rather than assuming the key is the only credential that matters. YouTube documents the URL and key as values that are entered in the encoder; its stream-key instructions also explain how to manage the key.
Pay particular attention to whether the key has been reset or replaced since the last time FFmpeg worked. A key copied from an earlier setup may no longer be the active one. Check for accidental whitespace, a missing character, quoting or shell-expansion issues in the way the value is supplied. These are possibilities to inspect in the actual invocation, not conclusions that can be drawn from the title of the problem.
Do not post the complete key when asking for help. Redact it in a command, screenshot or log, preserving only a marker such as [REDACTED] so someone can see where the value goes without being able to use it. If you have already exposed the key publicly, replace it in Live Control Room and update your encoders.
If OBS and FFmpeg are being compared at different times, also consider whether the Live Control Room stream configuration changed between tests. Use one current set of values for both tests and record when each was attempted. This avoids comparing a successful OBS run from last week with an FFmpeg attempt using details that have since changed.
Check RTMP versus RTMPS
Confirm the protocol as well as the hostname and port. YouTube recommends RTMPS; the RTMPS address is available in Live Control Room, and the ordinary RTMP address may be what you see by default. Select or reveal the RTMPS URL deliberately instead of assuming that an address from an old setup is equivalent. YouTube’s RTMPS troubleshooting page describes how to approach connection and SSL messages.
A protocol mismatch can look like a network or certificate problem. If YouTube reports that the RTMP server sent an invalid SSL certificate, first confirm that you are using the correct RTMPS server address. YouTube advises trying port 443 if the URL is correct and the SSL error remains. Treat that as a documented troubleshooting step, not a reason to change arbitrary parts of the address.
For a connection timeout, check the URL and whether the encoder supports RTMPS. The fact that OBS connects does not answer whether the FFmpeg build in use supports the protocol or whether the particular invocation requests it correctly. That needs evidence from the FFmpeg version, build configuration and command.
Keep a record of which protocol was tested, the exact server address with sensitive material omitted, and the resulting error. Change one thing at a time. If you replace the URL, switch protocol and alter encoding settings together, a successful retry will not tell you which change mattered.
Verify the FFmpeg build and invocation
Do not infer a universal FFmpeg fix from this symptom. The correct interpretation depends on the actual command, FFmpeg version and build, and full error output. A command that works on one installation may not be valid for another, and the available YouTube guidance does not specify FFmpeg’s exact command-line syntax or what protocols a particular build includes.
Collect the version and build configuration from the same FFmpeg executable you use to stream. If more than one installation is present, note the executable path or otherwise establish which one is running. Then inspect the complete invocation, including the output destination and options affecting the connection. Keep the key redacted, but retain enough structure to show where the destination and key are supplied.
Compare that invocation with the working OBS values: destination, protocol and key source. Do not assume that an OBS field maps one-to-one to a particular FFmpeg argument without checking the syntax for your installation. If a command uses an address assembled from separate pieces, compare the assembled result, not only the fragments in a script or configuration file.
You can also use the OBS-versus-VLC playlist comparison as a reminder that different encoder paths have their own configuration and playback behaviour. It is not evidence that a particular FFmpeg flag is wrong; the relevant comparison here remains the actual command and build. If you are not confident reading the invocation, share a redacted copy along with the version output and exact error with someone who can verify it against current FFmpeg documentation.
Review YouTube encoder settings after connection
Codec and bitrate settings matter, but put them in the right place in the sequence. First establish whether FFmpeg reaches YouTube and whether the key is accepted. If the client cannot connect, changing video bitrate is unlikely to explain the initial failure. If it connects but Live Control Room reports a poor or unsupported stream, then examine the media output.
YouTube’s encoder settings guidance lists RTMP or RTMPS as ingest protocols, supported video codecs including H.264, H.265 and AV1, and AAC or MP3 audio. It recommends constant bitrate (CBR), a two-second keyframe interval and says that interval should not exceed four seconds. Its guidance lists frame rates up to 60 fps. Check the current page for the supported settings and bitrate recommendations that match your codec, resolution and frame rate; there is no single bitrate that applies to every stream.
If you are streaming a 1080p playlist, for example, do not copy a bitrate from a 4K, 60 fps recommendation and treat it as universal. Compare the output mode you actually selected with the matching entry in YouTube’s current table. This is a media-quality check, not a substitute for correcting a bad ingest URL or a failed TLS connection.
Inspect both audio and video in FFmpeg’s output and in Live Control Room. Check that the intended tracks are present and that the stream’s picture and sound behave as expected. If the output is poor locally, review the encoder’s own errors and the computer’s load before blaming YouTube. A healthy-looking local output with a connection problem points you back towards protocol or outbound connectivity; a connected but flagged feed calls for media-setting checks.
For readers comparing other encoder profiles, the OBS 1080p Kannada playlist bitrate guide is relevant as an example of matching settings to a particular output mode. Use it as context, not as a universal FFmpeg preset: the codec, resolution and frame rate must match before a bitrate comparison is useful.
Read timeout and certificate errors as clues
An error is evidence about where to look next, not proof of a single cause. Capture the complete message and identify whether it appears immediately, after a delay, or only after YouTube has received media. A short fragment such as “failed” omits the distinction between an address problem, a protocol negotiation issue, a rejected key and an encoder problem.
For a timeout, verify the current server URL and whether the FFmpeg client supports the protocol you selected. Then check whether the same client can reach the destination from the network where it runs. A timeout does not by itself prove that the key is wrong: it may occur before authentication is reached.
For an SSL certificate error, check that the address is the RTMPS URL from Live Control Room, not an RTMP address paired with an SSL expectation. If the URL is correct, YouTube’s troubleshooting guidance suggests trying port 443. Do not disable certificate validation as a shortcut; that would remove a security check rather than establish that the endpoint is correct.
An authentication or key-related rejection belongs in a different branch from a timeout or certificate failure. Re-copy the current key and verify how the command supplies it. If FFmpeg connects and YouTube receives media but reports an unhealthy stream, move on to codec, keyframe, bitrate and audio/video checks. Recording the exact stage and text keeps you from changing unrelated settings in response to a vague symptom.
Check outbound network access
Once the URL, protocol and FFmpeg support are plausible, determine whether the machine running FFmpeg can make the outbound connection. OBS may have been tested on another computer or network, and a cloud host, office connection or home router can have different outbound rules. Compare the tests from the same machine and network where possible before concluding that the key behaves differently.
YouTube’s encoder troubleshooting advice includes checking outbound internet connectivity. If the test indicates a connection problem, its guidance is to contact your internet service provider. Where you manage a firewall or network policy, ask the administrator whether outbound access required for the selected ingest protocol is permitted. Avoid opening broad inbound access or changing firewall rules without understanding what is being changed.
A timeout can arise from the destination, protocol support or the path out of the network, so preserve the evidence from each layer. Record whether other applications can reach the internet, whether the failure occurs on more than one network, and whether the same FFmpeg build works from a different connection. These observations can help separate a network-specific block from a build or command issue, but they do not replace the exact error output.
If the channel is intended to run continuously, it is useful to distinguish a one-time connection failure from a stream that later drops. The guide to YouTube streams disconnecting on Indian internet covers a broader connectivity problem; here, first establish whether FFmpeg can connect at all. That distinction prevents a remedy for intermittent drops from obscuring a failure at startup.
Collect the right evidence for the next step
A useful troubleshooting report lets someone reproduce the configuration without exposing the key. Collect the items below before changing more settings. Include timestamps and note each test change so the sequence is clear.
| Evidence | What to include | What to redact or preserve |
|---|---|---|
| YouTube destination | Current server URL and whether it is RTMP or RTMPS | Omit the key; retain enough of the address to identify the protocol and host |
| Key configuration | Where the key is supplied and whether it was refreshed | Replace the value with [REDACTED] |
| FFmpeg identity | Version, build configuration and executable used | Keep the full version/build text where practical |
| Invocation | The complete command or relevant script/configuration | Redact the key and any unrelated secrets; retain options and destination structure |
| Error and timing | Full error text, when it occurs, and whether media was sent | Do not trim away preceding lines that show the connection stage |
| Stream health | What Live Control Room reports and what you see/hear locally | Note whether a connection was established before a media warning |
| Network context | Machine, network type and whether another network changes the result | Do not publish private network credentials or public IP details unnecessarily |
YouTube’s troubleshooting material also recommends checking encoder errors and CPU load when output is poor. Include relevant local observations, but avoid turning a log dump into a public disclosure: stream keys, tokens and credentials should be removed first. If the key appears in a publicly accessible log, treat it as exposed and rotate it.
When asking for help, state what OBS used and what FFmpeg used, rather than saying only that “the same key works”. The comparison should show whether the server and protocol were actually the same, whether FFmpeg’s build supports the selected protocol, and what error appeared. That is enough to make the next diagnostic step evidence-led without asking anyone to guess from the application names.
If you need a broadcast that does not depend on keeping a local FFmpeg process and computer running, StreamNeo removes that specific operational burden by turning an uploaded file into a YouTube live stream that can continue with your computer switched off. It does not resolve a broken FFmpeg command, and this is a YouTube-only workflow, so first decide whether a file-based channel fits what you are trying to broadcast.
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 OBS working prove my stream key is correct?
It shows that OBS was able to stream with the configuration it used at that time, but it does not prove that FFmpeg is using the same key, URL or protocol. Re-copy the current URL and key from Live Control Room and compare both configurations without publishing the key.
Should I change bitrate when FFmpeg cannot connect?
Not as the first step. Establish whether the destination and protocol are correct and whether FFmpeg reaches YouTube; examine bitrate and codecs after a connection exists or Live Control Room identifies a media issue.
What should I send someone who is helping debug FFmpeg?
Send the FFmpeg version and build configuration, a redacted complete command, the full error text and the current protocol/URL details. Include when the error occurs and what Live Control Room reports, but remove the stream key and other credentials.
What does an RTMPS certificate error mean?
It is a reason to verify the RTMPS server address and protocol, not proof of one specific fault. YouTube advises checking the RTMPS URL and, if it is correct, trying port 443; retain the exact error when reporting the result.