Puis-je transcoder de la vidéo avec FFmpeg sur un VPS à vCPU dédié sans GPU ?

Quels encodeurs tournent sur un CPU, et que changent les presets ?

Un preset est un compromis vitesse-taille : un preset plus lent consomme plus de CPU pour produire un fichier plus petit à qualité égale. Chaque encodeur logiciel de FFmpeg en a un. La qualité elle-même se règle séparément, avec CRF. Choisissez d'abord la qualité, puis le preset le plus lent que le délai autorise.

Comment FFmpeg utilise-t-il les vCPU d'un VPS ?

FFmpeg et ses encodeurs dimensionnent leurs threads d'après le nombre de CPU qu'ils détectent, soit sur un VPS le nombre de vCPU. L'option générique threads vaut auto par défaut, et -filter_threads (mise à l'échelle, incrustations et autres filtres) prend par défaut le nombre de CPU disponibles. x265 construit ses propres pools de threads, un par nœud NUMA, dimensionnés d'après le nombre de CPU, et applique le wavefront parallel processing par défaut ; sa documentation situe le coût de compression du WPP sous 1% dans la plupart des tests.

Cette valeur par défaut convient à un encodage à la fois. Plusieurs encodages en parallèle chercheraient chacun à utiliser tous les vCPU et passeraient leur temps à changer de tâche au lieu d'encoder. Répartissez les threads à la main : sur Fell 8, deux tâches avec -threads 4 chacune, ou quatre tâches avec -threads 2. La règle thread contre cœur est expliquée dans un vCPU dédié est-il un cœur ou un thread.

Un seul encodage ne monte pas non plus indéfiniment en charge. Le threading par images et par tranches a des limites liées à la résolution, si bien qu'un fichier 720p gagne moins à passer à 16 threads qu'un fichier 4K.

Que changent des cœurs dédiés pour un long encodage ?

Un encodage, c'est du CPU à 100% tant que dure le fichier, le profil de charge contre lequel les plans mutualisés sont conçus pour vous arrêter. Selon l'enquête de Cobaltfell du 2 novembre 2026, 29 des 51 hébergeurs qui acceptent la crypto sans vérification d'identité ne vendent aucun plan dont ils qualifient le CPU de dédié. Deux d'entre eux fixent une limite par écrit : les conditions de Spartan Host interdisent d'utiliser plus de 50% des cœurs alloués pendant plus d'une heure, et la politique d'usage raisonnable d'Advin Servers plafonne l'utilisation du CPU à 75%. Un lot de films déclenche les deux. Le cas général est exposé dans quelle est la différence entre un vCPU mutualisé et un vCPU dédié.

Chez Cobaltfell : La pleine charge est autorisée aussi longtemps que votre travail l'exige : aucun crédit CPU, aucune fenêtre de burst et aucun throttling après quelques minutes à 100 %. Un vCPU correspond à un thread matériel du processeur hôte. Les vôtres sont épinglés un à un à votre VPS et ne sont jamais prêtés à un autre client, et les deux threads d'un cœur physique restent ensemble : ainsi, chaque 2 vCPU forment un cœur entier que nul voisin ne partage. Sans voisin qui prend des cycles, le chiffre speed= affiché par FFmpeg tient de la première minute d'un lot à la dernière, si bien que la durée d'une file d'attente peut être calculée à l'avance.

La vidéo est volumineuse, donc le disque et le trafic comptent autant que les cœurs. Source et sortie partagent le NVMe du plan (Stockage NVMe sur toutes les offres) : Fell 8 en offre 320 GB NVMe et Fell 16 640 GB NVMe. Chaque VPS reçoit une adresse IPv4 et un IPv6 /64 sur un port à 1 Gbit/s. Le trafic mensuel de votre offre compte uniquement les données sortantes, et le dépassement n'entraîne à lui seul aucun frais.

Comment chronométrer un encodage sur un VPS avant de s'engager ?

Encodez une minute de la vraie source avec chaque réglage candidat et lisez la valeur speed= : 1x correspond au temps réel, 2x va deux fois plus vite. -f null - jette la sortie, si bien que le test mesure l'encodeur et non le disque. -benchmark ajoute le temps CPU utilisé à la fin.

# which software encoders this ffmpeg build has
ffmpeg -hide_banner -encoders | grep -E 'libx264|libx265|libsvtav1'

# 60 seconds of your own file, video only, output discarded
ffmpeg -hide_banner -benchmark -t 60 -i input.mp4 -an -c:v libx264 -preset medium -crf 23 -f null -
ffmpeg -hide_banner -benchmark -t 60 -i input.mp4 -an -c:v libx265 -preset medium -crf 28 -f null -
ffmpeg -hide_banner -benchmark -t 60 -i input.mp4 -an -c:v libsvtav1 -preset 8 -crf 35 -f null -

# the same H.264 test held to 4 threads, to plan parallel jobs
ffmpeg -hide_banner -benchmark -t 60 -i input.mp4 -an -c:v libx264 -preset medium -crf 23 -threads 4 -f null -

Quel plan convient à quel travail de transcodage ?

C'est le travail à terminer par heure qui décide du plan, pas un seul fichier. Le tableau donne des points de départ, pas des chronométrages : Nos propres résultats YABS et Geekbench 6, ainsi que le steal time que nous mesurons, seront publiés avec leur date dès la livraison de notre première machine de test. D'ici là, nous ne citons aucune performance de notre cru. Le prix de chaque plan est indiqué sous combien coûte un VPS à cœurs dédiés.

Les autres hébergeurs qui vendent des cœurs dédiés pour de longs encodages sont classés dans quel est le meilleur fournisseur de VPS à CPU dédié en 2026.

Quand un GPU est-il l'outil le plus adapté pour la vidéo ?

Le GPU est l'outil le plus adapté pour de nombreux flux live simultanés en temps réel, ou lorsque le débit d'encodage compte plus que le plus petit fichier possible. Les encodeurs matériels comme NVENC, Quick Sync et VAAPI tournent sur une carte graphique ou un GPU intégré, et FFmpeg ne les utilise que si ce matériel est présent. Un VPS Cobaltfell n'en a pas : sa force, c'est l'encodage logiciel, plus lent par flux, avec l'ensemble complet des presets et l'efficacité de compression des encodeurs logiciels.

Pour des bibliothèques à la demande, des lots de nuit et des archives, l'encodage CPU sur des cœurs dédiés est la configuration la plus simple. Pour une plateforme live avec des dizaines de chaînes simultanées, le matériel GPU est le bon achat. La même question CPU ou GPU pour les modèles de langage est traitée dans puis-je exécuter Ollama sur un VPS sans GPU.