YouTube rejecting an FFmpeg stream from a VPS does not point to one universal fault. Start with the exact health message in Live Control Room and the FFmpeg lines around connection and output initialisation, then follow the branch they indicate.
A stream that never reaches YouTube needs a different investigation from a stream that arrives with an unsupported codec, bitrate or keyframe pattern. This guide helps you separate those cases without assuming access to your VPS or claiming that one command fixes every rejection.
Capture the exact error before changing anything
Open YouTube Live Control Room and look at the stream health indicator while FFmpeg is running. Copy the complete message, not only a short description such as “not showing” or “rejected”. YouTube can report issues involving audio, video, bitrate, frame rate, codec, keyframe frequency and stream configuration, so the wording determines which part of the setup deserves attention.
Also save the FFmpeg output from the point where it opens the input through the point where it attempts to publish the output. You are looking for lines that show the input streams, the selected output streams, the destination URL with its secret removed, and any error after connection. A log that says the output was initialised is useful evidence, but it does not by itself prove that YouTube accepted the media.
Do not paste your stream key into a forum, support ticket or shared document. Replace it with [redacted] before sharing a command or log. If the key has already been exposed, create a new one in Live Control Room and update the sender rather than continuing to troubleshoot with a credential that is no longer private.
Keep the two observations separate:
| What you observe | First branch to investigate |
|---|---|
| YouTube shows no incoming data and FFmpeg cannot establish or maintain the connection | Destination, protocol, port, DNS, routing or VPS egress |
| YouTube receives data but reports incorrect video settings | Codec, resolution, frame rate, bitrate or encoder parameters |
| YouTube reports an audio problem | Audio codec, sample rate, channels or missing audio stream |
| YouTube reports a keyframe or GOP problem | Keyframe interval and GOP structure |
| FFmpeg fails before publishing | Input file, local permissions, encoder availability or command syntax |
These are starting points, not guaranteed interpretations of every message. YouTube’s Live Control Room health guidance and its live stream health documentation are the authoritative references for the current issue categories.
If the wording is vague, record when the message appears and whether it changes after FFmpeg starts. “No data” during the first moments of a connection is different evidence from a persistent codec warning after YouTube has clearly received the stream.
Confirm the destination, protocol and stream key
A valid input file and a working FFmpeg installation cannot compensate for a wrong YouTube destination. In Live Control Room, compare the server URL and stream key with the values used by FFmpeg. Treat them as separate fields when building the publishing destination, and check for copied spaces, missing characters or a key belonging to a different live event.
The key is a credential, while the server URL identifies the ingest destination. Do not assume that replacing one with the other, or combining them in a different order, will produce a valid address. Use the format shown in YouTube’s current instructions and keep the complete destination out of public logs.
Check the protocol as well. YouTube recommends RTMPS for general encoder use. RTMP and RTMPS are related, but they are not interchangeable in every connection. Google’s RTMPS ingestion guide explains that a cleartext RTMP connection sent to a YouTube endpoint expecting RTMPS can time out without returning a useful response. That can look like a firewall problem or a dead stream when the first issue is the protocol and endpoint pairing.
For a conventional FFmpeg FLV push, compare the protocol in the command with the endpoint YouTube currently provides. FFmpeg’s official protocol documentation describes the general RTMP family and its options. Its example command shape is documentation for the protocol, not a verified YouTube command for your event. Your endpoint, key, output format and encoding settings still need to match YouTube’s instructions.
If the key is not visible or the event is not behaving as expected, use the separate troubleshooting guide for a YouTube stream key not showing in Live Control Room. Do not rotate keys repeatedly while leaving the destination or protocol unverified, because that changes two variables without telling you which one mattered.
Check codec, container and ingest-profile compatibility
Once YouTube receives data, read the output stream summary in the FFmpeg log. Confirm what FFmpeg is actually sending rather than what you intended to send. A source file may contain a codec, frame rate, pixel format or audio track that causes FFmpeg to select different output properties unless you set them explicitly.
YouTube’s current encoder guidance lists H.264, H.265/HEVC and AV1 as supported video codecs, and AAC or MP3 as supported audio codecs. The correct choice also depends on the ingest mode and the capabilities of the FFmpeg build and encoder available on your VPS. A codec that is supported in principle may still be unsuitable if the selected protocol, container or installed build cannot produce it correctly.
For a conventional FLV publication workflow, inspect the output container and the video and audio streams together. If the health message identifies an unsupported audio codec, changing the video bitrate will not address it. If the message identifies a video codec or format issue, inspect the video encoder and output stream instead of adding network retry options.
Frame rate and resolution matter alongside codec. Check that the output is intentionally, for example, 30 or 60 frames per second rather than inheriting an unexpected value from the source. The same applies to 720p or 1080p output. YouTube’s bitrate recommendations are tied to resolution and frame rate, so an output that is labelled or encoded differently from your plan can move into the wrong guidance range.
Keyframes deserve their own check. YouTube’s current encoder settings page recommends a two-second keyframe frequency and says not to exceed four seconds. If Live Control Room reports a keyframe mismatch, inspect the GOP and keyframe options produced by the selected FFmpeg encoder. YouTube’s health guidance also identifies open GOP as unsupported by its ingest, so investigate an open-GOP warning rather than assuming that the interval alone is correct.
The exact option names can vary between FFmpeg encoders and builds. Do not copy an encoder flag merely because it appears in a command for a different codec. First identify the encoder shown in your output summary, then consult the documentation for that encoder and confirm the resulting stream properties in the log.
For audio, confirm that an audio stream exists and that it uses AAC or MP3 when that is what your selected workflow requires. YouTube’s current guidance recommends 44.1 kHz for stereo and 48 kHz for 5.1 surround, with 5.1 over RTMP or RTMPS supported only for AAC. If the health message names audio, review sample rate and channel layout as well as the codec.
Review bitrate and stream-health feedback
Do not choose one bitrate as a universal repair. YouTube’s recommended values depend on the codec, resolution and frame rate. For H.264, its current table gives 5 Mbps as the minimum and 14 Mbps as the recommended rate for 1080p30, while 1080p60 has a 6 Mbps minimum and 17 Mbps recommendation. For 720p30 and 720p60, the table gives 3 Mbps minimum and 8 Mbps recommended for H.264.
Those figures are current page recommendations, not a promise that any particular VPS connection will sustain them. YouTube’s table also contains separate guidance for AV1 and H.265/HEVC, so do not apply the H.264 figures to another codec without checking the relevant row. Read the current YouTube encoder settings for the exact combination you are sending.
Constant bitrate, or CBR, is part of the comparison. If your command uses variable rate control or allows large bitrate swings, YouTube may report a bitrate or stream-health issue even when the average looks close to your target. Review the encoder’s rate-control output and the health message together. A high average does not prove that the stream is consistently within the expected range.
A bitrate problem can also be caused by the path between the VPS and YouTube. If FFmpeg reports connection interruptions and YouTube shows missing or unstable data, separate the media target from the network evidence. If FFmpeg is publishing steadily and YouTube flags an incorrect setting, stay with output configuration before changing the VPS.
Use the health indicator as feedback after each controlled change. Note the message before the change, the relevant FFmpeg output, and the message afterwards. If the warning moves from “no data” to a codec warning, that is useful progress: it suggests that the connection branch and the media branch are not the same problem. It still does not prove that every setting is correct.
For a deeper explanation of choosing a target without treating bitrate as a magic number, see this bitrate guide for 24/7 YouTube live streams. If you are also deciding whether your VPS can carry the workload overnight, compare the operational trade-offs in cheap VPS versus cloud streaming for a 24/7 YouTube channel.
Inspect the VPS connection and outbound path
When YouTube reports no incoming data, or FFmpeg times out before it can publish, investigate the path from the VPS rather than immediately changing codec flags. Confirm that the VPS can resolve the destination hostname, establish the required protocol connection and send traffic through the required port. The precise checks depend on the VPS provider, operating system and network policy.
A timeout is evidence of a connection problem, but not proof of one particular cause. Possible causes include a protocol mismatch, a blocked outbound port, provider egress restrictions, DNS failure, routing trouble or an endpoint copied incorrectly. The research for this guide does not identify which of those exists on any individual VPS, and an article cannot inspect your server from here.
Ask the VPS provider a focused question if the protocol and destination have already been checked. Give them the region, the destination hostname and port with the stream key removed, the time of the attempt, and the exact connection error. Ask whether outbound connections using the required protocol are permitted. Do not send them the stream key unless you have a separate, appropriate security process and have decided that exposure is acceptable.
If YouTube receives media but reports an invalid codec, frame rate or bitrate, changing VPS hardware or adding reconnect flags is not the first move. Those flags may help a sender recover from an interruption, but they do not convert an unsupported audio stream into a supported one. Follow the category shown by Live Control Room.
A VPS can also be locally healthy while its route to YouTube is unsuitable for a particular continuous stream. A successful shell login or a working download from another site does not establish that the YouTube ingest connection is correct. Test the exact destination and protocol required by the workflow, while avoiding tests that expose the key.
If a continuously running channel is becoming difficult to maintain because every restart depends on your own VPS, the issue may be operational rather than a single rejected command. StreamNeo removes the need to keep your computer or a self-managed sender running by accepting the prepared video and YouTube key once, then monitoring and restarting the broadcast automatically when it drops.
Change one variable and retest
Once you have captured the evidence, make one controlled change. If the message concerns the destination, change the endpoint or protocol pairing, not the codec. If it concerns audio, change the audio output and leave the video settings alone. If it concerns keyframes, change the relevant GOP or keyframe configuration and keep the bitrate constant.
A useful retest has the same input file, destination and test duration, with only the selected variable changed. Watch both sides: FFmpeg’s connection and output lines, and YouTube’s health message. Write down whether the stream remains invisible, becomes detectable, changes to an encoder warning or reaches a healthy state.
Do not stack several popular command-line fixes into one attempt. Replacing the protocol, changing the encoder, doubling the bitrate and adding reconnect flags at the same time may produce a working stream, but it leaves you without a reliable explanation and can create a new incompatibility. This matters when the stream must run overnight and nobody is available to undo an untested combination.
Test with content that resembles the planned channel. YouTube advises checking representative audio and movement before going live. A still devotional image, a lofi visual loop and a local news sequence can exercise different parts of the pipeline. If your normal file has no audio, do not use an audio warning from another test to diagnose it as though it came from the normal stream.
When a change helps, preserve the working command and record the output properties it produced. Keep the key in a protected environment variable or other secret store rather than in a public script. Then repeat the test after a clean restart of the sender, because a command that works only in an already-running session is not yet a dependable overnight procedure.
For a media-file workflow, the guide to looping a nature video for YouTube Live with FFmpeg may help you separate looping behaviour from the publishing path. The important point here is to verify the final output stream, not merely the fact that FFmpeg can read the file.
Know when to consult current YouTube guidance
YouTube changes encoder recommendations, supported workflows and Live Control Room wording over time. Treat the official encoder settings page and health documentation as the final reference when a command copied from an older article conflicts with what your account shows now. This is especially important for protocol, codec and bitrate choices.
Check the current guidance when you change resolution or frame rate, move from H.264 to AV1 or HEVC, use a different ingest protocol, add surround audio, or see a health category that your existing notes do not explain. The ingestion comparison for RTMP, RTMPS, HLS and DASH is useful when you are considering a specialised pipeline, but those protocols are not interchangeable in every conventional FFmpeg workflow.
Do not infer that a successful connection means YouTube has approved the stream for every purpose. Channel policies, content rights, monetisation requirements and event settings are separate matters. Review the current official pages for your situation, and do not treat a technical health message as a legal or policy decision.
If official guidance does not explain the result, collect a minimal support record: the exact Live Control Room message, the time and event, the protocol and destination host with secrets removed, the FFmpeg version and build, the output stream summary, and the relevant stderr lines. Include whether YouTube saw any data. That record gives a provider or YouTube support team something more useful than a screenshot saying that the stream was rejected.
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
Why is YouTube not detecting my FFmpeg stream from the VPS?
First check the exact health message and whether FFmpeg reports a successful connection to the intended destination. A wrong key, endpoint or RTMP-versus-RTMPS pairing can prevent data from arriving, while a stream that arrives with invalid media settings needs a codec, bitrate or keyframe investigation.
Does changing the bitrate fix every rejected stream?
No. Bitrate is only one possible health category, and the appropriate value depends on codec, resolution and frame rate. If YouTube reports an audio, protocol or keyframe issue, changing bitrate alone addresses the wrong branch.
Should I use RTMP or RTMPS with FFmpeg?
YouTube recommends RTMPS for general live encoder use, but the protocol must match the endpoint and the capabilities of your workflow. Check the current YouTube instructions and FFmpeg protocol documentation rather than changing only the URL prefix and assuming the rest of the destination is unchanged.
What should I share when asking for VPS support?
Share the provider, region, destination hostname and port with the stream key removed, plus the exact connection error and relevant FFmpeg lines. Never include the stream key in a public log or support request unless you have deliberately accepted the security risk and have a process for replacing it.