SRT 解决的是传输可靠性，不是自动降延迟
SRT 适合公网、移动网络和有一定丢包抖动的回传链路。它通过接收缓冲和重传给丢失的数据补救机会，但这段缓冲本身也会增加传输等待。因此，SRT 的设置不是越小越好，也不是把 latency 调大就一定稳定。
项目真正要平衡的是三件事：网络往返时间和抖动、可接受的端到端延迟、编码码率与实际可用带宽。
先确认 Caller、Listener 和网络入口
一端作为 Listener 监听端口，另一端作为 Caller 主动连接。放在公网侧或有固定端口映射的一端通常更适合 Listener；位于复杂 NAT 后的远端设备通常使用 Caller 主动发起连接。
联调前应确认公网地址、监听端口、UDP 放行、容器到宿主的端口映射，以及双方使用的 streamid、passphrase 和传输模式。连接都没有建立时，先解决这些问题，不要提前调整延迟参数。
latency 参数应该怎么起步
SRT latency 是为网络抖动和丢包重传预留的时间，不是摄像头到播放器的最终延迟。可以从当前产品或编码端的稳定默认值开始，在固定码率和固定网络条件下逐步调整。
如果 RTT 较高、抖动明显或重传包经常来不及到达，需要增加 latency；如果网络稳定、用途是远程控制或低延迟监看，可以小幅降低，但每次调整后都要重新观察丢帧和卡顿。StreamGate 当前 SRT 回传示例以 120 ms 作为基础值，实际项目应按目标网络复测。
实时视频应使用 live 传输类型。启用过期包丢弃（如 tlpktdrop）可以避免网络恢复后继续播放大量旧画面，但会牺牲无法及时重传的数据，应结合业务对连续性和实时性的要求决定。
带宽不足时，加大缓冲也解决不了
编码码率长期接近或超过上行可用带宽时，发送队列会持续积压。更大的 latency 只能延后问题，不能创造带宽。弱网回传应为码率预留余量，并控制瞬时峰值、GOP 和音频码率。
测试时不要只看运营商标称带宽。记录持续可用上行、峰值码率、RTT、抖动和丢包，并在业务高峰时段复测。移动网络还要观察小区切换或信号变化后的恢复。
用指标区分丢包、重传和播放卡顿
建议同时观察：
- 发送与接收码率是否稳定，是否长期低于编码输出。
- RTT、丢包数、重传数和来不及恢复的包数。
- 发送队列或接收缓冲是否持续增加。
- 网关收到首包和首个可解码帧的时间。
- 浏览器首帧、卡顿次数、重连时间和稳定阶段延迟漂移。
SRT 统计正常但浏览器仍卡顿时，应继续检查网关转发、转码、播放缓冲和终端解码；不要把整条链路的问题都归到 SRT。
在网关项目里的典型链路
远端编码端可以向 StreamGate 所在服务器的 SRT Listener 推流，网关在本机接入该视频后，再提供浏览器预览、录像、回放和业务系统接口。这样把不稳定的公网回传与内网播放、存储链路分开，排障时也能判断问题位于远端上行、SRT 传输还是网关输出。
一个可复现的调试顺序
- 在同一局域网内先确认 Caller/Listener、地址、端口和 streamid 可用。
- 固定编码分辨率、帧率、码率和 GOP，记录无丢包时的基础延迟。
- 接入目标公网，记录 RTT、抖动、丢包、重传和端到端延迟。
- 一次只调整一个参数，先保证不持续积压，再在稳定性与延迟之间取值。
- 使用真实画面时钟对比源端和播放端，不能把 SRT latency 当成最终结果。
- 连续运行并覆盖网络波动、断网重连和服务重启。
常见误区
把 latency=120 ms 当成端到端延迟。 实际结果还包括采集、编码、网关处理、播放缓冲、解码和显示。
遇到卡顿就不断加大 latency。 如果根因是带宽不足或编码峰值过高，缓冲只会让延迟继续累积。
只测握手成功。 连接成功不能说明长时间重传、网络切换和播放恢复可靠。
只看播放器感受。 没有 RTT、丢包、重传、码率和时钟对比，就很难判断调整是否有效。