搭建影片點播與短影片平台後端：儲存伺服器、FFmpeg HLS 轉碼、MinIO 與 CDN

搭建影片點播（VOD）或短影片平台後端需要四樣東西：存放原片和轉碼檔案的儲存型獨立伺服器、輸出 HLS 多位元速率階梯的 ffmpeg 轉碼流水線、MinIO 這類相容 S3 的物件儲存，以及承擔大部分頻寬的 CDN。IMIDC 在香港（CN2 GIA 直連大陸）、東京、新加坡、洛杉磯等亞太節點提供這些基礎設施：香港獨立伺服器每月 $139 起，洛杉磯獨立伺服器每月 $499 起，配套 10Gbps 上行、DDoS 防護和 IMIDC CDN。

從上傳到播放的點播流水線

所有影片平台都遵循同一條流水線：上傳、儲存原片、轉碼、儲存各檔位元速率、經 CDN 分發。

1. 上傳：客戶端用預簽名 URL 直接上傳到物件儲存，API 伺服器無需中轉大檔案。
2. 佇列：上傳完成事件把任務寫入佇列（Redis、RabbitMQ 或資料庫表）。
3. 轉碼：轉碼伺服器執行 ffmpeg，生成 HLS 位元速率階梯、封面圖和短預覽。
4. 儲存：轉碼結果放進公開只讀的 HLS 儲存桶，原片放入冷儲存。
5. 分發：播放器從 CDN 載入 master.m3u8，CDN 缺失的切片再回源到儲存伺服器。

後設資料（標題、作者、播放量、稽核狀態）放在 API 伺服器的常規資料庫裡；影片檔案本身放在儲存伺服器上。

用 ffmpeg 轉碼：HLS 位元速率階梯

每個影片一次編碼出多檔解析度，並對齊關鍵幀，播放器才能平滑切換清晰度。

mkdir -p out/v0 out/v1 out/v2 out/v3
ffmpeg -i input.mp4 \
  -filter_complex "[0:v]split=4[a][b][c][d];[a]scale=-2:1080[v0];[b]scale=-2:720[v1];[c]scale=-2:480[v2];[d]scale=-2:360[v3]" \
  -map "[v0]" -c:v:0 libx264 -b:v:0 5000k -maxrate:v:0 5350k -bufsize:v:0 7500k \
  -map "[v1]" -c:v:1 libx264 -b:v:1 2800k -maxrate:v:1 3000k -bufsize:v:1 4200k \
  -map "[v2]" -c:v:2 libx264 -b:v:2 1400k -maxrate:v:2 1500k -bufsize:v:2 2100k \
  -map "[v3]" -c:v:3 libx264 -b:v:3 800k  -maxrate:v:3 856k  -bufsize:v:3 1200k \
  -map a:0 -map a:0 -map a:0 -map a:0 -c:a aac -b:a 128k -ac 2 \
  -preset medium -profile:v high -pix_fmt yuv420p \
  -force_key_frames "expr:gte(t,n_forced*2)" -sc_threshold 0 \
  -f hls -hls_time 4 -hls_playlist_type vod -hls_flags independent_segments \
  -hls_segment_filename "out/v%v/seg_%04d.ts" \
  -master_pl_name master.m3u8 \
  -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2 v:3,a:3" \
  out/v%v/index.m3u8

• -force_key_frames "expr:gte(t,n_forced*2)" 不論幀率都每 2 秒插入一個關鍵幀，-sc_threshold 0 保證各檔位關鍵幀對齊。
• H.264 相容所有終端；之後可再加 HEVC 或 AV1 階梯，為支援的裝置節省頻寬。
• CPU 轉碼能力隨核心數線性擴充套件：高核心獨立伺服器是最簡單的轉碼叢集。每幾個核心跑一個 ffmpeg 任務，靠加機器擴容。

短影片要點：豎屏與秒開

短影片 App 的體驗取決於首幀時間，因此要用小切片、精簡階梯和預載入預覽。

# vertical short video: 3-step ladder, 2 s segments for a fast first frame
ffmpeg -i clip.mp4 \
  -filter_complex "[0:v]split=3[a][b][c];[a]scale=1080:-2[v0];[b]scale=720:-2[v1];[c]scale=540:-2[v2]" \
  -map "[v0]" -c:v:0 libx264 -b:v:0 3500k -maxrate:v:0 3750k -bufsize:v:0 5000k \
  -map "[v1]" -c:v:1 libx264 -b:v:1 2000k -maxrate:v:1 2150k -bufsize:v:1 3000k \
  -map "[v2]" -c:v:2 libx264 -b:v:2 1000k -maxrate:v:2 1070k -bufsize:v:2 1500k \
  -map a:0 -map a:0 -map a:0 -c:a aac -b:a 96k \
  -preset medium -force_key_frames "expr:gte(t,n_forced*2)" -sc_threshold 0 \
  -f hls -hls_time 2 -hls_playlist_type vod \
  -hls_segment_filename "short/v%v/seg_%03d.ts" -master_pl_name master.m3u8 \
  -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2" short/v%v/index.m3u8

# cover image and a small progressive MP4 preview for feeds
ffmpeg -ss 1 -i clip.mp4 -frames:v 1 -vf scale=540:-2 short/cover.jpg
ffmpeg -i clip.mp4 -t 6 -vf scale=360:-2 -c:v libx264 -b:v 400k -an -movflags +faststart short/preview.mp4

• 使用 2 秒切片，並預載入資訊流中下一條影片的首個切片。
• 60 秒以內的短片通常三檔就夠了，再多檔位只增加儲存，體驗提升有限。
• 上傳時就生成封面和無聲預覽，讓資訊流在發起 HLS 請求前就能渲染。

