A VPS can send a 1080p live stream to YouTube with FFmpeg, but 1080p is not a setting you can assume will work on every server. Your source, frame rate, encoder, CPU allocation and sustained outbound capacity all need to support the chosen output.
The command below is a template for a prerecorded video file, not a universal VPS profile. Use YouTube's current encoder guidance, protect your stream key, and test the complete path with representative movement and audio before relying on it overnight.
Confirm what you are streaming and what the VPS can do
Start by identifying the input. A prerecorded MP4 file, camera, desktop capture, playlist, network feed and generated video each need a different FFmpeg input section. The example in this guide uses one prerecorded file and -re to send it at its normal playback rate. It does not show how to capture a camera or desktop.
A file that is described as 1080p may not actually be 1,920 by 1,080, and its frame rate may be 25, 30 or 60 frames per second. Inspect the source before choosing the output. You can use FFmpeg's probing tools or another media inspection utility to check the dimensions, frame rate, audio tracks and codec. The source's properties matter because converting a smaller file to 1080p adds processing without adding detail.
The VPS is responsible for reading the input, encoding video, encoding audio, and maintaining an outbound connection to YouTube. Do not infer that it can do this from a plan name, a nominal port speed or the fact that it can play the file. Sustained CPU allocation, shared-host contention, provider traffic limits, the complexity of the pictures and the installed FFmpeg build can all affect the result.
Before configuring the stream, check these practical points:
- The source can be read continuously from the path or storage location.
- The VPS has enough available CPU for the selected software encoder, or has a suitable hardware encoder that you have actually confirmed is available.
- The VPS can sustain the selected output rate with headroom for audio and protocol overhead.
- The operating system can keep FFmpeg running after you disconnect from SSH.
- The FFmpeg build supports the codec, muxer and RTMPS protocol you intend to use.
If you are still choosing the machine rather than configuring one, the considerations in VPS setup guidance for a 24/7 devotional stream are relevant, but do not treat any general VPS description as proof that a particular instance will encode your file in real time.
Prepare a representative 1080p input
Use a sample that resembles the material you will actually broadcast. A still devotional slide, a fast gaming replay and a local news loop place different demands on an encoder. Test with speech, music or other intended audio as well, because an apparently healthy video-only test can conceal an audio mapping or level problem.
The cleanest case is a file already framed at 1,920 by 1,080 with the frame rate you want to send. If the source is a different shape, FFmpeg can scale it into a 1920:1080 canvas and add bars rather than stretching faces or text. The command later in this guide does that with scale, pad and setsar.
That filter is a practical starting point, not a requirement. If your source is already correctly framed, removing unnecessary scaling may reduce CPU work. If it is portrait, ultrawide or substantially smaller, decide whether bars, cropping or a different output canvas is appropriate. Do not label an upscaled low-resolution source as evidence that you are delivering native 1080p detail.
Check the audio deliberately. The example maps the first video stream and optionally maps the first audio stream. Optional audio mapping prevents FFmpeg from failing when a file is silent, but it does not create useful audio. If the input has several tracks, subtitles or commentary channels, select the intended streams explicitly and test the result.
For a continuous channel, also decide what happens when the file ends. This guide does not add looping or playlist logic. A one-file process normally reaches end of input and exits unless you build a separate loop or playlist arrangement. If your concern is keeping a broadcast alive after a file finishes, see how to keep a YouTube livestream from ending when the video file finishes.
Check YouTube's current ingest guidance
Open YouTube Help's page on live encoder settings, bitrates and resolutions immediately before configuring a production stream. YouTube can change its recommendations, and live-ingest settings should not be confused with separate recommendations for uploading an ordinary video.
The current guidance lists H.264, H.265 and AV1 as supported video codecs, up to 60 frames per second, and AAC or MP3 for audio. For stereo audio it lists 44.1 kHz and 128 kbps. For SDR it recommends Rec. 709 and 8-bit colour. Use the current official page if your source or FFmpeg build gives you a choice outside the simple H.264 example here.
For H.264 live ingest, YouTube's listed recommended video bitrate is 10 Mbps for 1080p at 30 fps and 12 Mbps for 1080p at 60 fps. The same page lists minimum H.264 figures of 5 Mbps at 1080p30 and 6 Mbps at 1080p60. These are operational ingest settings, not a promise that a VPS can encode or upload them successfully.
YouTube recommends constant bitrate, a keyframe interval of two seconds, and says not to exceed four seconds. It recommends RTMPS for ingest. The exact server URL and stream key are obtained from YouTube Live Control Room, rather than copied from an old tutorial.
A higher bitrate is not automatically a better result for every viewer or source. It uses more outbound capacity and may not improve a mostly static image. The practical trade-off is discussed in whether increasing YouTube Live bitrate improves viewer quality. Select a frame rate and bitrate that match the movement in the programme and the capacity you can verify.
Choose the encoder, bitrate and keyframes
For a straightforward and widely compatible setup, H.264 video in an FLV output is a reasonable starting point. The example uses libx264, but that encoder must exist in your FFmpeg build. A slower preset can use more CPU, while a faster preset generally reduces CPU pressure at a possible quality cost. veryfast below is only a starting point to measure, not a YouTube requirement.
At 30 fps, a two-second keyframe interval means 60 frames between keyframes. At 60 fps, it means 120 frames. The target bitrate, frame rate and GOP settings need to describe the same output. If you change one, review the others instead of changing only the resolution label.
The following choices illustrate one conditional case:
| Output case | Video bitrate from YouTube's current guidance | Two-second GOP at this frame rate | Main trade-off |
|---|---|---|---|
| 1080p30 H.264 | 10 Mbps recommended; 5 Mbps listed minimum | 60 frames | Lower motion demand and lower encoding load than 60 fps |
| 1080p60 H.264 | 12 Mbps recommended; 6 Mbps listed minimum | 120 frames | Smoother motion, with higher upload and encoding demands |
The table does not establish a required VPS specification. You still need to measure the chosen workload. If the source is mostly static and the machine struggles at 60 fps, 30 fps may be the more dependable choice. If movement is important and the VPS can sustain it, 60 fps may be appropriate.
The other officially listed codecs can be useful when your build and workflow support them, but codec support is not enough by itself. Confirm that your FFmpeg build can encode the chosen format, mux it for the selected output and send it through RTMPS. Compatibility with your intended YouTube workflow and the available CPU or hardware encoder matters more than choosing a codec by name.
Use the current ingest URL and stream key
Create or open the live stream in YouTube Live Control Room. YouTube's encoder setup instructions explain where to obtain the stream URL and key. The URL is the destination; the key identifies the stream. Treat the key as a password.
This prerecorded-file command is an illustrative 1080p30 H.264 template:
ffmpeg -re -i /path/to/input.mp4 \
-map 0:v:0 -map 0:a:0? \
-vf "scale=1920:1080:force_original_aspect_ratio=decrease,pad=1920:1080:(ow-iw)/2:(oh-ih)/2,setsar=1,fps=30" \
-c:v libx264 -preset veryfast -pix_fmt yuv420p \
-b:v 10M -maxrate 10M -bufsize 20M -g 60 -keyint_min 60 -sc_threshold 0 \
-c:a aac -b:a 128k -ar 44100 \
-f flv "rtmps://a.rtmp.youtube.com/live2/${YOUTUBE_STREAM_KEY}"
The command assumes that the build includes libx264, AAC encoding, FLV muxing and RTMPS support. Check locally with:
ffmpeg -encoders
ffmpeg -muxers
ffmpeg -protocols
For a 60 fps version, change the filter to fps=60, use the bitrate appropriate for that case, and set the GOP values to 120 frames. Do not make that change merely because the output is called 1080p. Frame rate is part of the workload.
-maxrate keeps peaks near the selected target and -bufsize 20M represents a two-second video buffer at 10 Mbps in this example. These are practical encoder settings, not YouTube's guarantee for your VPS. Confirm their effect with the installed encoder and inspect the actual output.
Do not paste a real key into a public script, screenshot, article or repository. Inject YOUTUBE_STREAM_KEY through a protected environment, service manager configuration or another secret-handling method. Avoid exposing it in shell history where possible. If it is disclosed, use YouTube's current stream-management controls to reset it before continuing.
Test FFmpeg output and YouTube stream health
Run the first test with a private or unlisted stream and a file that contains the same kind of movement and audio as the real channel. YouTube specifically advises testing with audio and movement similar to the intended stream. A few seconds of a static image is not a representative overnight test.
Watch FFmpeg's terminal output. The encoding speed should remain at or above real time rather than falling progressively behind. Look for connection resets, repeated reconnect attempts, encoder errors, input read failures and messages indicating dropped frames. Note the output frame rate and bitrate rather than relying on the command's intended values.
At the same time, open YouTube Live Control Room and inspect the stream health messages. Check that YouTube sees the expected resolution, frame rate, audio and bitrate. Let the test run long enough to expose a sustained upload or CPU problem, rather than stopping as soon as the preview appears.
A useful test record includes the input filename, output dimensions, frame rate, encoder preset, observed CPU use, encoding speed, outbound traffic and YouTube health messages. Record what changed between attempts. This makes it easier to distinguish an authentication error from a capacity problem.
Keep the VPS's own monitoring separate from YouTube's view. Local CPU graphs can show that the process is busy, while YouTube may show unstable ingest. Conversely, a clean local process does not prove that the destination received every packet. Use both sets of evidence before leaving the channel unattended.
If the live channel is intended to run continuously, arrange for process supervision and logging appropriate to your operating system. A service that restarts FFmpeg can recover from a process exit, but it cannot make an undersized CPU or inadequate upload path reliable. Test the restart behaviour and make sure a failed process does not create multiple competing broadcasts.
Troubleshoot resource and upload constraints
Work through problems in a fixed order. First confirm the stream URL and key. Then check that the installed build supports the chosen encoder, muxer and RTMPS protocol. Next inspect FFmpeg's input, encoding speed and connection messages. Finally compare the actual output with YouTube's stream-health information.
If encoding speed falls below real time, check CPU use, input complexity, scaling and the selected preset. You could reduce the output frame rate, use a faster preset, remove unnecessary scaling or investigate an available hardware encoder. Retest the complete path after every meaningful change. Do not silently lower the output and continue calling it a 1080p stream.
If the video encodes on time but YouTube reports unstable ingest, measure sustained outbound capacity to the ingest destination. YouTube notes that total stream bitrate cannot exceed available upload bandwidth. On a VPS, account for audio and protocol overhead, and leave practical headroom rather than treating an advertised port speed as a sustained guarantee.
A rate that passes a short speed test may not remain available during a long broadcast. Provider traffic policies, contention and routing can affect a real stream. The result you need is not a single impressive test number, but a stable upload while FFmpeg is producing the chosen output.
If YouTube reports missing or irregular keyframes, review the frame-rate filter, GOP calculation and encoder options. At 30 fps, the example's -g 60 targets two seconds. At 60 fps, it needs the corresponding 120-frame value. Check the actual output rather than assuming that the option was accepted as intended.
If there is no sound, verify that the input really contains an audio stream, that the selected map points to it, and that the AAC encoder is available. For a silent source, decide whether you need generated audio or whether the channel's format permits silence. A successful video connection does not mean the audio requirement has been met.
If the connection repeatedly fails, check firewall rules, DNS, certificate support and the RTMPS URL supplied by YouTube. Re-copying an old URL from a blog post is less reliable than taking the current value from Live Control Room. Rotate the key if it has appeared in logs or shared configuration.
For a channel where maintaining a VPS, FFmpeg build and restart process is itself the main risk, a managed workflow such as StreamNeo removes the need to keep your own computer running and can restart a dropped file-based broadcast automatically, but it is not a VPS and should not be treated as a guarantee of 1080p output.
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
Can any VPS stream 1080p to YouTube with FFmpeg?
No. The VPS must encode the chosen source in real time and sustain the required outbound rate, with capacity for audio and overhead. CPU allocation, encoder support, provider limits and routing all need to be tested for the particular workload.
Is 10 Mbps always required for 1080p?
No single figure applies to every situation. YouTube's current H.264 guidance lists 10 Mbps as the recommended 1080p30 video bitrate and 5 Mbps as a listed minimum, while 1080p60 is listed at 12 Mbps recommended and 6 Mbps minimum. Use the current official table and validate the result in YouTube's stream health.
Should I use -re for every FFmpeg input?
No. In this guide it paces a prerecorded file at its normal playback rate. Camera, desktop, playlist and network inputs have their own timing behaviour, so adding -re without understanding the input can produce the wrong result.
What should I do if my stream key is exposed?
Treat it as compromised and reset it through YouTube Live Control Room before running the production stream. Keep future keys out of public scripts, source control, screenshots and unprotected logs.