Building a VOD and Short-Video Platform Backend: Storage Servers, FFmpeg HLS Transcoding, MinIO and CDN

A video-on-demand or short-video platform backend needs four things: storage dedicated servers for originals and renditions, an ffmpeg transcoding pipeline that outputs HLS bitrate ladders, S3-compatible object storage such as MinIO, and a CDN that carries most of the bandwidth. IMIDC supplies the infrastructure in Hong Kong (CN2 GIA to mainland China), Tokyo, Singapore, Los Angeles and other Asian locations: Hong Kong dedicated servers from $139/mo, Los Angeles dedicated servers from $499/mo, 10Gbps uplinks, DDoS protection and the IMIDC CDN.

The VOD pipeline from upload to playback

Every video platform follows the same pipeline: upload, store the original, transcode, store renditions, deliver through a CDN.

1. Upload: clients upload directly to object storage with presigned URLs, so your API servers never proxy large files.
2. Queue: an upload-complete event puts a job in a queue (Redis, RabbitMQ or a database table).
3. Transcode: worker servers run ffmpeg to produce an HLS ladder, a cover image and a short preview.
4. Store: renditions go to a public-read HLS bucket; originals go to cold storage.
5. Deliver: the player loads master.m3u8 from the CDN, which pulls missing segments from your storage origin.

Keep metadata (titles, owners, view counts, moderation status) in a normal database on an API server; keep bytes on storage servers.

Transcoding with ffmpeg: HLS bitrate ladders

Encode each video once into several resolutions with aligned keyframes, so players can switch quality smoothly.

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)" puts a keyframe every 2 seconds regardless of frame rate, and -sc_threshold 0 keeps them aligned across renditions.
• H.264 plays everywhere; add an HEVC or AV1 ladder later to cut bandwidth for devices that support it.
• CPU transcoding scales with cores: high-core dedicated servers are the simplest worker pool. Run one ffmpeg job per few cores and scale by adding servers.

Short-video specifics: vertical video and instant start

Short-video apps live or die by time to first frame, so use small segments, a short ladder and preloaded previews.

# 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

• Use 2-second segments and preload the first segment of the next items in the feed.
• Three renditions are usually enough for clips under 60 seconds; extra steps cost storage without improving experience much.
• Generate covers and silent previews at upload time so the feed renders before any HLS request.

Object storage with MinIO and hot/cold tiers

Store renditions in S3-compatible object storage on dedicated servers, and tier data by how often it is watched.

# 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 is licensed under AGPLv3 and its community distribution has changed over time, so check the current edition and license before production use; SeaweedFS, Garage and Ceph RGW are other S3-compatible options. In this example the raw bucket is only an upload staging area; keep the original or a high-quality mezzanine file in cold storage so you can re-transcode later.

Rough sizing: the 4-rung ladder above totals about 10.5 Mbps, or about 79 MB per minute of video. 1,000 hours of content is therefore about 4.7 TB of renditions, plus the originals.

CDN delivery and the real cost of bandwidth

Bandwidth, not storage, is the largest running cost of a video platform, so estimate it before choosing servers.

• Formula: monthly TB = viewers x minutes x 60 x Mbps / 8 / 1,000,000 x 30.
• Put the IMIDC CDN in front of the HLS bucket; a high cache-hit ratio means storage servers only serve cache misses.
• Set long Cache-Control lifetimes on segments and VOD playlists (they never change once published) and version file paths instead of purging.
• Use signed URLs or tokens to stop hotlinking, which silently burns bandwidth.

Choosing a region: Hong Kong vs Tokyo, Singapore and Los Angeles

Place origins where your viewers are and where the routes to them are strongest.

Many platforms run one primary origin (often Hong Kong or Tokyo) behind the CDN and add a second origin only when cache misses from a distant region become slow.

Copyright and content compliance

A video platform is responsible for handling what users upload, so build compliance into the pipeline from day one.

• Only host content you own or are licensed to distribute, and make uploaders accept terms that say the same.
• Publish a copyright contact and a notice-and-takedown process (for example DMCA-style notices), act on valid notices quickly, and keep a repeat-infringer policy.
• Log uploader account, IP and time for every file, and store content hashes so removed videos cannot simply be re-uploaded.
• Hosting providers forward copyright complaints to their customers; respond promptly to keep your service running.
• For audiences in mainland China, content must be lawful, and online audio-visual services there may require separate licenses. This is general information, not legal advice.

Which IMIDC setup fits

Start with one origin and a CDN, then split transcoding and storage as the library grows.

• MVP or a course library: one Hong Kong dedicated server or Japan dedicated server running the API, MinIO and ffmpeg, plus IMIDC CDN.
• Growing short-video app: separate transcoding workers, a MinIO cluster on storage dedicated servers and the CDN.
• Americas plus China audiences: add Los Angeles dedicated servers with CN2 and 9929 routes.
• Your own storage chassis: colocation from 1U to a full rack with remote hands.
• Large disks, many cores, Singapore or custom builds: contact IMIDC sales for a custom configuration.

FAQ

What servers do I need to build a short-video platform like TikTok for Asia?

At minimum you need API servers, transcoding workers running ffmpeg, S3-compatible storage such as MinIO on storage dedicated servers, and a CDN. IMIDC provides dedicated servers in Hong Kong, Tokyo, Los Angeles and other Asian locations plus the IMIDC CDN for this stack.

Should I host my video platform in Hong Kong or Singapore?

Choose Hong Kong if many viewers are in mainland China, because IMIDC Hong Kong servers use China Telecom CN2 GIA and need no ICP filing for hosting. Choose Singapore for Southeast Asia and Tokyo for Japan and Korea; IMIDC configures Singapore servers on request via sales.

How much bandwidth does a VOD platform use?

Multiply viewers by watch minutes and average bitrate: 10,000 daily viewers watching 20 minutes at 1.5 Mbps use about 67.5 TB per month. A CDN should deliver most of that so your storage origin only handles cache misses.

Is MinIO a good choice for video storage?

MinIO is a widely used S3-compatible store that works well for HLS segments and originals on dedicated servers. Review its current license and edition first; SeaweedFS, Garage and Ceph RGW are alternatives.

Do I need GPUs to transcode video?

No. CPU encoding with ffmpeg on high-core dedicated servers gives the best quality per bit and is simple to scale. GPUs speed up high volumes of uploads; ask IMIDC sales about GPU or high-core configurations.

Ready to build your video platform? Explore Hong Kong dedicated servers and the IMIDC CDN, or open a ticket and IMIDC engineers will help you plan storage, transcoding and delivery.