MinIO 物件儲存與冷熱分層

把轉碼檔案存放在獨立伺服器上的相容 S3 物件儲存裡，並按觀看頻率分層。

# single-node MinIO on a storage dedicated server (use distributed mode across 4+ servers for HA)
docker run -d --name minio --restart unless-stopped \
  -p 9000:9000 -p 9001:9001 \
  -v /data/minio:/data \
  -e MINIO_ROOT_USER=vodadmin \
  -e MINIO_ROOT_PASSWORD=replace-with-a-long-random-secret \
  minio/minio server /data --console-address ":9001"

# buckets: raw uploads (private) and hls output (public read via CDN)
mc alias set vod http://127.0.0.1:9000 vodadmin replace-with-a-long-random-secret
mc mb vod/raw
mc mb vod/hls
mc anonymous set download vod/hls
mc ilm rule add vod/raw --expire-days 180      # drop raw uploads after 180 days
mc mirror --overwrite out/ vod/hls/videos/abc123/

MinIO 採用 AGPLv3 許可，其社群版的分發方式有過調整，投產前請確認當前版本和許可條款；SeaweedFS、Garage、Ceph RGW 也是相容 S3 的可選方案。示例中的 raw 桶只是上傳暫存區；請把原片或高質量母版檔案另存到冷儲存，便於日後重新轉碼。

粗略估算：上面四檔階梯合計約 10.5 Mbps，即每分鐘影片約 79 MB。1,000 小時內容的轉碼檔案約 4.7 TB，另加原片。

CDN 分發與真實頻寬成本

影片平台最大的持續成本是頻寬而不是儲存，選伺服器前先算清楚。

• 公式：每月 TB = 觀眾數 × 分鐘數 × 60 × Mbps ÷ 8 ÷ 1,000,000 × 30。
• 在 HLS 儲存桶前接入 IMIDC CDN；快取命中率越高，儲存伺服器只需處理未命中的請求。
• 切片和點播播放列表釋出後不會再變，可設定很長的 Cache-Control，用帶版本號的路徑代替重新整理快取。
• 用簽名 URL 或 Token 防盜鏈，否則頻寬會被悄悄消耗。

區域選擇：香港、東京、新加坡還是洛杉磯

源站放在觀眾所在地、且到觀眾線路最好的地方。

很多平台只在 CDN 後面放一個主源站（通常在香港或東京），等到遠端區域的回源變慢時再加第二個源站。

版權與內容合規

影片平台要對使用者上傳的內容負責，合規機制應從第一天就寫進流水線。

• 只託管自有或已獲授權分發的內容，並要求上傳者同意相應的使用者協議。
• 公佈版權聯絡渠道和“通知—刪除”流程（例如 DMCA 式通知），及時處理有效投訴，並制定重複侵權處理政策。
• 記錄每個檔案的上傳帳號、IP 和時間，並儲存內容雜湊，防止被刪影片原樣重新上傳。
• 主機服務商會把版權投訴轉交給客戶，及時響應才能保證服務正常執行。
• 面向中國大陸的觀眾，內容必須合法，且在大陸提供網路視聽服務可能需要單獨的許可。以上為一般資訊，不構成法律意見。

哪種 IMIDC 方案適合你

先用一個源站加 CDN 起步，影片庫增長後再把轉碼和儲存拆開。

• MVP 或課程影片庫：一台香港獨立伺服器或日本獨立伺服器同時執行 API、MinIO 和 ffmpeg，再加 IMIDC CDN。
• 快速增長的短影片 App：獨立的轉碼伺服器、儲存型獨立伺服器上的 MinIO 叢集，以及 CDN。
• 美洲加大陸觀眾：增加帶 CN2 和 9929 線路的洛杉磯獨立伺服器。
• 自有儲存機箱：1U 到整機櫃的伺服器託管，含遠端協助服務。
• 大硬碟、多核心、新加坡或其他定製配置：聯絡 IMIDC 銷售定製。

常見問題

面向亞洲做一個類似抖音/TikTok 的短影片平台，需要哪些伺服器？

至少需要 API 伺服器、執行 ffmpeg 的轉碼伺服器、部署在儲存型獨立伺服器上的 MinIO 等相容 S3 儲存，以及 CDN。IMIDC 在香港、東京、洛杉磯等亞太節點提供獨立伺服器，並有 IMIDC CDN 支撐這套架構。

影片平台放香港還是新加坡？

大量觀眾在中國大陸就選香港，IMIDC 香港伺服器走中國電信 CN2 GIA，且託管無需 ICP 備案。東南亞選新加坡，日韓選東京；IMIDC 新加坡伺服器通過銷售按需配置。

一個點播平台要用多少頻寬？

觀眾數 × 觀看分鐘數 × 平均位元速率即可估算：日活 1 萬、人均 20 分鐘、1.5 Mbps，每月約 67.5 TB。大部分流量應由 CDN 承擔，儲存源站只處理快取未命中。

MinIO 適合存影片嗎？

MinIO 是廣泛使用的相容 S3 儲存，在獨立伺服器上存放 HLS 切片和原片效果很好。投產前請先確認其當前許可和版本；SeaweedFS、Garage、Ceph RGW 也可作為替代。

轉碼一定要 GPU 嗎？

不一定。在高核心獨立伺服器上用 ffmpeg 做 CPU 編碼，單位位元速率畫質最好，擴容也簡單。上傳量很大時 GPU 可以提速，可向 IMIDC 銷售諮詢 GPU 或高核心配置。

準備搭建自己的影片平台？瞭解香港獨立伺服器和 IMIDC CDN，或提交工單，由 IMIDC 工程師協助規劃儲存、轉碼和分發方案。