Posso transcodificare video con FFmpeg su un VPS con vCPU dedicati senza GPU?

Quali encoder girano su CPU e cosa cambiano i preset?

Un preset è uno scambio tra velocità e dimensione: un preset più lento consuma più CPU per creare un file più piccolo alla stessa qualità. Ogni encoder software di FFmpeg ne ha uno. La qualità stessa si imposta separatamente, con CRF. Scegli prima la qualità, poi il preset più lento che la scadenza consente.

Come usa FFmpeg i vCPU di un VPS?

FFmpeg e i suoi encoder dimensionano i thread in base al numero di CPU che rilevano, che su un VPS è il numero di vCPU. L'opzione generica threads ha come default auto, e -filter_threads (scaling, overlay e altri filtri) ha come default il numero di CPU disponibili. x265 crea i propri pool di thread, uno per nodo NUMA, dimensionati in base al numero di CPU, e usa di default il wavefront parallel processing; la sua documentazione stima il costo di compressione del WPP sotto l'1% nella maggior parte dei test.

Quel default va bene per una codifica alla volta. Più codifiche in parallelo proverebbero ciascuna a usare tutti i vCPU e passerebbero il tempo a fare context switch invece di codificare. Dividi i thread a mano: su Fell 8, due job con -threads 4 ciascuno, oppure quattro job con -threads 2. La regola thread-versus-core è spiegata in un vCPU dedicato è un core o un thread.

Anche una singola codifica non scala all'infinito. Il threading di frame e slice ha limiti legati alla risoluzione, quindi un file 720p guadagna meno da 16 thread di un file 4K.

Cosa cambiano i core dedicati per una codifica lunga?

Una codifica è CPU al 100% per tutta la durata del file, il profilo di carico che i piani condivisi sono pensati per fermare. Secondo l'indagine di Cobaltfell del 2 novembre 2026, 29 dei 51 host che accettano cripto senza controllo d'identità non vendono alcun piano con CPU che definiscono dedicata. Due di loro mettono un limite per iscritto: i termini di Spartan Host vietano di usare più del 50% dei core assegnati per più di un'ora, e la fair-use policy di Advin Servers limita l'uso di CPU al 75%. Un batch di film infrange entrambi. Il caso generale è illustrato in qual è la differenza tra un vCPU condiviso e uno dedicato.

Su Cobaltfell: Il carico pieno è consentito per tutto il tempo che il tuo lavoro richiede: nessun credito CPU, nessuna finestra di burst e nessun throttling dopo qualche minuto al 100%. Un vCPU è un thread hardware del processore host. I tuoi sono assegnati uno a uno al tuo VPS e non vengono mai prestati a un altro cliente, e i due thread di un core fisico restano insieme, quindi ogni 2 vCPU formano un core intero che nessun vicino condivide. Senza un vicino che si prende i cicli, il valore speed= che FFmpeg stampa resta valido dal primo minuto di un batch all'ultimo, così la durata di una coda si può calcolare in anticipo.

Il video è grande, quindi disco e traffico contano quanto i core. Sorgente e output condividono l'NVMe del piano (Archiviazione NVMe su ogni piano): Fell 8 ha 320 GB NVMe e Fell 16 640 GB NVMe. Ogni VPS riceve un indirizzo IPv4 e un IPv6 /64 su una porta da 1 Gbit/s. Il traffico mensile del tuo piano conta solo i dati in uscita, e superarlo non comporta mai un addebito da solo.

Come cronometro una codifica su un VPS prima di impegnarmi?

Codifica un minuto della sorgente reale con ogni impostazione candidata e leggi il valore speed=: 1x è tempo reale, 2x è il doppio più veloce. -f null - scarta l'output, così il test misura l'encoder e non il disco. -benchmark aggiunge alla fine il tempo di CPU usato.

# 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 -

Quale piano si adatta a quale lavoro di transcodifica?

È il lavoro da completare per ora a decidere il piano, non un singolo file. La tabella dà punti di partenza, non tempi: I nostri risultati YABS e Geekbench 6, insieme allo steal time che misuriamo, saranno pubblicati con la loro data quando sarà consegnata la nostra prima macchina di test. Fino ad allora non citiamo nessun dato di prestazioni nostro. I prezzi di ogni piano sono elencati in quanto costa un VPS con core dedicati.

Gli altri host che vendono core dedicati per codifiche lunghe sono classificati in qual è il miglior provider di VPS con CPU dedicate nel 2026.

Quando è la GPU lo strumento migliore per il video?

La GPU è lo strumento migliore per molti stream live simultanei in tempo reale, o quando la velocità di codifica conta più del file più piccolo possibile. Gli encoder hardware come NVENC, Quick Sync e VAAPI girano su una scheda grafica o su una GPU integrata, e FFmpeg li usa solo quando quell'hardware è presente. Un VPS Cobaltfell non ne ha, quindi il suo punto di forza è la codifica software: più lenta per stream, con l'intero set di preset e l'efficienza di compressione degli encoder software.

Per librerie on-demand, batch notturni e archivi, la codifica su CPU con core dedicati è la configurazione più semplice. Per una piattaforma live con decine di canali simultanei, l'hardware GPU è l'acquisto giusto. La stessa domanda CPU-o-GPU per i modelli linguistici trova risposta in posso eseguire Ollama su un VPS senza GPU.