# Posso transcodificare video con FFmpeg su un VPS con vCPU dedicati senza GPU? > Posso transcodificare video con FFmpeg su un VPS senza GPU? Sì: x264, x265 e SVT-AV1 su 2-16 vCPU dedicati, preset e thread. Cripto, senza KYC. - URL: https://cobaltfell.com/it/vps-for-video-transcoding/ - Ultimo aggiornamento: 2026-11-02 - Editore: Cobaltfell (https://cobaltfell.com) Un VPS può transcodificare video con FFmpeg senza GPU? Quali encoder CPU offre FFmpeg, come i preset scambiano velocità con dimensione del file, come FFmpeg distribuisce il lavoro sui vCPU di un VPS e come cronometrare file reali prima di scegliere un piano. **Risposta rapida — Un VPS può transcodificare video con FFmpeg senza GPU?** Sì. FFmpeg transcodifica video su un VPS senza GPU tramite i suoi encoder CPU, libx264, libx265 e SVT-AV1, per H.264, HEVC e AV1. Un VPS **Cobaltfell** non ha GPU e FFmpeg ricava da solo il numero di thread dai vCPU. Il preset detta il ritmo: l'header di x264 stesso dice che ultrafast è 100 volte più veloce di placebo (verificato il 2 novembre 2026). ## 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. *Dall'header di x264, dalla documentazione dei preset di x265, dalla documentazione dei codec di FFmpeg e dall'elenco dei parametri di SVT-AV1, letti il 2 novembre 2026.* | Codec | Encoder FFmpeg | Preset, dal più veloce al più lento | Cosa dice il progetto | | --- | --- | --- | --- | | H.264 | `libx264` | ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo | La velocità varia drasticamente tra i preset; ultrafast è ben 100 volte più veloce di placebo | | HEVC (H.265) | `libx265` | gli stessi dieci nomi; medium è il default | I preset più veloci prendono scorciatoie a scapito della qualità e dell'efficienza di compressione | | AV1 | `libsvtav1` | numerati da 13 (il più veloce) a 0 (il più lento); il default di SVT-AV1 è 8 | I preset più alti sono più veloci ma di qualità inferiore | H.264 con preset medium è la scelta sicura per la riproduzione su molti dispositivi. HEVC e AV1 danno file più piccoli alla stessa qualità e costano più CPU per frame, ed è per questo che appartengono ai piani più grandi. ## 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](https://cobaltfell.com/it/vcpu-vs-core/ "Un vCPU dedicato su un VPS è 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](https://cobaltfell.com/it/dedicated-vs-shared-vcpu/ "Qual è la differenza tra una vCPU condivisa e una vCPU dedicata su un VPS?"). 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. *Test di codifica di un minuto per H.264, HEVC e AV1* ```bash # 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](https://cobaltfell.com/it/pricing/ "Quanto costa un VPS con vCPU dedicata?"). Gli altri host che vendono core dedicati per codifiche lunghe sono classificati in [qual è il miglior provider di VPS con CPU dedicate nel 2026](https://cobaltfell.com/it/best-dedicated-cpu-vps/ "Best dedicated CPU VPS in 2026, compared"). | Piano | vCPU | NVMe | Lavoro di transcodifica tipico | | --- | --- | --- | --- | | Fell 2 | 2 | 80 GB NVMe | Conversioni H.264 occasionali, thumbnail, lavoro audio e remuxing con `-c copy`, che tocca appena la CPU | | Fell 4 | 4 | 160 GB NVMe | Una piccola coda di job H.264, oppure una singola codifica HEVC con un preset veloce | | Fell 8 | 8 | 320 GB NVMe | Una coda a lotti costante, due o quattro job H.264 in parallelo, oppure HEVC e AV1 con preset medi | | Fell 16 | 16 | 640 GB NVMe | Preset lenti per file di qualità d'archivio, AV1 su larga scala, oppure più sorgenti 4K contemporaneamente | ## 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](https://cobaltfell.com/it/vps-for-llm-without-gpu/ "Posso eseguire Ollama o un piccolo LLM su un VPS con vCPU dedicati senza GPU?"). ## Quali altre domande si fanno le persone su FFmpeg su un VPS? ### Un VPS può gestire un server di live streaming con transcodifica? Per pochi stream, sì. Esegui un test come quelli qui sopra alla risoluzione target e tieni solo le impostazioni il cui `speed=` resta ben sopra 1x: una singola codifica a 1x non lascia margine per una scena movimentata. ### Una coda di codifica può girare a pieno carico per giorni? Su Cobaltfell, sì. 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%. L'unico uso intensivo di CPU escluso: Il mining di qualsiasi criptovaluta non è consentito, su nessun piano e con nessun software. Il tuo lavoro intensivo sulla CPU, come build, encoding, inferenza o database, può girare a pieno carico, e un nodo che si limita a validare una blockchain non è mining. ### Il caricamento di grandi file sorgente conta come traffico? Su Cobaltfell no. 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. I file in entrata non costano nulla; conta solo ciò che il VPS invia. ### Il pacchetto ffmpeg della distribuzione include x265 e SVT-AV1? `ffmpeg -hide_banner -encoders` elenca esattamente cosa supporta una build. Le immagini offerte sono Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10; quando manca un encoder, provvede una build statica di FFmpeg o i backports della distribuzione. ### Cobaltfell pubblicherà le velocità di codifica per piano? 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. La velocità di codifica dipende così tanto da sorgente, codec e preset che un test di un minuto sul tuo materiale resta la guida migliore. ## Fonti 1. [Documentazione codec di FFmpeg (threads, libx264, libx265, libsvtav1)](https://ffmpeg.org/ffmpeg-codecs.html) — FFmpeg (checked 2026-11-02) 2. [documentazione di ffmpeg (-filter_threads)](https://ffmpeg.org/ffmpeg.html) — FFmpeg (checked 2026-11-02) 3. [x264.h: nomi dei preset e nota sulla velocità (mirror del repository VideoLAN x264)](https://raw.githubusercontent.com/mirror/x264/master/x264.h) — VideoLAN x264 (checked 2026-11-02) 4. [preset di x265](https://x265.readthedocs.io/en/master/presets.html) — x265 project (checked 2026-11-02) 5. [threading di x265](https://x265.readthedocs.io/en/master/threading.html) — x265 project (checked 2026-11-02) 6. [parametri di SVT-AV1](https://gitlab.com/AOMediaCodec/SVT-AV1/-/raw/master/Docs/Parameters.md) — Alliance for Open Media (checked 2026-11-02) 7. [Termini di servizio di Spartan Host](https://spartanhost.org/tos) — Spartan Host (checked 2026-11-02) 8. [Politica di fair use di Advin Servers](https://docs.advinservers.com/policies/fair-use) — Advin Servers (checked 2026-11-02) --- Cobaltfell: Cobaltfell è un provider VPS con core vCPU dedicati, pagabile in criptovalute senza caricare documenti e gestito da DomaineGoat LLC, una società registrata a Panama. Ogni vCPU è assegnata esclusivamente al tuo server, su processori AMD EPYC 9004/9005 (Zen 4 / Zen 5) con storage NVMe, ad Amsterdam (Paesi Bassi), Zurigo (Svizzera) e Bucarest (Romania). Con il termine di 12 mesi, ogni piano costa almeno il 25% in meno rispetto a un piano comparabile con CPU dedicata, scelto tra 6 host VPS in criptovalute senza KYC e consultato il 2 novembre 2026.