车辆视频流媒体链路
背景
在车辆监控系统里，除了位置和轨迹，实时视频也是重要的功能。 车载终端通过网络把摄像头视频传到平台，用户在网页上就能看到实时画面。 这里整理一下整条链路的组成和关键技术点。
整体链路
车辆终端
↓ RTP 推流
收流服务（mediaserver）
↓ RTMP 推流
流媒体服务（nms）
↓ WebSocket / HTTP-FLV
反向代理（nginx）
↓ WSS
用户浏览器各环节说明
1. 车辆终端 → 收流服务
车载终端通常使用 RTP（Real-time Transport Protocol） 协议把视频流推送到平台的固定端口。RTP 是实时传输协议，适合视频、 音频这类对延迟敏感的场景。
终端侧要做的事：编码（H.264/H.265）、封装成 RTP、按目标地址发送。 平台侧要做的事：监听端口、接收 RTP 包、解析并重组为完整的视频帧。
2. 收流服务 → 流媒体服务
收流服务把 RTP 流转成 RTMP（Real-Time Messaging Protocol） 再推给流媒体服务。RTMP 是基于 TCP 的协议，兼容性好，很多流媒体服务 都支持。
3. 流媒体服务 → 用户
流媒体服务把 RTMP 转成浏览器能直接播放的格式。常见的有：
- HTTP-FLV - 基于 HTTP 的长连接，延迟低
- WebSocket-FLV - 基于 WebSocket，延迟更低
- HLS - 基于 HTTP 分片，兼容性最好但延迟高（3~10 秒）
4. 反向代理
流媒体服务对外暴露端口，nginx 做反向代理，加上 SSL 证书提供 WSS
（WebSocket over TLS）服务。这样用户就能通过
wss://域名:端口/路径 访问。
技术难点
1. 协议转换
从 RTP 到 RTMP 到 WebSocket，每一步都要拆包、重组、转封装。 这一步通常由专门的流媒体服务完成，自己实现成本很高。
2. 延迟控制
视频直播最大的挑战是延迟。不同协议的延迟差异很大：
| 协议 | 典型延迟 | 适用场景 |
|---|---|---|
| RTMP | 1~3 秒 | 直播推流 |
| HTTP-FLV | 1~3 秒 | 网页播放 |
| WebSocket-FLV | 0.5~2 秒 | 低延迟播放 |
| HLS | 5~20 秒 | 点播、兼容性优先 |
3. 弱网环境
车载场景网络不稳定，需要处理：
- 丢包重传
- 自动重连
- 码率自适应
- 缓存策略
常见问题
问题 1：视频黑屏
可能是收流服务没起、端口映射丢失、或者流媒体服务没收到流。 排查顺序：端口是否监听 → 服务进程是否存活 → 日志有没有报错。
问题 2：视频卡顿
网络带宽不足、服务端处理不过来、或者客户端解码性能不够。 先看服务端 CPU 和带宽占用，再看客户端是否用了合适的播放器。
问题 3：多个用户同时观看
流媒体服务要支持"一路推流、多路拉流"。用户多了之后， 需要考虑 CDN 分发或边缘节点。
参考资料
- SRS 流媒体服务器
- Node-Media-Server
- RFC 3550 - RTP 协议规范