搭建视频点播与短视频平台后端：存储服务器、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 工程师协助规划存储、转码和分发方案。