视频开发到底在开发什么？一张图讲清整个技术栈
【视频开发工程化实战：架构、协议与AI落地】
很多人第一次接触视频开发，都是从一句话开始的：
“把摄像头接进来，能看就行。”直到项目真的跑起来，才发现事情完全不是这么简单。
如果你也是后端 / 平台开发，或者做过一点视觉算法，大概率都会有这种感觉：
视频开发，好像什么都沾一点，但又哪儿都不轻松。
一、先说结论：视频开发 ≠ 接摄像头 ≠ 跑模型
在真实项目里，“视频开发”至少包含 6 个层面：
任何一个环节出问题，最终体验都会很差。
而很多项目失败，恰恰是因为：
- 只关注了“能不能看”
- 或只关注了“模型准不准”
- 却忽略了中间大量的工程问题
二、视频开发的第一层：设备与采集（最不标准的一层）
现实中的摄像头世界，非常混乱：
- 不同厂家
- 不同协议实现
- 不同码率、分辨率、帧率
- 同一型号，不同固件，表现都不一样
哪怕都号称支持 ONVIF / RTSP，你也会遇到：
- 能连，但时不时断
- 白天正常，晚上码流异常
- 并发一高，设备先扛不住
工程上的共识是：
设备永远是不可靠的，你的系统必须假设它随时会出问题。
三、视频传输：真正的“技术选择地狱”
视频不是普通的 HTTP 请求，它是：
- 长连接
- 大带宽
- 持续输出
- 对延迟极其敏感
你会反复纠结这些问题：
- RTSP、RTMP、HLS、WebRTC 到底选哪个？
- 是直连设备，还是先转发？
- 延迟是 300ms 还是 3 秒，业务能不能接受？
而残酷的现实是：
没有“最优方案”，只有“当前场景下的最合适”。
这也是为什么视频开发很难“一次设计到位”。
四、解码与转码：CPU / GPU 的黑洞
很多非视频背景的工程师，第一次被“性能问题”暴击，通常就在这里。
- 一路视频看着没事
- 十路还能忍
- 一百路直接把服务器打趴
常见误区包括：
- 以为分辨率只是“清晰度问题”
- 忽略编码格式对算力的影响
- 在不需要的地方做了转码
视频系统里，没有“免费的计算”。
每一次解码、转码，背后都是：
- CPU 时间
- GPU 显存
- 带宽成本
五、存储与回放：比“存下来”复杂得多
“录像存一下，回头能放不就行了？”
这是很多项目的起点，也是很多项目的坑点。
真实情况是：
- 视频是连续数据，不能随便切
- 回放需要时间轴对齐
- 大规模存储，成本是指数级增长
更别说：
- 快进、拖动
- 精确到秒的定位
- 多路同步回放
录像系统，本质上是一个时间序列系统。
六、AI 分析：不是跑个模型就结束了
当你引入 AI，事情只会变得更复杂：
- 实时分析还是离线分析？
- 抽帧频率怎么定？
- 模型误报谁来兜底？
很多工程师会发现：
模型本身的问题，反而不是最大的。
真正难的是：
- 算法和工程如何解耦
- 模型输出如何转成“业务事件”
- 错误如何被感知、被修正
七、业务层：决定项目“有没有用”
最后一层，往往被低估，但最关键。
用户并不关心：
- 你用了什么协议
- 模型 mAP 有多高
他们关心的是：
- 能不能及时发现问题
- 有没有明确的告警
- 出事之后能不能追溯
从“能看见”到“用得上”，中间隔着完整的业务设计。
八、为什么视频开发这么“累”
总结一句话：
视频开发，是把网络、系统、存储、AI、业务，强行拧在一起的一门工程。
它不像纯后端那样边界清晰，
也不像纯算法那样目标单一。
但也正因为这样：
- 能做好的工程师不多
- 一旦跑通，壁垒极高
写在最后
如果你正准备进入视频领域，希望你记住两点：
- 不要只盯着某一个技术点
- 一定要从系统视角看问题
后面的文章，我会：
- 拆协议
- 拆架构
- 拆性能
- 拆 AI 落地
尽量用真实工程经验，讲清这些“看起来很玄、其实很工程”的问题。
如果你也在做视频相关的系统，希望这个系列能帮你少踩一些坑。
