说实话，我刚开始压根没想过用Golang去搞赛事直播视频的事儿，沧源那边有个挺热闹的赛事，好像是叫“沧源vs”什么的对决，具体项目我不细说了，反正就是那种本地人特别上头、看直播的人数能冲到好几万的那种，我本来只想安安静静当个观众，结果发现官方直播平台那个缓冲啊，卡得我快把键盘砸了，于是我一拍脑袋——能不能用Golang自己写个看比赛的玩意儿？
要搞直播，先搞清楚“视频流”是个啥
很多人一听到“视频流”就头大，觉得是什么高深的东西，其实你把它当成一长串不断被发送的数据块就行了，就像你吃火锅，涮羊肉是一片一片放进嘴里的，视频流呢，是一帧一帧发到你设备上的，Golang的net/http包能把视频流当文件一样读进来，关键是你不能让这个“读”的过程停下来。
我当时写了一个超级简陋的测试：
resp, _ := http.Get("https://cangyuan-live.example.com/stream.m3u8")
defer resp.Body.Close()
buf := make([]byte, 1024*64)
for {
n, err := resp.Body.Read(buf)
if err != nil { break }
// 把buf[:n]发给前端
}
你瞧，这就是最核心的东西，不用管什么复杂概念，就是把字节流从服务器拉到本地，再往前推，光这样还不够，因为视频是有编码格式的，H.264、AAC这些术语你迟早会碰到，我的建议是先别纠结编码细节，Golang社区已经有gortsplib和mpegts这些库帮你处理了。
沧源的网络环境，逼我写了个“自适应缓冲”
你们可能不知道，沧源那边的网络信号有时候真的一言难尽，我去过那边一趟，山多，云多，4G信号忽强忽弱，如果用死板的缓冲区大小，视频就会一卡一卡的，所以我用Golang写了个动态缓冲算法，其实没什么高深的，就是根据连续几秒的数据到达速度,自动调整预读量。
我一开始用的是固定10秒缓冲，结果延迟高得离谱，比赛都进球了我这边还在看中场回防，后来改成基于滑动窗口的调整：
- 如果最近5秒每秒数据量大于阈值（比如2MB/s），那就把缓冲目标设为3秒
- 如果数据量掉到500KB/s以下，就逐步增加到8秒缓冲
代码里就一个goroutine专门做这个事情，用一个channel把调整后的缓冲参数发给拉流协程，你别说，这个思路在沧源那种网络下还真管用，视频虽然画质会降，但至少不卡死了，不过我得坦白，延迟还是比官方App高了大概2到3秒,但对于自己写着玩已经很满意了。
多路复用这件事，Golang真把我看傻了
后来我发现沧源那个赛事不只有一个机位，主镜头、特写镜头、无人机俯拍，好家伙，三路流同时推，我要是每个流开一个HTTP连接去拉，性能肯定崩，这时候Golang的goroutine简直救了我老命。
我设计了一个流管理器大致结构：
- 一个主goroutine负责接收用户点击切换机位的请求
- 每个机位开一个独立的goroutine去拉流
- 这些拉流的goroutine把数据写入共享的环形缓冲区（ring buffer）
- 播放端只从当前选中的机位缓冲区读数据
写这段代码的时候有个小插曲：我一开始没加锁，结果两个goroutine同时写缓冲区，数据全乱了，后来用sync.Mutex加了个锁就好了，其实更好的做法是用atomic包，但我懒,mutex够用。
type StreamManager struct {
streams map[string]*RingBuffer
mu sync.Mutex
current string
}
func (sm *StreamManager) SwitchTo(cameraID string) {
sm.mu.Lock()
defer sm.mu.Unlock()
sm.current = cameraID
// 通知播放器切换
}
就是这个看起来土里土气的代码，让我在沧源的赛事直播中实现了无缝切换机位，切过去的时候视频大概有0.5秒的“顿一下”的感觉，但总体上比官方播放器还流畅——我得说,有点小得意。
用Golang解码？我劝你放弃，但有个替代方案
我一开始天真的以为可以用Golang直接把视频流解码成图片，然后用image包显示，结果试了ffmpeg的Go绑定，编译就报了一堆错，后来查资料才发现，Golang在视频解码这块其实挺弱的，社区里比较成熟的库也就gocv（OpenCV的包装）和goav（FFmpeg的包装）,但安装依赖都挺折腾的。
我的解决方案是这样的：用Golang做拉流和分发，用浏览器来做解码和渲染，也就是说，我在服务端用Golang把视频流切成小片段（比如每2秒一个.ts文件），然后通过WebSocket推给前端，前端用HLS.js或者flv.js去解码，这样既利用了Golang的高并发优势,又避开了它的短板。
具体实现是这样的：
- Golang拉流程序把原始TS流切成多个2秒的片段
- 每个片段写入内存中的文件系统（我用的是ramfs）
- 前端通过HTTP请求获取最新的片段列表（一个JSON文件）
- 播放器按顺序加载这些片段
这个方法有个缺点：延迟会比直接拉流高个几秒，因为要等一个片段完全下载完才会播放，但对于沧源赛事那种场景，观众更看重流畅度而不是实时性，所以这个折中其实挺合适的,你可以对比一下：
| 方案 | 延迟 | 流畅度 | 开发难度 |
|---|---|---|---|
| 原生拉流 | 1-2秒 | 中 | 高 |
| Golang切片分发 | 4-6秒 | 高 | 中 |
| 第三方SDK | 2-3秒 | 中 | 低 |
对于自己搞着玩，切片分发方案是最平衡的，我甚至给这个方案起了个名字，叫“沧源流”方案,哈哈。
碰到的那些坑，现在想起来还挺好笑的
写这个项目的过程中，我碰到了不少问题，有几个特别典型,估计大家也会遇到。
第一个坑是内存泄漏。 我开了10个goroutine同时拉流，结果跑了半小时内存涨了200MB，查了半天发现是缓冲区没清理，老的视频切片占着内存不放，解决办法是在切片管理器中加了个TTL机制,超过30秒的切片自动删除。
第二个坑是HLS的m3u8文件解析。 沧源那边的直播源用的不是标准的m3u8，里面有的标签是自定义的，比如#CANGYUAN-SYNC:12345，我用Golang的标准库解析直接报错，后来只能用bufio.Scanner手动逐行读取,碰到不认识的行就跳过。
scanner := bufio.NewScanner(reader)
for scanner.Scan() {
line := scanner.Text()
if strings.HasPrefix(line, "#") && !strings.HasPrefix(line, "#EXT") {
continue // 跳过非标准标签
}
// 处理正常的TS片段的URL
}
这个方法虽然土，但管用，有时候真的，别想着所有事情都用优雅的方式解决,能把比赛看下来才是最重要的。
第三个坑是WebSocket的二进制帧。 我一开始用JSON格式传视频片段，结果光序列化和反序列化就占用了大量CPU，后来改成直接用二进制帧传原始TS数据，性能直接翻倍，这个问题其实比较偏，但如果你也想自己实现，记得用websocket.MessageTypeBinary。
用Golang写视频播放的一点心得
说真的，用Golang写赛事直播视频这件事，一开始看起来挺吓人的，但拆开来一看，无非就是：拉流、缓冲、分发、播放，每一步都有现成的库可以参考,Golang的并发模型又特别适合处理这种实时数据流。
沧源vs赛事的直播视频，我用自己写的程序看了好几场，虽然画面偶尔模糊一下，虽然切台的时候会有半秒卡顿，但那种“这程序是我自己写的”的感觉，比官方App的4K清晰度还爽，我甚至给程序加了个功能：在比赛暂停的时候，自动把最近三分钟的精彩片段存下来，这个功能也是在Golang里做的，用了个简单的事件循环监听比分变化，一旦检测到进球概率高的时间段（比如攻防转换），就标记缓冲区里的数据为“重要”,最后单独打包成一个短视频。
这个功能现在还不太完善，有时候会把教练喝水的画面也当成精彩镜头，但我相信慢慢调参会好起来的，就像我前面说的，不完美才是真实的，你如果也打算用Golang搞类似的视频项目，我的建议是别想太多，先让视频动起来，再去优化，工具都是次要的，重要的是你想看的那场比赛,能顺利看完。
哦对了，如果你也在沧源，或者也在用Golang搞视频流，欢迎交流经验，我最近在研究怎么用Pion WebRTC库把这个切片分发方案升级成真正的实时传输，低延迟的那种，等我搞定了再来分享，不过那可能是下个月的事了，毕竟沧源vs赛事的热度不会一直这么高,我得趁现在多看几场好比赛。
本文来自作者[kyadmin]投稿，不代表中国·AC米兰(Milan)体育官方网站-Official Website立场，如若转载，请注明出处：http://www.pi-pa-yq.com/ly/761.html
评论列表（4条）
我是中国·AC米兰(Milan)体育官方网站-Official Website的签约作者“kyadmin”！
希望本篇文章《沧源vs赛事直播视频，用Golang看比赛，这事儿还真让我整明白了》能对你有所帮助！
本站[中国·AC米兰(Milan)体育官方网站-Official Website]内容主要涵盖：AC米兰,ac米兰官网,AC米兰官网
本文概览：说实话，我刚开始压根没想过用Golang去搞赛事直播视频的事儿，沧源那边有个挺热闹的赛事，好像是叫“沧源vs”什么的对决，具体项目我不细...