h1: 当你手头有365路NDI视频流，中文字幕怎么加才不翻车？
说实话,我第一次接到这个需求的时候，脑子里蹦出来的第一个念头是：“365路？你确定不是36路？”对方很认真地看着我，说就是365路，每年每一天每一路，好家伙，这数字还真吉利，但真干起来，一点都不吉利。
我先试了手头的几个现成工具,FFmpeg直接怼进去，CPU直接飙到95度，风扇跟直升机起飞似的，VLC？单路还行，多路？别闹了，后来我冷静下来想，这事儿得换个思路——用Golang自己搭一个轻量级的字幕叠加服务，为啥选Go？因为并发啊，365路流的处理，每个流都得独立管理，Go的goroutine天生适合干这个。
h2: 为什么NDI视频字幕这么麻烦？
先说清楚,NDI（Network Device Interface）这玩意儿本身不含字幕轨道，它是纯视频加音频的IP流，你要加中文字幕，就得在视频画面的某个区域把字幕“画”上去，而且中文字幕跟英文字幕不一样，中文是方块字，每个字占用的像素不一样，字体渲染起来更吃资源。
我一开始用的是gocv（OpenCV的Go绑定）来做字幕叠加，思路是这样：
- 从NDI源拉取每一帧图像
- 用
freetype库在图像上绘制中文字符 - 再把带字幕的帧推送到输出NDI流
结果呢？单路视频720p 30fps，处理延迟就飙到了120ms，365路？那画面太美我不敢想。
h3: 核心瓶颈到底在哪儿？
第一层瓶颈：NDI接收端的效率。 我用的是github.com/ondi/ndi-go这个库，一开始用的RecvCaptureV2拉取帧，每次拉取都要做一次内存拷贝，365路同时拉，内存带宽直接被打满。
第二层瓶颈：字幕渲染。 每帧都用CPU去渲染中文字符，那算力需求是天文数字，中文字库动辄几千个字符，每次渲染都要查字库、做抗锯齿、做位置计算。
第三层瓶颈：视频编码。 加完字幕的帧要重新编码成NDI流输出，软件编码器（哪怕是x264的fast模式）也扛不住365路并发。
h2: 我最终用的方案是什么？
我承认,一开始想得太理想了，后来我做了个取舍——不是所有流都实时渲染字幕，我把365路分成三类：
- 关键流（大约20路）：需要实时高质量中文字幕
- 普通流（大约100路）：需要字幕，但可以接受低画质
- 监控流（剩下的）：只要字幕出现就行，画质无所谓
然后针对不同类别用不同的处理管线。
关键流的方案最折腾：
- 用NDI的硬件加速接收模式（
RecvCapture配合CUDA），减少CPU拷贝 - 字幕渲染放到GPU上做,我用的是
vulkan-go配合一个预先将中文字库烘焙成纹理图集的方案，字幕文本先映射成纹理坐标，然后在片段着色器里混合到视频帧上，这样每帧的渲染成本基本是固定的，跟字幕长度无关。 - 输出端用NDI的硬件编码插件,让显卡直接输出带字幕的H.264流。
普通流就简单多了：用软解+gocv的普通PutText（但字体文件换了精简版，只包含常用3500个汉字），分辨率降到540p，帧率砍到15fps，监控流更粗暴：每5秒更新一次字幕，画面直接用JPEG质量50压缩。
h3: 内存管理上踩的一个大坑
这一条必须单拿出来说,Go的垃圾回收（GC）在365路并发的情况下，简直是一场噩梦，每帧图像数据都是[]byte，365路每秒30帧，那每秒有10950次内存分配，GC一触发，整个程序停顿几百毫秒，视频直接卡成PPT。
我最后的解决办法是：用sync.Pool复用帧缓冲区，并且自己实现了一个无锁的内存池来管理NDI接收端的VideoFrame结构体，具体代码不贴了，但思路是预先分配好一个固定大小的内存池，每个goroutine从池子里拿帧，用完再还回去，全程不触发GC。
大概的效果是：GC从原来每秒触发好几次，变成十几分钟才触发一次。
h2: 中文字幕的那个“细”问题
别以为“画”个字上去就完事了，中文排版跟英文不一样，英文单词有空格分隔，中文没有，而且中文里会出现英文、数字、标点混排，第1路：会议室A（3楼）”，你要是用简单粗暴的textWidth = len(text) * fontSize来算位置，那屏幕上的字一会儿重叠一会儿间距过大。
我后来用一个叫golang.org/x/image/font的库配合golang.org/x/image/math/fixed做精确的文本度量（text measuring），每个字符的字宽都不太一样，我用一个[]rune遍历每个字符，累计实际像素宽度，然后才决定换行位置。
对了,还有字体版权的问题，别随便找个免费字体就拿来商用，最后我选的是思源黑体，开源，而且字重选择多，渲染效果好。
h2: 一个真实的性能对比表
我做了一组测试,机器配置是：双路Xeon Gold 6248R，256GB内存，一张RTX A6000，测试源是1080p 25fps的NDI流，字幕内容是随机中文新闻稿。
| 方案 | 可支持最大并发路数 | 平均延迟 | CPU占用 | 内存占用 |
|---|---|---|---|---|
| FFmpeg滤镜（串行） | 8路 | 85ms | 320% | 3GB |
| Go+gocv软渲染 | 18路 | 142ms | 680% | 1GB |
| Go+GPU着色器（关键流方案） | 42路（单卡） | 12ms | 45% | 2GB |
| 上述混合分级方案 | 365路 | 关键流15ms，普通流85ms，监控流320ms | 232% | 8GB |
365路是跑起来了,虽然监控流那320ms延迟在直播场景下有点扎眼，但至少没有丢帧，没有OOM，没有GPU过热。
h2: 其实到现在我还在改
文章写到这里,其实我后台还在跑着一套压力测试，刚发现一个bug：当字幕文本里同时出现“龘”（三个龙）这种生僻字的时候，我的精简字库里没这玩意儿，直接显示一个方框，得把那三千五百个常用字再扩充一下，至少到GB2312的6763个字。
但这个系统基本能用,它不完美，甚至有点粗糙——比如GPU方案的初始化代码里还有几个todo注释，但面对365路NDI视频流加中文字幕这种需求，有时候你得承认，完美的方案不存在，足够好就行。
你也遇到类似的需求？别急着买现成的字幕机或者服务器，先想想你的瓶颈到底在哪儿，是IO、是渲染、还是编码，然后用Go把每个环节拆开，分别做优化，Go的pprof很好用，跑一跑就知道了。
本文来自作者[kyadmin]投稿，不代表be365立场，如若转载，请注明出处：http://www.uss1.cn/keji/1184.html
评论列表（4条）
我是be365的签约作者“kyadmin”！
希望本篇文章《用Golang搞365 NDI视频中文字幕？这事儿我替你踩过坑了》能对你有所帮助！
本站[be365]内容主要涵盖：be365,be365网站,be365网址,ball365体育,Be365排名
本文概览：h1:当你手头有365路NDI视频流，中文字幕怎么加才不翻车？说实话,我第一次接到这个需求的时候，脑子里蹦出来的第一个念头是：“3...