Hardware encoding with FFmpeg on a Contabo VPS is possible only if the instance exposes a compatible NVIDIA GPU. Installing CUDA or an NVENC-capable FFmpeg build on an ordinary shared-vCPU VPS does not add a GPU.
Start by identifying the exact instance and checking nvidia-smi. If there is no visible GPU, stop before changing FFmpeg: this is an instance-access question, not an encoder setting. If the GPU is present, verify the driver and FFmpeg build, then test a short representative file before relying on the setup for a long-running channel.
Check whether the instance exposes a GPU
Log in to the VPS and run:
nvidia-smi
On an instance with a working NVIDIA driver and visible device, the output should identify the GPU and show driver information. Contabo's GPU VPS documentation says its passed-through GPU can be seen with this command. If the command is missing, reports that it cannot communicate with the driver, or shows no device, do not infer that a package installation will create GPU access. First establish whether the chosen instance actually includes a GPU and whether its image and driver are functioning.
Check your Contabo control panel, order details, or support records for the exact product name. Do not rely on a memory of which plan you selected or on the fact that the VPS has many CPU cores. CPU allocation and GPU access are separate things. A machine can have ample CPU and memory while offering no NVIDIA device to the operating system.
If this is an ordinary VPS, the practical choices are to continue with CPU encoding, move the workload to a GPU-enabled instance, or use an operating approach that does not require you to run FFmpeg on that server. A cloud GPU elsewhere will not help unless your encoding process runs there and the resulting stream can be sent reliably to YouTube. For a 24/7 playlist, first map the file preparation, live broadcast, and restart requirements; the recordings-based Quran playlist guide covers the broader shape of a continuous YouTube channel.
Ordinary VPS versus Contabo GPU VPS
Contabo documents ordinary VPS families as shared-vCPU offerings. Its separate GPU VPS documentation describes a dedicated NVIDIA GPU attached through PCIe passthrough. That distinction matters: a normal VPS does not become GPU-enabled because you install a CUDA toolkit, update FFmpeg, or add a package that contains NVENC support.
As documented on 3 October 2026, Contabo's GPU VPS configuration includes one NVIDIA RTX 6000 PRO Blackwell Server Edition GPU with 96 GB of GPU memory, alongside 18 vCPUs, 96 GB RAM, and 900 GB NVMe. These are product specifications, not a promise about the speed of a particular FFmpeg job. The documented offer lists EU and US Central availability, Ubuntu 24.04 LTS as the operating system, no regional migration, and no upgrade or downgrade path. Availability and configuration can change, so revisit Contabo's GPU VPS documentation and its configurator before ordering.
Those constraints can be decisive. If your audience, other services, or data need to stay in a particular region, check the currently offered locations before committing; do not assume that a running GPU VPS can later be moved. If you need another operating system, or a flexible size path as demand changes, compare that requirement against what the current GPU product actually offers. For a general discussion of the ongoing costs and trade-offs involved in hosting a continuous YouTube music stream, see cloud server costs for a 24/7 stream. That comparison is not a substitute for checking today's Contabo terms.
The right decision depends on whether your goal needs local GPU encoding at all. A pre-rendered file can be streamed without re-encoding on every loop; a live composition or frequent format conversion may have different demands. Estimate the actual processing you need before selecting a server around an encoder feature.
Verify the passed-through GPU with nvidia-smi
On Contabo's documented GPU VPS, the first useful check is still nvidia-smi. It confirms that the guest operating system can see the NVIDIA device and communicate with the installed driver. It is a checkpoint, not proof that every codec or FFmpeg operation is supported.
Run it after first login and again after any driver or system-image change. Read the GPU name and driver version from the output. If it fails, keep the full error text and investigate the instance image, driver state, and device visibility before proceeding. Reinstalling FFmpeg cannot repair a GPU that the operating system cannot see.
A successful result narrows the problem, but does not guarantee the specific encoding path you want. NVENC capability depends on the GPU model and codec/profile support, while FFmpeg must also have been built with the relevant support. NVIDIA's Video Codec SDK documentation explains the FFmpeg/NVIDIA workflow and advises checking the available encoders and decoders in the installed build.
For a 24/7 stream, record the driver version and the exact FFmpeg binary used in your notes. If a package update changes behavior later, those details help distinguish a driver change from an FFmpeg build change. Avoid updating a working broadcast machine immediately before a long unattended run; test changes on a short job first.
Check the documented Ubuntu CUDA image
Contabo's GPU VPS documentation describes an Ubuntu 24.04 LTS CUDA image with the NVIDIA driver and CUDA toolkit preinstalled. This gives you a documented starting point on that product, rather than a reason to assume the same image or GPU access exists on ordinary VPS plans. The documentation also identifies Ubuntu 24.04 LTS as the GPU VPS operating system, so check the current product page if you need a different distribution.
After provisioning, inspect what is installed rather than relying only on the image label. Start with nvidia-smi, then check whether ffmpeg is present and which build it is. A toolkit being installed does not, by itself, establish that the installed FFmpeg binary has NVENC enabled. Conversely, a suitable precompiled FFmpeg may already be enough; a manual source build is not automatically necessary.
Keep the image as close to its documented baseline as practical while you validate the workload. Add only the packages your pipeline needs, and note the commands or package versions used. If a service script or scheduled job runs under another account, make sure that account can find the intended FFmpeg executable and read the media files. A successful interactive shell test can fail in a background process because it uses a different path, permissions, or environment.
Confirm FFmpeg and driver support
Check the encoders and hardware acceleration methods advertised by the binary:
ffmpeg -hide_banner -encoders | grep -i nvenc
ffmpeg -hide_banner -decoders | grep -i cuvid
ffmpeg -hide_banner -hwaccels
An h264_nvenc entry indicates that this FFmpeg build advertises that encoder. A decoder or hardware-acceleration listing indicates what the binary knows how to request. These lists do not prove that the driver can initialise the device at runtime, nor that the particular codec profile or bit depth you need is supported by the GPU. You need a real test as well.
The driver and FFmpeg build must be compatible. NVIDIA's FFmpeg guide gives version and build context; check its current requirements alongside the installed driver's version. Prefer a maintained precompiled FFmpeg that supports NVENC if it meets your needs. If the encoder is absent, investigate the binary before deciding to compile: you may be invoking a different executable than expected, or using a package built without the needed support.
A custom build is a fallback when an appropriate precompiled binary is not available. NVIDIA's guide describes using nv-codec-headers and configuring FFmpeg for NVIDIA support. Build instructions and compatibility requirements change, so follow the current documentation for the operating system, FFmpeg branch, driver, and SDK headers you are using rather than copying a command sequence written for another environment. CUDA libraries and headers do not grant device access on a host without a GPU.
Encoding and decoding are separate choices. You can use NVENC to encode output while decoding on the CPU. Hardware decode may help where the input format is supported and the rest of the pipeline can use the decoded frames efficiently. Arbitrary filters can require transfers between GPU memory and host memory, or compatible GPU-specific filters. More hardware flags do not automatically make a pipeline faster or entirely GPU-resident.
Validate hardware encoding on the instance
Use a short, representative input file and select the output encoder explicitly. For H.264, this is an illustrative test, not a guarantee that every build or file will work unchanged:
ffmpeg -i input.mp4 -c:v h264_nvenc -c:a copy output.mp4
Read the complete FFmpeg output. A successful test should finish without an encoder initialisation error and produce a file that plays in the way your channel requires. Check the codec and playback, and compare the resulting file size and elapsed time against your existing CPU-based workflow. Keep the same source and comparable output settings when comparing; otherwise the difference may reflect different quality or bitrate choices rather than hardware alone.
Use hevc_nvenc or av1_nvenc only when the GPU, FFmpeg build, and intended delivery format all support that codec. Do not assume a named encoder is usable just because another NVENC encoder appears in the list. Consult the GPU's codec capabilities and your viewer/device requirements. H.264 can be the more compatible delivery choice for a broad audience, while another codec may suit a controlled playback environment; validate against the actual devices you expect viewers to use.
If you also want to attempt hardware decode, an example pattern is:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 \
-c:v h264_nvenc -c:a copy output.mp4
The input options go before -i. This pattern depends on the input codec, driver, GPU and FFmpeg support, and on what happens to frames between decode and encode. If a filter cannot operate on GPU frames, the pipeline may need a copy back to host memory or a different filter path. Test each added stage separately so that a failure points to decoding, filtering, or encoding rather than an opaque combined command.
For source preparation rather than live encoding, a hardware test can be done before you build the broadcast loop. For an always-on channel, the operational problem may instead be keeping the same prepared file on air without leaving a personal workstation running. StreamNeo removes that specific machine-running burden by taking an uploaded video and keeping it on a YouTube live broadcast, but it is YouTube-only and does not provide a general FFmpeg shell for arbitrary workflows.
Test stream output and monitor behaviour
A successful transcode is not the same as a healthy YouTube broadcast. First confirm that the output file is complete and plays, then run the planned stream command against a private or otherwise appropriate test setup. Check YouTube's live control room for incoming video and audio, and verify that the stream remains active through a representative interval. YouTube's guidance on live encoder settings and troubleshooting is the place to confirm current ingest recommendations rather than relying on an old bitrate or resolution copied from a forum post.
Watch the FFmpeg process and GPU during the test. nvidia-smi can show whether the device is visible and whether work is active, while FFmpeg's logs reveal input, output, reconnect, and encoder errors. Monitoring should also include the process exit status and a way to alert you if the service stops. A command that works in a terminal is not yet a 24/7 service; restarting after a failure, preserving logs, and avoiding accidental duplicate broadcasts need their own plan.
For a local FFmpeg stream, check the stream key and scheduled broadcast pairing as well as the media command. A connected encoder can still send to the wrong event or fail to connect after a configuration change; this guide to checking the stream key against the scheduled stream addresses that separate part of the setup. If you are using YouTube's ingest status, follow its current official instructions and verify the channel's stream health rather than assuming that an FFmpeg exit code tells the whole story.
Do not assume NVENC will make the entire job faster. Frame transfers, filters, disk reads and writes, CPU-side audio handling, initialisation, and the characteristics of the input all affect end-to-end results. NVIDIA's FFmpeg pipeline guidance discusses the effects of GPU/host copies and pipeline design. Measure your own material and choose on the basis of stable output and manageable operation, not encoder branding.
| Check | What it tells you | What it does not prove |
|---|---|---|
nvidia-smi identifies a GPU |
The operating system can see the device and driver | That a particular codec or FFmpeg command will work |
ffmpeg -encoders lists NVENC |
The binary advertises an NVENC encoder | That the driver can initialise it at runtime |
| A short transcode completes | The tested input and settings worked in that test | That every file, filter, or long broadcast will behave the same way |
| YouTube receives the test stream | The tested stream reached the intended ingest | That monitoring and recovery will work unattended |
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 I enable NVENC on an ordinary Contabo VPS by installing CUDA?
No. CUDA packages and an FFmpeg build cannot create GPU access where the instance does not expose a compatible NVIDIA device. Contabo documents its GPU VPS separately from ordinary shared-vCPU VPS families, so verify your exact product first.
Why does FFmpeg say there is no CUDA-capable device?
The message can indicate that the process cannot access a supported GPU through the driver, or that the runtime environment is not using the expected device and libraries. Check the instance and nvidia-smi before changing FFmpeg. If nvidia-smi works, confirm the driver/build combination and test a supported encoder with a short file.
Does seeing h264_nvenc mean hardware encoding is working?
It means the FFmpeg binary advertises that encoder, not that it can successfully use it on this instance. The driver, GPU capability, and runtime must also align. Run a representative test and inspect both the FFmpeg logs and output file.
Is GPU encoding always faster for a 24/7 stream?
No. The result depends on the workload, including filters, frame transfers, storage, and CPU work. Compare the same material and suitable output settings on your own setup, then consider the operational cost and reliability of the full stream path.