WEB短视频源码

一套WEB短视频源码，视频核心就三样东西：视频上传转码、源码流媒体分发、视频前端播放器。源码别的视频功能——弹幕、点赞、源码评论、视频关注——都是源码长在这根主干上的枝叶。我见过太多团队一上来就折腾推荐算法，视频结果连视频上传后转码失败的源码问题都没解决。

先说上传。视频用户选完文件，源码前端用 FormData 切片，视频每片2MB左右，源码并发往服务端扔。视频服务端收到分片先存临时目录，同时往Redis里记一条“upload:fileId:chunkIndex”的状态。所有分片到齐，合并成完整文件。这一步不难，坑在断点续传——用户传了一半关掉页面，下次回来得从已传分片继续，不能从头再来。源码里通常用 localStorage 存fileId和已传分片索引，刷新后先请求服务端查已收分片列表，再决定从哪片开始。

合并完的文件不能直接播。浏览器原生 <video> 标签对MP4支持最好，但MP4的moov原子如果在文件尾部，必须整个文件下载完才能播放。所以源码里一般会调FFmpeg做两件事：把moov移到文件头（-movflags faststart），再转出HLS切片。HLS是苹果那套 .m3u8 + .ts 方案，兼容性最广，安卓iOS浏览器通吃。转码命令大概长这样：

ffmpeg -i input.mp4 -c:v libx264 -c:a aac -f hls -hls_time 10 -hls_list_size 0 output.m3u8

转码是异步的。源码里会开一个任务队列，用Redis的 BRPOP 阻塞读取转码任务，转完一个再取下一个。小团队用单机跑就行，量大再上分布式转码集群。我见过有人用云函数做转码，便宜是便宜，但冷启动和超时限制能把人逼疯。

流媒体分发这块，HLS的 .ts 切片直接扔Nginx或者对象存储，.m3u8 索引文件动态生成。Nginx配个 location ~ \.m3u8$ 加 add_header Cache-Control no-cache，防止播放列表被缓存导致新切片拉不到。如果想省钱，切片文件设长缓存，索引文件不缓存，这是标准做法。

前端播放器选型看场景。PC端用 video.js 或 hls.js，移动端直接 <video> 标签加 playsinline 属性就能播HLS。hls.js的原理是MSE（Media Source Extensions），把 .ts 切片喂给 SourceBuffer。源码里初始化大概这样：

if (Hls.isSupported()) {  const hls = new Hls(); hls.loadSource('https://cdn.example.com/video/abc.m3u8'); hls.attachMedia(videoElement); }

播放器要处理的事件不少：loadedmetadata 后设置初始时间、timeupdate 上报观看进度、ended 触发下一条自动播放。弹幕的话，用 requestAnimationFrame 逐帧计算弹幕位置，比CSS动画性能好，因为弹幕数量多了CSS动画会掉帧。

数据库设计有个细节：视频表里存 m3u8_url 和 cover_url，但别存 .ts 切片路径——切片数量随视频时长变化，存不过来。播放时前端请求 .m3u8，里面自然包含所有切片地址。

最后说个真实教训。有人把转码后的HLS切片放在同一台服务器上，用户一多，磁盘IO直接打满，视频卡成PPT。正确做法是切片文件推CDN，源站只保留原始文件和索引。CDN回源一次，后续全走边缘节点。成本？比买大带宽服务器便宜多了。

源码这东西，看一百遍不如自己搭一遍。找个开源的（比如 csharpserver 那套或者 Node.js 写的 video-streaming 项目），跑起来，改两行代码，看效果。比读十篇架构文章管用。

本文地址：http://www.79wt.cn/news/1616d1899820.html