A continuous YouTube stream using NVENC works only when three separate dependencies line up: the actual VPS must expose supported NVIDIA hardware and drivers, your FFmpeg build must include an NVENC encoder, and the outgoing settings must suit YouTube Live. Installing FFmpeg alone does not prove that the hardware path is available.
You can verify each dependency on the real VPS before committing to a long-running broadcast. The checks below use a looping file, an H.264 NVENC example and YouTube’s current ingest guidance, but the command remains a starting point rather than a universal configuration.
Understand what NVENC depends on
NVENC is NVIDIA’s dedicated hardware video-encoding block. It is separate from the general CPU workload, but FFmpeg can use it only when the environment where FFmpeg runs can access supported NVIDIA hardware and a suitable driver. NVIDIA’s FFmpeg integration guide describes the hardware path and names encoders including h264_nvenc, hevc_nvenc and av1_nvenc.
That makes NVENC a property of the actual runtime, not simply of the VPS provider’s product name. A plan may be described as GPU-enabled while the selected instance, virtual machine, container or permissions do not expose a device to your process. Conversely, an FFmpeg binary may list NVENC while the driver or device access needed at runtime is missing.
There are therefore three checks to keep separate:
| Dependency | What you need to establish | A useful check |
|---|---|---|
| NVIDIA hardware | The VPS exposes an NVIDIA GPU to the environment running FFmpeg | nvidia-smi -L |
| Driver and device access | The driver is available and the process can use the device | Run nvidia-smi and an encode test |
| FFmpeg support | The installed build exposes an NVENC encoder | ffmpeg -hide_banner -encoders |
A CPU-only VPS can still run FFmpeg with a software video encoder, but that is a different setup. Do not assume its performance, power use or ability to sustain your chosen output. If the goal is specifically NVENC, stop and verify the GPU path instead of silently changing to CPU encoding.
This is also why a copied command can fail on one server and work on another. The command may be valid, while the host does not provide the hardware or driver required by the selected encoder.
Check the GPU and driver on the actual VPS
Connect to the VPS using the same operating-system environment and user that will eventually run the long-lived FFmpeg process. If you test as an administrator but run the service as a restricted account, you may prove access that the production process does not have.
Start by listing the NVIDIA devices:
nvidia-smi -L
NVIDIA documents this as a way to list the GPUs available to the system. If it returns no device, an error, or a command-not-found message, you have not yet established that NVENC is available. Check the VPS documentation and the instance allocation, then verify that the driver is installed and that the device is passed through to the virtual machine or container.
A successful listing is useful but not sufficient. It shows that the NVIDIA utility can see a device; it does not by itself prove that your FFmpeg build can load the required libraries or that the eventual service account has permission to use the GPU. Run nvidia-smi as well and note whether it can query the device without an error.
If the VPS has more than one GPU, identify which device the process should use. NVIDIA’s documentation covers device selection for hardware-accelerated workflows, including -hwaccel_device where applicable. Do not add device-selection options just because they appear in another guide. First establish how the selected FFmpeg build exposes them and which device is available to your process.
A container adds another possible failure point. The host can have a GPU while the container lacks the device mapping or compatible driver libraries. Test from inside the container, not only on the host. Likewise, if the provider lets you choose between CPU and GPU instances, confirm that the running instance is the one you intended rather than relying on the order or name shown in a control panel.
Keep the output of these checks with your deployment notes. When a stream stops several weeks later, knowing which device and driver the original test used can save time.
Verify that FFmpeg exposes NVENC
Next inspect the FFmpeg binary that will run the stream:
ffmpeg -hide_banner -encoders | grep nvenc
You are looking for an encoder such as h264_nvenc. NVIDIA’s guide also lists HEVC and AV1 NVENC encoders, but the choice should follow the YouTube output profile and the compatibility of your source and audience. For the conservative example in this article, use H.264.
If no NVENC encoder appears, the binary does not expose the required encoder under that name. Installing a different package may be necessary, but do not assume that every distribution build has the same compile-time features. Check the binary’s version and package source, then inspect the encoder-specific help:
ffmpeg -hide_banner -h encoder=h264_nvenc
This matters because preset names, rate-control options and other details can vary between FFmpeg and NVIDIA driver combinations. An option copied from a current example may not be accepted by an older build, while a build can list an encoder and still fail when it tries to initialise the driver at runtime.
Run a small real encode before connecting the process to your public channel. Use a representative file rather than a tiny test clip with no audio or motion. For example:
ffmpeg -hide_banner -i /srv/media/loop.mp4 \
-t 30 -c:v h264_nvenc -f null -
The -t 30 value limits this test to thirty seconds. It is a test duration, not a performance claim or a YouTube requirement. If the command cannot initialise h264_nvenc, inspect the complete error for driver, permissions, library or unsupported-option clues. If it succeeds, repeat the test with the account and service environment that will run the continuous stream.
This encode test still does not prove that a broadcast will remain healthy overnight. It verifies an important dependency: the selected FFmpeg process can invoke the encoder on the selected VPS. The network path, input loop, audio mapping, output settings and YouTube ingest must still be tested.
Prepare the media and YouTube output settings
Before building a command, inspect the source file. The example below assumes one file contains a video stream and an audio stream. If the file has no audio, several audio tracks or an unusual audio codec, change the mapping and audio handling rather than copying the command unchanged.
A simple loop uses -stream_loop -1 before the input it applies to:
-stream_loop -1 -i /srv/media/loop.mp4
FFmpeg options apply to the next input or output, so placement matters. The -re option then paces file reading at the file’s native rate for a live-source workflow. Without suitable pacing, a file-based process can read ahead instead of behaving like a live feed.
YouTube’s current live encoder settings guidance documents RTMP and RTMPS ingest, H.264, H.265 and AV1 options, frame rates up to 60 fps, constant bitrate guidance, and a recommended two-second keyframe interval with a four-second maximum. YouTube recommends RTMPS, so use the encrypted destination supplied for your stream where available.
For a straightforward SDR H.264 profile, choose 30 fps, a two-second keyframe interval and a bitrate that the VPS network can sustain. YouTube’s current table lists the following H.264 figures:
| Output | YouTube-listed minimum | YouTube-listed recommended |
|---|---|---|
| 720p30 | 3 Mbps | 8 Mbps |
| 1080p30 | 5 Mbps | 14 Mbps |
| 1080p60 | 6 Mbps | 17 Mbps |
These are YouTube encoder-setting figures, not a guarantee that your VPS network or source can maintain them. The outgoing connection needs additional headroom for the configured stream and ordinary network variation. If the host cannot sustain the selected bitrate reliably, choose a smaller output or a different host rather than relying on brief successful tests.
The following command illustrates one 1080p30-style profile:
ffmpeg -re -stream_loop -1 -i /srv/media/loop.mp4 \
-map 0:v:0 -map 0:a:0? \
-c:v h264_nvenc -preset p4 -tune hq \
-r 30 -g 60 -keyint_min 60 -sc_threshold 0 \
-b:v 14M -maxrate 14M -bufsize 28M \
-pix_fmt yuv420p \
-c:a aac -b:a 128k -ar 44100 \
-f flv 'rtmps://YOUTUBE_INGEST_URL/YOUR_STREAM_KEY'
Here, -g 60 at 30 frames per second targets a two-second GOP. The video bitrate and maximum rate are set to the same target, with a buffer specified, but you should confirm the exact rate-control behaviour of the installed NVENC build using its encoder help. Do not describe this command as an exact CBR implementation unless you have checked the supported rate-control option and the resulting stream.
The ? in -map 0:a:0? makes the audio mapping optional. That prevents a missing audio stream from failing at the mapping stage, but YouTube still expects a usable output for the intended broadcast. If the input audio is suitable AAC, copying it may be possible; encoding to AAC, as shown, gives the command a more predictable output path. Test representative speech, music and silence, because audio problems can be less obvious than a video failure.
The preset and tuning choices are illustrative. NVENC options can vary by FFmpeg and driver version. Use the options accepted by your installed encoder, and remove an option that your build rejects rather than forcing a copied command through.
For more context on bitrate and keyframe choices, compare this FFmpeg bitrate and keyframe guide. If your source is a long playlist or has timing problems, the audio and video drift guide covers a separate class of issue.
Configure YouTube ingest and protect the key
In YouTube Studio, create or schedule the live stream and obtain the stream URL and stream key. YouTube describes the key as the information that tells the encoder where to send the feed and allows YouTube to accept it. The destination details shown by YouTube should take priority over a generic example copied from elsewhere.
Treat the stream key as a credential. Do not place it in a public repository, paste it into a screenshot, or leave it in a world-readable shell history or configuration file. The YouTube Help instructions for finding and managing stream keys explain the key’s role and describe resetting it if it is compromised.
A safer arrangement is to keep the key in a protected environment variable, a restricted configuration file or the secret facility provided by your operating system and deployment method. Make sure the FFmpeg service account can read it without making the file readable to unrelated users. Also check process listings and logs so the complete RTMPS URL is not recorded accidentally.
If the key is exposed, reset it in Live Control Room and update the running process. A stream that suddenly receives an unauthorised feed or stops accepting your encoder is a reason to inspect the key as well as the network and FFmpeg logs.
For a first test, use a private or unlisted broadcast. Keep the same media characteristics, audio and motion that you expect in the real channel. A static test image can conceal timing, bandwidth and encoder issues that appear when the actual file is played.
Test the encode and inspect stream health
Start with the short local NVENC test, then run the complete command against a private or unlisted YouTube stream. Watch both sides: the FFmpeg process and YouTube Live Control Room.
On the VPS, inspect FFmpeg’s console output and capture logs to a location you can review after the test. Look for encoder initialisation errors, repeated reconnects, input read failures, timestamp warnings and unexpected exits. Also observe CPU, memory, GPU and network use during representative parts of the file. A process can encode successfully while the host still lacks enough network headroom for a stable broadcast.
In YouTube Live Control Room, inspect stream-health messages and the preview. YouTube specifically advises testing before starting a live stream and recommends checking the audio and motion that resemble the real event. Let the file pass through changes in motion and sound rather than stopping immediately after the first preview appears.
The repeating input is not a complete reliability system. An FFmpeg process can stop after a network error, host reboot or damaged input. For a continuous deployment, run it under an operating-system service manager or another process supervisor, arrange a restart-on-failure policy, retain logs and alert on a lost process or unhealthy stream. The exact service configuration depends on your Linux distribution and the management method you choose, so validate restart behaviour on your actual VPS.
A restart policy also needs care. If the stream key is stored in a protected file, ensure the service can read it after a reboot. If the input file is mounted from another location, confirm it is available before FFmpeg starts. If repeated failures cause rapid restarts, use logs and an appropriate delay rather than hiding the underlying driver, input or network fault.
For a non-VPS alternative, a cloud workflow can remove the need to leave your own computer running. This guide to cloud services for turning a podcast playlist into a YouTube live stream explains the operational trade-off. StreamNeo removes the need to keep a local FFmpeg process and VPS running for this particular uploaded-video-to-YouTube workflow, while you still need to prepare the media and verify the resulting channel.
Troubleshoot missing hardware or encoder support
If nvidia-smi -L cannot see a device, investigate the VPS allocation, device exposure and driver installation before changing FFmpeg flags. A provider may offer GPU instances without every instance type exposing the same hardware path, and a container may need explicit device access. The correct answer can be to select a different host, not to add another option to the command.
If the GPU is visible but h264_nvenc is absent from ffmpeg -encoders, inspect the FFmpeg package and binary path. You may be calling a different binary from the one you tested, or the distribution build may not include the encoder. Confirm with command -v ffmpeg, ffmpeg -version and the encoder list used by the service.
If the encoder is listed but initialisation fails, check driver compatibility, device permissions and the libraries visible to the running process. Repeat the test as the service account. An interactive shell can have environment variables or permissions that are absent from a system service.
If video encodes but YouTube reports an ingest problem, compare the actual output with the destination settings: codec, resolution, frame rate, bitrate, audio, keyframe interval and protocol. Check for a malformed RTMPS URL or an outdated key. YouTube’s stream-health messages are more useful here than guessing from the FFmpeg command alone.
If the stream starts and then falls behind, check network capacity and host load. A file loop can be perfectly valid while the VPS cannot sustain the selected output continuously. Reduce the output requirements, choose a host with suitable capacity or use a workflow that does not depend on this VPS. Do not call the stream continuous until you have tested process restarts, reboots, input availability and YouTube recovery on the actual deployment.
If the source is unsuitable, convert or remux it before the live run. Verify that video and audio have stable timestamps, that the audio stream is present and that the selected output dimensions and frame rate match the profile you intend to send. For an example of a different FFmpeg continuous-stream workflow, see the Windows FFmpeg YouTube guide, while remembering that its operating environment is not the same as a VPS.
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 every GPU VPS support NVENC?
No. NVENC depends on the NVIDIA hardware, driver and device access exposed by the actual VPS runtime. Use nvidia-smi -L, inspect the driver and run an encode test on the selected instance before planning the broadcast.
Why does FFmpeg list h264_nvenc but still fail?
The encoder can be present in the FFmpeg build while runtime access to the GPU or driver is unavailable. Test with the same account and service environment that will run the stream, then check driver compatibility, permissions and visible libraries.
Is -stream_loop -1 enough for a 24/7 stream?
It repeats the selected input, but it does not restart FFmpeg after a host reboot, network error or input failure. Use a tested supervisor or service arrangement, retain logs and monitor YouTube stream health as well as the process.
What should I do if the stream key is exposed?
Reset it in YouTube Live Control Room and update the protected configuration used by FFmpeg. Do not publish the key in scripts, repositories, screenshots or unrestricted logs.