实时音视频不只有"视频通话"这一种需求
提到低延迟音视频，很多开发者首先想到WebRTC。
这并不奇怪。WebRTC为浏览器及兼容终端提供了实时音视频通信能力，底层采用SRTP传输媒体，通过ICE寻找可用网络路径，并可借助STUN、TURN解决NAT穿透和中继问题。它同时具备RTCP反馈、拥塞控制、安全传输和数据通道等能力，非常适合视频会议、在线客服、远程协作、互动课堂和多人连麦等场景。
于是，一个看似合理的问题随之出现：
既然WebRTC已经能够实现低延迟、弱网适配和浏览器实时通信，为什么还需要大牛直播SDK（SmartMediaKit）？
问题的关键在于，WebRTC首先是一套实时通信技术体系，而SmartMediaKit是一套面向行业视频系统的模块化SDK底座。两者都处理音视频，却不处于完全相同的产品层次，也不解决完全相同的业务问题。
WebRTC擅长的是"两个或多个实时通信端点如何连接"；SmartMediaKit长期解决的是"摄像头、智能终端、边缘设备和业务平台之间，如何完成采集、播放、录像、转发、国标接入和数据处理"。
因此，有了WebRTC，SmartMediaKit依然具有独立价值。
一、WebRTC解决的是实时通信，行业项目需要的是完整视频系统
WebRTC的技术体系围绕RTCPeerConnection展开，媒体使用RTP/RTCP和SRTP传输，密钥通过DTLS-SRTP建立，网络连接则依赖ICE候选协商。数据通道采用SCTP over DTLS over ICE。它是一套完整而强大的实时通信技术。
但一个真正的行业视频项目，通常还要处理WebRTC本身并不直接提供的业务能力：
- 如何接入IPC、NVR和工业摄像头；
- 如何播放现有RTSP、RTMP或HTTP-FLV视频源；
- 如何让移动终端以GB28181设备身份接入国标平台；
- 如何在播放、推流或转发过程中同步录像；
- 如何拉取RTSP后转推到RTMP服务器；
- 如何在终端本地启动轻量级RTSP服务；
- 如何将解码后的YUV、RGB数据交给AI算法；
- 如何在Windows、Linux、Android、鸿蒙NEXT、iOS、macOS和Unity3D中保持相对一致的能力；
- 如何在无人值守环境下长期运行，并完成异常恢复。
SmartMediaKit官方产品矩阵正是围绕这些需求构建，覆盖RTMP推流、RTSP/RTMP/HTTP-FLV低延迟播放、轻量级RTSP服务、多路流媒体转发、GB28181接入、录像、SEI数据和AI分析接入等模块。
所以，两者最根本的区别不是延迟高低，而是产品边界不同：
二、有了WebRTC，摄像头依然不会自动变成WebRTC设备
在智慧安防、工业监控、园区管理和视频巡检中，大量现有视频源来自IPC、NVR、编码器、工业相机和边缘网关。
这些设备通常输出RTSP视频流，行业平台则可能使用GB28181接入；一些直播服务器和业务平台使用RTMP或HTTP-FLV。SmartMediaKit重点覆盖这些已经广泛存在的设备和平台协议，便于原生应用直接接入现有视频基础设施。
如果业务系统只支持WebRTC，就需要在设备和观看端之间增加协议网关：
IPC、NVR、工业摄像头
↓ RTSP
协议接入与媒体处理网关
↓ WebRTC
浏览器或WebRTC客户端网关仍然要完成RTSP会话管理、RTP接收、H.264/H.265处理、时间戳转换、关键帧识别、音视频同步、异常恢复以及必要的转码。
换句话说，WebRTC可以解决最后一段实时分发，却不会让设备侧原有协议生态自然消失。
SmartMediaKit的价值正是在于，它能够先把真实设备的视频稳定接入系统，再根据业务需求决定视频是本地播放、录像、转发、AI分析，还是进一步转换给其他平台。
在很多项目中，最先需要解决的并不是"浏览器之间怎样通话"，而是：
现有摄像头的视频，怎样低延迟、稳定地进入业务系统？
这是SmartMediaKit长期投入的方向。
三、低延迟不是协议标签，而是完整媒体链路的结果
WebRTC常被视为低延迟技术，但系统最终延迟并不只由传输协议决定。
一条完整视频链路通常包括：
如果摄像头使用较长GOP，编码端缓存过多，服务器发生排队，播放器设置了较大的缓冲区，或者解码渲染链路积压，即使传输协议本身很快，端到端延迟依然可能很高。
SmartMediaKit的低延迟能力并不是简单地"使用UDP"，而是围绕拉流、缓冲、解码、同步、渲染和异常恢复进行整体优化。其官方资料给出的典型场景延迟体验为约100～200毫秒，但实际结果仍取决于网络、码流、服务器链路和终端性能。
以RTSP播放器为例，业务可以根据环境选择TCP、UDP或自动模式：
- 稳定局域网和专网可以优先考虑UDP，减少重传等待；
- 对完整性要求较高或存在一定丢包的网络，可以选择TCP；
- 播放器侧还需要处理缓冲控制、延迟追赶、关键帧恢复、断线重连和异常码流。
WebRTC在NACK、RTCP反馈、拥塞控制和公网连接方面具有体系化优势。WebRTC媒体端点必须使用RTP和RTCP，并要求实现相应的安全传输与网络反馈机制。
但这并不意味着所有低延迟视频系统都必须采用WebRTC。
在局域网摄像头预览、工业设备直连、车载内网视频、机器人局部网络和专网指挥等场景中，经过优化的RTSP或RTMP链路同样可以获得良好的低延迟体验，而且更容易与现有设备和平台直接对接。
Android平台RTMP直播播放器功能与时延测试
四、WebRTC的优势是弱网互动，SmartMediaKit的优势是媒体链路可控
必须承认，WebRTC在复杂公网和互动通信场景中具有明显优势。
ICE能够在不同网络拓扑下寻找候选路径，并在直连失败时使用TURN中继；WebRTC媒体使用安全RTP传输，同时要求拥塞控制和RTCP反馈。这使其特别适合互联网用户之间的音视频互动。
但行业系统通常还有另一个重要要求：媒体数据必须可控。
所谓可控，不仅是能看到画面，还包括：
- 可以获得解码前的H.264、H.265数据；
- 可以获得解码后的YUV、RGB数据；
- 可以独立控制软解码和硬解码；
- 可以进行播放端录像；
- 可以进行推流端录像；
- 可以进行转发过程录像；
- 可以独立截图；
- 可以提取SEI扩展数据；
- 可以对接YOLO等AI算法；
- 可以根据业务状态动态开启或停止模块；
- 可以把同一套采集编码数据同时用于推流、RTSP服务和录像。
SmartMediaKit官方资料明确提供编码前后数据回调，并支持推送端、播放端录像、多路流媒体转发和轻量级RTSP服务等能力。
这类能力对于传统互动通话可能不是重点，但对于工业、安防、执法、机器人和AI视觉项目却非常关键。
客户真正需要的往往不是一个黑盒式视频连接，而是一条能够被业务系统读取、控制、组合和扩展的媒体管线。
HarmonyOS鸿蒙NEXT下RTMP播放器时延测试
五、录像、转发和GB28181，是WebRTC无法替代的业务纵深
1. 录像不是"顺便录一下"
在移动执法、金融双录、工业生产、应急指挥和安全巡检中，录像具有取证、复盘和责任追溯价值。
录像系统需要考虑：
- 音视频时间戳；
- 文件切片；
- 编码格式兼容；
- 异常中断后的文件完整性；
- 纯音频或纯视频；
- 转码与不转码；
- 新文件和完成事件回调；
- 长时间运行稳定性。
SmartMediaKit将录像设计成可以与播放、推流、转发和国标接入组合的独立模块，而不是简单依赖浏览器端MediaRecorder。其官方产品体系把录像和快照作为完整行业视频链路的重要组成部分。
2. 后台转发不是视频会议
大量项目需要完成：
RTSP摄像头
↓
拉流与编码数据回调
↓
RTMP转推
↓
云平台或私有直播服务器或者：
多路RTSP、RTMP视频源
↓
边缘节点汇聚
↓
录像、转发和AI分析
↓
中心业务平台这类系统强调多实例、低资源占用、时间戳连续性、协议转换和长期无人值守运行，并不需要会议房间、用户呼叫和多人互动。
SmartMediaKit官方资料显示，其转发模块支持拉取RTSP、RTMP视频并转推到RTMP服务器，并可与录像等模块组合。
3. 行业平台仍然需要GB28181
在安防监控、移动执法、车载终端、无人机巡检和应急指挥中，终端可能需要以GB28181设备身份接入现有平台，完成注册、心跳、目录上报、实时点播、媒体传输和语音广播等流程。
SmartMediaKit在鸿蒙NEXT等平台提供GB28181设备接入能力，并可与RTMP推流、轻量级RTSP服务和本地录像组合运行。
WebRTC并不能替代国标平台现有的SIP信令、PS封装和RTP媒体接入体系。
RTSP/RTMP直播播放器预录回放：事件前后片段完整保存
六、跨平台原生能力，是SmartMediaKit的重要护城河
WebRTC天然适合浏览器，也广泛支持Android和iOS。但很多行业项目并不是纯Web应用。
客户可能需要在以下环境中运行：
- Windows桌面客户端；
- Linux x86_64或ARM边缘设备；
- Android智能终端；
- 鸿蒙NEXT原生应用；
- iOS和macOS；
- Unity3D数字孪生平台；
- 国产化CPU、操作系统和GPU环境。
SmartMediaKit官方产品体系覆盖Windows、Linux、Android、鸿蒙NEXT、iOS、macOS和Unity3D，并强调跨平台统一媒体内核和模块组合。
跨平台真正困难的部分，也不是把接口编译通过，而是处理：
- 不同平台的摄像头和屏幕采集；
- MediaCodec、VideoToolbox、D3D、OpenGL和Surface渲染；
- 软硬编解码器差异；
- 应用生命周期；
- Surface或Texture切换；
- 多实例资源调度；
- 国产化环境适配；
- 长时间运行中的资源释放与异常恢复。
这些能力并不会因为采用WebRTC而自动完成。
对于需要深度嵌入原生应用、硬件设备和三维可视化系统的客户而言，专业跨平台媒体SDK仍然具有现实价值。
七、SmartMediaKit更适合哪些场景
智慧安防与视频监控
典型链路是IPC、NVR或边缘网关输出RTSP，客户端需要低延迟多路播放、录像、快照和AI分析，部分视频还需要接入GB28181平台。
这类项目优先考虑的是设备兼容、多路资源占用、录像取证和国标对接，而不是浏览器互动。
推荐模块：
RTSP播放 + 多实例 + 录像快照
+ AI数据回调 + GB28181工业巡检与工业视觉
工业项目通常需要接入设备视频，将解码帧交给AI模型，同时保留人工低延迟预览和异常录像。
推荐链路：
RTSP视频源
↓
SmartMediaKit低延迟播放
↓
YUV/RGB数据回调
↓
YOLO或行业视觉模型
↓
告警、录像和设备联动无人机、机器人与车载终端
这些系统需要原生端采集、编码、视频回传、本地预览、边缘转发和录像。部分项目运行在局域网或专网，部分项目需要进入GB28181指挥平台。
推荐模块：
采集编码 + RTMP推流
+ 轻量级RTSP服务
+ 低延迟播放
+ 本地录像或GB28181应急指挥与移动执法
同一终端可能同时承担视频采集、国标上报、局域网分发、云端推流和本地录像。
SmartMediaKit鸿蒙NEXT方案展示了这种多模块复用同一采集编码链路的设计：RTMP推流、轻量级RTSP服务和录像可并行工作，并可结合GB28181接入。
Unity3D与数字孪生
Unity3D项目需要把实时视频嵌入三维场景，并处理Texture渲染、多路视频、视频数据回调和不同操作系统适配。
这类业务通常更需要原生播放器SDK，而不是直接把浏览器WebRTC组件嵌入三维引擎。
八、WebRTC与SmartMediaKit不是二选一，而是可以组合
在复杂项目中，最合理的方案往往不是只选择一种协议，而是分层使用。
例如，一个智慧安防系统可以采用：
IPC、NVR、机器人、移动终端
↓ RTSP / RTMP / GB28181
SmartMediaKit设备接入与媒体处理
↓
播放 / 录像 / 转发 / AI分析
↓
WebRTC或WHEP网关
↓
浏览器低延迟观看在这套架构中：
- SmartMediaKit负责设备视频接入；
- SmartMediaKit负责解码、录像、转发和AI数据输出；
- WebRTC负责最后一公里浏览器低延迟观看；
- 需要公网互动时，再发挥ICE、STUN、TURN和拥塞控制的优势。
这不是重复建设，而是让不同技术各自承担最擅长的部分。
SmartMediaKit官方将产品定位为"做底座不做平台"，强调让客户能够基于SDK构建自己的业务系统。
从这一角度看，WebRTC完全可以成为SmartMediaKit未来可接入的一种传输出口，却没有必要替代SmartMediaKit已有的媒体底座。
九、有了WebRTC，为什么还需要SmartMediaKit
可以用一张表概括：
| 对比维度 | WebRTC | SmartMediaKit |
|---|---|---|
| 核心定位 | 实时通信技术体系 | 行业实时视频SDK底座 |
| 典型场景 | 会议、连麦、客服、浏览器互动 | 安防、工业、机器人、应急、教育、设备视频 |
| 网络能力 | ICE、STUN、TURN、拥塞控制 | TCP/UDP选择、低延迟缓冲、重连、追赶与异常恢复 |
| 设备协议 | 需要设备或网关转换 | RTSP、RTMP、HTTP-FLV、GB28181 |
| 浏览器能力 | 强 | 主要面向原生端和设备端 |
| 录像取证 | 需业务额外实现 | 播放、推流、转发等链路可组合录像 |
| 后台转发 | 需要SFU或媒体服务器 | 提供RTSP/RTMP转发模块 |
| AI数据接口 | 视具体实现而定 | YUV、RGB及编码数据回调 |
| 国标接入 | 不覆盖 | 支持GB28181设备接入 |
| 部署形态 | 浏览器、App、RTC服务器 | App、终端设备、边缘网关、私有化平台 |
| 产品边界 | 实时连接与互动 | 从采集到业务联动的完整媒体链路 |
WebRTC解决的问题非常重要，但它并不能自动完成行业系统中的设备接入、录像、转发、国标、AI和原生跨平台适配。
SmartMediaKit的价值，不是证明WebRTC没有用，而是补上WebRTC之外的大量行业工程能力。
结语：行业需要的不是"唯一协议"，而是合适的技术组合
WebRTC是一套优秀的实时通信技术。
它在浏览器互动、复杂公网连接、NAT穿透、弱网反馈和安全传输方面具有明显优势。对于多人会议、视频客服、在线课堂和互联网实时互动，WebRTC通常是更自然的选择。
但实时音视频行业远不止视频通话。
大量项目面对的是IPC、NVR、工业相机、机器人、无人机、车载设备、鸿蒙终端和GB28181平台。它们需要的不只是把音视频从A点传到B点，还需要低延迟预览、录像取证、多路转发、数据回调、AI分析、设备控制、跨平台适配和私有化部署。
这正是SmartMediaKit存在的意义。
WebRTC更擅长解决"如何建立实时连接"，SmartMediaKit更擅长解决"如何构建完整、可控、可落地的行业视频链路"。
未来两者并不会简单地谁取代谁。更现实的发展方向，是让SmartMediaKit继续负责设备端、边缘端和原生端的媒体能力，再根据项目需要接入WebRTC、WHEP或其他浏览器低延迟出口。
因此，有了WebRTC，仍然需要SmartMediaKit。
因为客户最终需要的，从来不只是一个协议，而是一套能够真正上线、长期运行、深度嵌入业务系统的实时视频能力。
📎 CSDN官方博客：音视频牛哥-CSDN博客