搞个IP摄像头在WebRTC里用，你得先搞定媒体网关，把不同的协议给它翻译通顺。媒体网关就像个翻译官，把摄像头说话变成浏览器能懂的“普通话”，再把浏览器发回来的“网络天气预报”给翻译回去给摄像头。要是不做这个翻译，画面很可能就卡成PPT了。市面上主流的IP摄像头，主要用两种方式来输出视频。一种是RTSP/H.264，这在安防圈是标准的“普通话”，经常被用在写字楼、小区和路口的枪机和球机上。还有一种是HTTP/MJPEG，这种常被用在资源有限的地方，比如无人机或小型机器人上。不管是哪种方式，网关都得先听懂它们的方言，再把它们转成WebRTC亲儿子VP8格式，然后打包成DTLS/SRTP给浏览器。 网络其实不是透明管道，它会发RTCP包给网关，提醒它调整码率。好多老旧的IP摄像头只支持AVP模式，没有反馈。如果网关直接把RTCP包丢回去，那就等于对摄像头说“别管我”，结果视频就会卡死在几分钟内。网关必须把这些反馈给吃干抹净，才能真正打通生产链路。Kurento这个媒体服务器就很方便了，它自带“不可知媒体能力”，你只要像搭积木一样放元素、连管线就行了。比如引入一个PlayerEndpoint来做“摄像头捕手”，它能直接支持RTSP/RTP和HTTP/MJPEG格式，不用你操心底层差异；再接上WebRtcEndpoint当“浏览器喇叭”，负责把VP8流灌进WebRTC协议栈，还能终结所有RTCP反馈；最后用Kurento内部自动转码和反馈终结功能把整个流程给打通。搭建好基本通话后，录像、人脸识别、行为分析这些功能也可以顺流而下再接一个Sink就行了，非常方便扩展功能。 怎么把IP摄像头塞进WebRTC里？最近我和几个开发者聊了一下，发现大家都在这个问题上卡住了。其实答案并不简单，底层编解码、网络反馈、丢包恢复这些细节都得考虑到。如果只是简单地把两段协议拼在一起，画面很容易就卡成PPT了。想要缩短从Demo到产品的距离，最稳妥的方式就是借助媒体网关做一次翻译官。图1展示了WebRTC媒体网关在RTSP/H.264-HTTP/MJPEG与WebRTC浏览器之间的通用方案，暗红线代表媒体流，需要适配协议与编解码器，还要终结RTCP反馈，才能让画面跑得动。 现在市面上主流的IP摄像头主要靠两种方言输出视频。一种是RTSP/H.264，这在安防圈是标准的普通话。写字楼、小区和路口的枪机球机几乎清一色都用这套组合。不过这种模式下AVP（无反馈）模式最常见，网关必须自己吞掉RTCP包，否则画面就会因为丢包直接卡死。另一种是HTTP/MJPEG，资源紧缺的时候常选这个。无人机、小型机器人因为CPU、内存预算低而选用这个方案。但这种方式下画质会被JPEG压缩榨干，带宽稍高就会糊成马赛克。不管是哪种方言，网关都要先听懂然后翻译成VP8最后打包成DTLS/SRTP塞给浏览器。 如果只是让媒体流跑起来就万事大吉了吗？当然不是！真实的网络会不断发“天气预报”（RTCP包）给网关告诉它“我快被堵死了，降低码率吧”。多数老旧IP摄像头只支持AVP模式没有反馈。如果网关把RTCP包丢回去相当于对摄像头说“别管我”，结果就是视频几分钟内突然停滞——VP8编码器长时间没收到PLI（关键帧请求）只能硬解码到黑画面。更惨的是REMB包——告诉编码器“我扛不住了，降码率吧”——如果网关不理会丢包会像雪崩一样滚下去最终画面卡成雪花。所以一句话：网关必须把RTCP反馈“吃干抹净”才算真正打通生产链路。 Kurento媒体服务器自带不可知媒体能力开发者只需像搭积木一样放元素连管线剩下转码反馈终结全部自动完成。引入PlayerEndpoint做摄像头捕手它天生支持RTSP/RTP HTTP/MJPEG抓流解包转码统统一手包办你不用关心底层差异接入WebRtcEndpoint当浏览器喇叭它负责把VP8流灌进WebRTC协议栈同时终结所有RTCP反馈收到PLI立刻插关键帧收到REMB立刻降码率最后用Kurento内部自动转码和反馈终结功能把整个流程给打通搭建好基本通话后录像人脸识别行为分析这些功能也可以顺流而下再接一个Sink就行了非常方便扩展功能。