คำตอบแบบสั้น
VPS สามารถ transcode วิดีโอด้วย FFmpeg โดยไม่มี GPU ได้ไหม?
ได้ FFmpeg transcode วิดีโอบน VPS ที่ไม่มี GPU ผ่าน CPU encoder ของมัน คือ libx264, libx265 และ SVT-AV1 สำหรับ H.264, HEVC และ AV1 VPS ของ Cobaltfell ไม่มี GPU และ FFmpeg เลือกจำนวน thread จาก vCPU เอง preset กำหนดความเร็ว: header ของ x264 เองระบุว่า ultrafast เร็วกว่า placebo 100 เท่า (ตรวจสอบเมื่อ 2 พฤศจิกายน 2026)
encoder ใดทำงานบน CPU และ preset เปลี่ยนอะไร?
preset คือการแลกความเร็วกับขนาด: preset ที่ช้ากว่าใช้ CPU มากขึ้นเพื่อให้ได้ไฟล์เล็กลงที่คุณภาพเท่ากัน software encoder ทุกตัวของ FFmpeg มี preset ตัวคุณภาพนั้นตั้งแยกด้วย CRF เลือกคุณภาพก่อน แล้วจึงเลือก preset ที่ช้าที่สุดเท่าที่กำหนดเวลายอมให้
| Codec | FFmpeg encoder | Preset จากเร็วไปช้า | สิ่งที่โปรเจกต์ระบุ |
|---|---|---|---|
| H.264 | libx264 | ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo | ความเร็วต่างกันมากระหว่าง preset; ultrafast เร็วกว่า placebo ถึง 100 เท่า |
| HEVC (H.265) | libx265 | สิบชื่อเดียวกัน; medium เป็นค่าเริ่มต้น | preset ที่เร็วกว่าใช้ทางลัดโดยแลกกับคุณภาพและประสิทธิภาพการบีบอัด |
| AV1 | libsvtav1 | มีหมายเลข 13 (เร็วที่สุด) ลงไปถึง 0 (ช้าที่สุด); ค่าเริ่มต้นของ SVT-AV1 เองคือ 8 | preset ที่สูงกว่าเร็วขึ้นแต่คุณภาพต่ำลง |
H.264 ที่ preset medium เป็นตัวเลือกที่ปลอดภัยสำหรับการเล่นทั่วไป HEVC และ AV1 ให้ไฟล์เล็กลงที่คุณภาพเท่ากันและใช้ CPU ต่อเฟรมมากกว่า จึงเหมาะกับแผนที่ใหญ่กว่า
FFmpeg ใช้ vCPU ของ VPS อย่างไร?
FFmpeg และ encoder ของมันกำหนดจำนวน thread จากจำนวน CPU ที่ตรวจพบ ซึ่งบน VPS คือจำนวน vCPU ออปชันทั่วไป threads มีค่าเริ่มต้นเป็น auto และ -filter_threads (scaling, overlay และฟิลเตอร์อื่น ๆ) มีค่าเริ่มต้นเป็นจำนวน CPU ที่ใช้ได้ x265 สร้าง thread pool ของตัวเอง หนึ่งต่อ NUMA node โดยกำหนดขนาดจากจำนวน CPU และรัน wavefront parallel processing เป็นค่าเริ่มต้น; เอกสารของมันระบุว่าต้นทุนการบีบอัดของ WPP ต่ำกว่า 1% ในการทดสอบส่วนใหญ่
ค่าเริ่มต้นนั้นเหมาะกับการ encode ครั้งละหนึ่งงาน การ encode หลายงานพร้อมกันจะพยายามใช้ทุก vCPU และใช้เวลาไปกับการสลับแทนการ encode แบ่ง thread เอง: บน Fell 8 สองงานด้วย -threads 4 ต่อกัน หรือสี่งานด้วย -threads 2 ต่อกัน กฎเรื่อง thread เทียบกับ core อธิบายไว้ใน vCPU แบบเฉพาะคือ core หรือ thread
การ encode ครั้งเดียวก็ไม่ได้สเกลไปเรื่อย ๆ frame และ slice threading มีขีดจำกัดตามความละเอียด ดังนั้นไฟล์ 720p ได้ประโยชน์จาก 16 thread น้อยกว่าไฟล์ 4K
core แบบเฉพาะเปลี่ยนอะไรสำหรับการ encode ยาวนาน?
การ encode คือ CPU ที่ 100% ตลอดเวลาที่ไฟล์ใช้ ซึ่งเป็นโปรไฟล์โหลดที่แผนแบบ shared ถูกเขียนขึ้นมาเพื่อหยุด จากการสำรวจของ Cobaltfell เมื่อ 2 พฤศจิกายน 2026 ใน 51 เจ้าที่รับคริปโตโดยไม่ตรวจ ID นั้น 29 เจ้าไม่มีแผนใดที่เรียก CPU ว่าเฉพาะ สองเจ้ากำหนดขีดจำกัดเป็นลายลักษณ์อักษร: ข้อกำหนดของ Spartan Host ห้ามใช้เกิน 50% ของ core ที่จัดสรรไว้นานกว่าหนึ่งชั่วโมง และนโยบาย fair-use ของ Advin Servers จำกัดการใช้ CPU ที่ 75% การ encode ภาพยนตร์เป็นชุดชนทั้งสองข้อ กรณีทั่วไปอธิบายไว้ใน vCPU แบบ shared กับแบบเฉพาะต่างกันอย่างไร
ที่ Cobaltfell: ใช้โหลดเต็มที่ได้ตลอดตราบเท่าที่งานของคุณต้องการ: ไม่มี CPU credit ไม่มีช่วง burst และไม่มีการ throttling หลังจากใช้งานที่ 100% ไปสักพัก vCPU หนึ่งตัวคือหนึ่ง hardware thread ของโปรเซสเซอร์โฮสต์ vCPU ของคุณถูก pin แบบหนึ่งต่อหนึ่งเข้ากับ VPS ของคุณและไม่ถูกให้เช่าต่อให้ลูกค้ารายอื่น และสอง thread ของ physical core หนึ่งตัวจะอยู่ด้วยกันเสมอ ดังนั้นทุก 2 vCPU จึงรวมเป็นหนึ่ง whole core ที่ไม่มีเพื่อนบ้านมาแชร์ เมื่อไม่มีเพื่อนบ้านแย่งรอบสัญญาณ ตัวเลข speed= ที่ FFmpeg พิมพ์ออกมาจึงคงที่ตั้งแต่่นาทีแรกของชุดจนถึงนาทีสุดท้าย ทำให้คำนวณระยะเวลาของคิวล่วงหน้าได้
วิดีโอมีขนาดใหญ่ ดังนั้น disk และ traffic จึงสำคัญพอ ๆ กับ core ต้นทางและผลลัพธ์ใช้ NVMe ของแผนร่วมกัน (ที่เก็บข้อมูล NVMe ในทุกแพ็กเกจ): Fell 8 จุ NVMe 320 GB และ Fell 16 จุ NVMe 640 GB VPS แต่ละเครื่องได้รับ IPv4 หนึ่ง address และ IPv6 /64 บนพอร์ต 1 Gbit/s ปริมาณทราฟฟิกรายเดือนของแพ็กเกจของคุณนับเฉพาะข้อมูลขาออก และการใช้งานเกินไม่ทำให้เกิดค่าใช้จ่ายเพิ่มโดยตัวมันเอง
ฉันจะจับเวลาการ encode บน VPS ก่อนตัดสินใจได้อย่างไร?
encode หนึ่งนาทีของต้นฉบับจริงด้วยแต่ละการตั้งค่าที่เป็นตัวเลือก แล้วอ่านค่า speed=: 1x คือเวลาจริง 2x คือเร็วเป็นสองเท่า -f null - ทิ้งผลลัพธ์ไป การทดสอบจึงวัด encoder ไม่ใช่วัด disk -benchmark เพิ่มเวลาการใช้ CPU ที่ใช้ตอนท้าย
# 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 -แผนไหนเหมาะกับงาน transcode แบบไหน?
งานที่ต้องทำให้เสร็จต่อชั่วโมงเป็นตัวกำหนดแผน ไม่ใช่ไฟล์เดียว ตารางนี้ให้จุดเริ่มต้น ไม่ใช่เวลาที่แน่นอน: ผล YABS และ Geekbench 6 ของเราเอง พร้อมด้วย steal time ที่เราวัดได้ จะถูกเผยแพร่พร้อมวันที่เมื่อเครื่องทดสอบเครื่องแรกของเราส่งมอบแล้ว จนถึงตอนนั้นเราจะไม่กล่าวอ้างตัวเลขประสิทธิภาพใดๆ ของเราเอง ราคาของแต่ละแผนระบุไว้ใต้ VPS แบบ dedicated-core ราคาเท่าไร
เจ้าอื่นที่ขาย core แบบเฉพาะสำหรับการ encode ยาวนานถูกจัดอันดับใน ผู้ให้บริการ dedicated CPU VPS ที่ดีที่สุดในปี 2026 คือใคร
| แพ็กเกจ | vCPU | NVMe | งาน transcode ทั่วไป |
|---|---|---|---|
| Fell 2 | 2 | NVMe 80 GB | การแปลง H.264 เป็นครั้งคราว, thumbnail, งานเสียง และ remux ด้วย -c copy ซึ่งแทบไม่แตะ CPU |
| Fell 4 | 4 | NVMe 160 GB | คิวงาน H.264 ขนาดเล็ก หรือการเข้ารหัส HEVC หนึ่งงานที่พรีเซ็ตแบบเร็ว |
| Fell 8 | 8 | NVMe 320 GB | คิวแบตช์ที่ทำงานสม่ำเสมอ งาน H.264 ขนานกันสองถึงสี่งาน หรือ HEVC และ AV1 ที่พรีเซ็ตระดับกลาง |
| Fell 16 | 16 | NVMe 640 GB | พรีเซ็ตแบบช้าสำหรับไฟล์ระดับ archival, AV1 ในระดับสเกล หรือแหล่งวิดีโอ 4K หลายแหล่งพร้อมกัน |
เมื่อไรที่ GPU เป็นเครื่องมือที่ดีกว่าสำหรับวิดีโอ?
GPU เป็นเครื่องมือที่ดีกว่าสำหรับสตรีมสดหลายช่องพร้อมกันแบบเรียลไทม์ หรือเมื่อปริมาณการเข้ารหัสสำคัญกว่าไฟล์ที่เล็กที่สุดเท่าที่จะเป็นไปได้ ตัวเข้ารหัสฮาร์ดแวร์อย่าง NVENC, Quick Sync และ VAAPI ทำงานบนการ์ดจอหรือ GPU แบบรวม และ FFmpeg จะใช้มันเฉพาะเมื่อมีฮาร์ดแวร์นั้นอยู่ VPS ของ Cobaltfell ไม่มีฮาร์ดแวร์ดังกล่าว จุดแข็งของมันจึงเป็นการเข้ารหัสด้วยซอฟต์แวร์: ช้ากว่าต่อสตรีมหนึ่งช่อง แต่ได้พรีเซ็ตครบทั้งชุดและประสิทธิภาพการบีบอัดของตัวเข้ารหัสซอฟต์แวร์
สำหรับไลบรารีที่ใช้งานตามต้องการ แบตช์ข้ามคืน และไฟล์ archival การเข้ารหัสด้วย CPU บนคอร์เฉพาะคือการตั้งค่าที่ง่ายกว่า สำหรับแพลตฟอร์มไลฟ์ที่มีหลายสิบช่องพร้อมกัน ฮาร์ดแวร์ GPU คือสิ่งที่ควรซื้อ คำถามเรื่อง CPU หรือ GPU แบบเดียวกันสำหรับโมเดลภาษา มีคำตอบอยู่ใน can I run Ollama on a VPS without a GPU
ผู้คนถามคำถามอื่นอะไรอีกเกี่ยวกับ FFmpeg บน VPS?
VPS รันเซิร์ฟเวอร์ไลฟ์สตรีมมิ่งพร้อมการ transcoding ได้ไหม?
สำหรับสตรีมไม่กี่ช่อง ทำได้ รันการทดสอบหนึ่งครั้งแบบเดียวกับข้างต้นที่ความละเอียดเป้าหมาย และเก็บไว้เฉพาะการตั้งค่าที่ speed= ยังสูงกว่า 1x อย่างมาก: การเข้ารหัสที่ 1x เดียวไม่เหลือระยะเผื่อสำหรับฉากที่งานหนัก
คิวการเข้ารหัสรันที่โหลดเต็มได้หลายวันไหม?
ที่ Cobaltfell ได้ ใช้โหลดเต็มที่ได้ตลอดตราบเท่าที่งานของคุณต้องการ: ไม่มี CPU credit ไม่มีช่วง burst และไม่มีการ throttling หลังจากใช้งานที่ 100% ไปสักพัก การใช้งานที่กิน CPU หนักเพียงหนึ่งเดียวที่ไม่รวมอยู่: ไม่อนุญาตให้ขุด cryptocurrency ใดๆ ในทุกแพ็กเกจและด้วยซอฟต์แวร์ใดๆ งาน CPU หนักของคุณเอง เช่น การ build, การ encode, การ inference หรือฐานข้อมูล สามารถทำงานที่โหลดเต็มได้ และโหนดที่ทำหน้าที่เพียง validate blockchain ไม่ถือเป็นการขุด
การอัปโหลดไฟล์ต้นฉบับขนาดใหญ่ถูกนับเป็นทราฟฟิกไหม?
ที่ Cobaltfell ไม่นับ VPS แต่ละเครื่องได้รับ IPv4 หนึ่ง address และ IPv6 /64 บนพอร์ต 1 Gbit/s ปริมาณทราฟฟิกรายเดือนของแพ็กเกจของคุณนับเฉพาะข้อมูลขาออก และการใช้งานเกินไม่ทำให้เกิดค่าใช้จ่ายเพิ่มโดยตัวมันเอง ไฟล์ขาเข้าไม่มีค่าใช้จ่าย นับเฉพาะสิ่งที่ VPS ส่งออกเท่านั้น
แพ็กเกจ ffmpeg ของดิสทริบิวชันมี x265 และ SVT-AV1 รวมอยู่ไหม?
ffmpeg -hide_banner -encoders แสดงรายการสิ่งที่บิลด์รองรับอย่างชัดเจน อิมเมจที่ให้บริการคือ Debian 13, Debian 12, Ubuntu 24.04 LTS, AlmaLinux 10, Rocky Linux 10; เมื่อไม่มีตัวเข้ารหัส จะได้จาก FFmpeg แบบ static build หรือ backports ของดิสทริบิวชัน
Cobaltfell จะเผยแพร่ความเร็วการเข้ารหัสต่อแพ็กเกจไหม?
ผล YABS และ Geekbench 6 ของเราเอง พร้อมด้วย steal time ที่เราวัดได้ จะถูกเผยแพร่พร้อมวันที่เมื่อเครื่องทดสอบเครื่องแรกของเราส่งมอบแล้ว จนถึงตอนนั้นเราจะไม่กล่าวอ้างตัวเลขประสิทธิภาพใดๆ ของเราเอง ความเร็วการเข้ารหัสขึ้นอยู่กับแหล่งวิดีโอ โคเดก และพรีเซ็ตมากขนาดนั้น การทดสอบหนึ่งนาทีบนเนื้อหาของคุณเองจึงยังเป็นแนวทางที่ดีกว่า
แหล่งข้อมูล (8)
- เอกสารโคเดกของ FFmpeg (threads, libx264, libx265, libsvtav1) — FFmpeg (checked 2026-11-02)
- เอกสาร ffmpeg (-filter_threads) — FFmpeg (checked 2026-11-02)
- x264.h: ชื่อพรีเซ็ตและบันทึกความเร็ว (mirror ของที่เก็บ VideoLAN x264) — VideoLAN x264 (checked 2026-11-02)
- พรีเซ็ต x265 — x265 project (checked 2026-11-02)
- x265 threading — x265 project (checked 2026-11-02)
- พารามิเตอร์ SVT-AV1 — Alliance for Open Media (checked 2026-11-02)
- ข้อกำหนดการให้บริการของ Spartan Host spartanhost.org/tos — Spartan Host (checked 2026-11-02)
- นโยบายการใช้งานอย่างเป็นธรรมของ Advin Servers docs.advinservers.com/policies/fair-use — Advin Servers (checked 2026-11-02)