RK3588 视频编码与推流方案：RTSP、RTMP 与低延迟实践
瑞芯微 RK3588 的硬件编码器让它能同时承担多路视频压缩与推流，实际延迟与画质由编码参数、协议选型与缓冲策略共同决定。低延迟没有单点开关，只能沿延迟构成逐层削减。
编码参数怎么影响延迟与画质？
硬件编码是这类平台的强项，可同时编码的路数与格式上限以原厂官方规格书为准。参数取舍直接影响带宽、画质与延迟：
- GOP 长度与随机接入：GOP 越长，平均码率越低但关键帧间隔越久，播放器随机接入与秒开越慢；直播与预览场景常把 GOP 压到 1~2 秒，录像可放长。
- 码率控制：CBR 输出稳定、利于带宽规划；VBR 在复杂画面给更多码率、画质更好但峰值不可控；AVBR 介于两者之间，适合带宽有上限又要兼顾画质的场景。
- 参考帧与延迟：多参考帧提升压缩效率却增加编码耗时与解码依赖，低延迟链路通常减少参考帧数量。
- B 帧：B 帧需要前后参考，会引入额外缓存与延迟，低延迟场景通常不用或极少用。
- 码率与画质权衡：带宽受限时优先保帧率与流畅度，再降分辨率，之后才压码率；一味压码率会导致块效应与运动模糊。
编码格式与档位同样要提前定：H.264 兼容性广、软硬解支持成熟，H.265 在同画质下可省下可观带宽但对解码端有要求，更新的格式则在终端支持上更挑剔，能否启用要以全链路设备能否解码为准。分辨率与帧率也不是越高越好：在带宽与算力固定时，把 4K30 降到 4K25 或 1080p30，往往比强行榨取码率更能换来稳定观感。档位确定后应写入规格书，作为编码参数与带宽预算的共同基准。
RTSP、RTMP、SRT、WebRTC、GB28181 怎么选？
| 协议 | 典型延迟量级 | 适用场景 | 主要代价 |
|---|---|---|---|
| RTSP | 数百毫秒级 | 局域网预览、传统视频监控生态、NVR 接入 | 公网穿透弱，多依赖内网或专线 |
| RTMP | 秒级 | 向直播平台推流、CDN 分发 | 基于 TCP，弱网下延迟累积 |
| SRT | 数百毫秒级 | 跨公网、弱网抗丢包的稳定传输 | 需收发两端支持，生态工具链相对新 |
| WebRTC | 百毫秒级或更低 | 浏览器端超低延迟预览、远程操控 | 部署与信令复杂，多路并发开销高 |
| GB28181 | 秒级 | 行业级联、平台对接与统一管理 | 协议栈重，依赖平台侧配合调试 |
延迟量级为经验区间，受网络质量、服务端转发与终端解码能力影响，须以实测为准。选型时先明确谁在看、在哪里看、能不能接受秒级：内网监控生态优先 RTSP，平台分发用 RTMP，公网弱网选 SRT 或 WebRTC，行业级联走 GB28181。部署复杂度也要计入排期：SRT 与 WebRTC 需要收发两端配合调参，GB28181 依赖平台侧联调，RTSP 与 RTMP 的落地经验相对丰富。
端到端延迟由哪些环节构成？
把链路拆开看，延迟由采集、编码、缓冲队列、网络传输、服务端转发、解码与渲染依次叠加。优化顺序是：先测量每一段的实际耗时，找出占比大的那一段，再逐层削减。经验上，编码耗时与网络传输常被过度关注，而采集与编码之间的缓冲队列往往才是被忽视的大头，队列为抗抖动而设，设得过深就会把延迟固定在高位。削减手段包括：降低队列深度并配合丢帧策略、缩短 GOP、减少参考帧、选择低延迟协议、合并渲染与显示链路。
延迟要量化才能优化：在采集、编码输入、编码输出、发送、接收、服务端转发、解码与渲染各点打时间戳，算出每段耗时再按占比排序。经验上，局域网内传输往往只占一小部分，真正拉高延迟的通常是采集缓冲、编码前置队列与服务端转发队列。每次只改一个环节并复测同一场景，才能确认改动是否有效；同一段耗时在不同网络条件下差异很大，结论须在目标网络环境下实测。
多路并发与带宽预算怎么算？
带宽预算的基本式为总带宽 = 各单路码率之和 × 并发系数，并发系数取 1.2~1.5，用来覆盖场景突变与客户端重连时的峰值。规划时有几条经验原则：
- 先定单路分辨率与帧率，再定码率上限，之后乘路数；顺序颠倒容易出现总带宽够而单路画质差。
- 编码能力与网络带宽要分开核算，两者瓶颈常常不在同一处。
- 转发与级联带宽独立预算，不与接入带宽共用。
- 预留 20% 以上余量应对突发码率，超限时优先降分辨率或帧率。
多路场景还要算清单机出口带宽：若同一台设备既向本地 NVR 推流、又向平台转发，两路带宽要分开计入。按 1080p30、4Mbps、16 路估算，接入侧约需 64Mbps，叠加 1.3 倍并发系数后约 83Mbps，千兆网口即可覆盖；一旦升到 4K 或增加转发路数，就要重新核对网口规格与交换机上联能力，相关口径均须以目标网络实测为准。
花屏、卡顿、音画不同步怎么定位？
- 花屏：多为丢包或丢帧导致参考链断裂，先看是否为关键帧丢失，再检查网络丢包与解码错误日志。
- 卡顿：区分编码侧与网络侧，编码侧看单帧耗时是否超过帧间隔，网络侧看抖动与重传；用分段计时定位，不要只看整体。
- 音画不同步：多因音频与视频时间戳管理不一致或缓冲深度不同，检查两路的时间基准与队列深度。
- 首帧慢：常与 GOP 过长、等待关键帧或连接建立耗时有关，缩短 GOP 并优化握手流程可改善。
- 延迟忽高忽低：多为缓冲队列深度与网络抖动叠加所致，先固定队列深度观察曲线，再定位是编码侧还是网络侧波动，避免把网络问题误判为编码问题。
常见问题
- Q1：RK3588 能同时编码几路视频？取决于所选分辨率、帧率、编码格式与并发配置，具体路数上限以原厂官方规格书为准；规划时按像素吞吐折算并预留 20% 余量。
- Q2：低延迟推流优先改哪个参数？先测出各环节耗时，找出占比大的一段；通常先削减编码前的缓冲队列深度，再缩短 GOP 并减少 B 帧与参考帧。
- Q3：RTSP 和 WebRTC 延迟差多少？RTSP 通常在数百毫秒级，WebRTC 可低至百毫秒级或更低，具体受网络与服务端影响，须以实测为准。
- Q4：带宽不够时该先牺牲什么？优先保证帧率与流畅度，其次降分辨率，之后才压码率，避免因过度压缩出现块效应与运动模糊。