安防监控和云值守为什么是两套技术栈？RTSP/HLS 与 RTC 的边界
内容提要
看画面与喊话是两类业务：看画面用HLS等CDN分发，成本优先；喊话须走RTC，延迟优先。TCP重传导致队头阻塞，延迟随丢包非线性上升，不适合喊话。HLS、HTTP-FLV为单向，无反向音频通道。实际项目常两套并存，仅对喊话那路补RTC。纯看画面、无强实时联动时，继续用HLS更经济。
延伸解读
延迟与成本：两种业务的不同优先级
文章指出，看画面是单向分发，核心指标是并发成本，延迟可以换取更低的成本和更高的并发；喊话是双向对话，核心指标是闭环延迟，300毫秒是分水岭，超过500毫秒沟通就会失败。因此，两类业务对延迟的敏感度截然不同，这决定了两套技术栈的分工。
TCP队头阻塞：为什么丢包时延迟非线性上升
HLS和HTTP-FLV基于TCP，TCP通过重传保证可靠，但按序交付导致队头阻塞：一个包丢失，后续包必须等待，延迟随丢包率非线性上升。这对看画面可以忍受，但对喊话是致命的，声音被憋住几秒再放出，沟通直接失败。
双向能力：HLS/HTTP-FLV的结构性缺失
文章强调，HLS和HTTP-FLV在设计上就是单向的，没有反向音频通道。因此，现有流媒体平台无法通过加配置实现喊话，这是结构性的不能。RTC则支持双向音频与信令通道，适合喊话和强实时联动。
何时不需要RTC：继续用HLS更经济
如果业务是纯看画面、无喊话需求、无强实时联动，或者并发规模不大且团队缺乏音视频人力，继续用HLS是更经济的选择。引入RTC意味着增加网关、鉴权、质量监控等长期维护成本，存量设备接入也可能带来额外工作量和风险。
Q&A
为什么安防监控和云值守需要两套不同的技术栈？
因为看画面和喊话是两类不同的业务：看画面是单向分发，成本优先，适合用HLS等CDN分发；喊话是双向对话，延迟优先，必须走RTC。两套技术栈的最优解不同，因此并存是常态。
HLS和RTC在延迟和丢包表现上有什么关键区别？
HLS基于TCP，延迟为秒级，丢包时因队头阻塞导致延迟非线性上升，出现重缓冲；RTC基于UDP私有协议，延迟可低至200ms，采用丢包对抗和带宽自适应，优先保连续。
为什么HLS和HTTP-FLV不能用于喊话？
因为HLS和HTTP-FLV在设计上是单向分发，没有反向音频通道，无法传输坐席的语音到现场。喊话需要双向音频与信令通道，这是结构性的不支持，不是配置能解决的。
实际项目中如何同时使用HLS和RTC？
通常同一路摄像头视频仍接入原有流媒体平台用于大屏轮播、多人巡览和事后调阅；当坐席需要对某点位喊话时，该路流通过网关转换协议（如RTSP/GB28181转RTC）切到RTC通道，保证所见与所说同源。
什么情况下不需要引入RTC？
如果业务是纯看画面无喊话需求、无强实时联动需求、并发规模不大且团队无音视频人力、或存量设备接入是主要矛盾，继续用HLS更经济省事。
RTSP和RTC在传输层有什么本质区别？
RTSP本身是控制协议，通常承载在TCP上，延迟与HLS同属秒级；RTC走基于UDP的自研私有协议，用丢包对抗换低延迟。这是传输层假设的不同，不是调优差距。
GB28181的延迟为什么降不下来？
GB28181解决的是设备接入与信令互通，不是传输优化。链路延迟仍取决于设备侧实现和承载网络，各厂商固件差异大，表现参差。真正的低延迟需要在传输层解决。
两套通道并存，成本会翻倍吗？
不会。多数项目复用同一路视频源，只把RTC补在需要喊话的那一路上，视频仍走原平台分发。增加的是那一路的成本，不是整条链路重建。
