共计 3115 个字符，预计需要花费 8 分钟才能阅读完成。
在以后数字化浪潮下，基于互联网的实时音视频通信曾经成为越来越多互联网利用的标配。得益于互联网基础设施的日趋完善和优良开源解决方案 WebRTC 的呈现，音视频实时通信的开发门槛也升高很多。但音视频利用的技术和工程实现复杂度还是比拟高的，有必要深刻其中搞清楚实现的前因后果。本文基于 webRTC 框架对实时音视频通信的一些要害实现做一些探讨，但其原理是相通的并不局限于 webRTC。
WebRTC 实时音视频通信框架
从它的名字上也能够看出 webRTC 是作为 web 端的实时通信计划提出的，目前在 google 鼎力推动下曾经成为支流浏览器的标配性能。基于图 1 的架构实现信令服务器，web APP 就能够轻松取得音视频通信的能力。
下面的场景只是简略的 P2P(点对点）两方的通信，如果要反对多方通信和克服理论网络环境中各类防火墙的挑战，通常会引入更多的服务器性能单元，比方 MCU（Multipoint Control Unit），SFU（Selective Forwarding Unit）。如图 2，减少了 Media Server 承当 MCU/SFU 等性能，减少 Data Server 承当媒体类的信息交互，这种架构下原来的点对点的去核心构造变成了星状的构造。
通信的单方有三类交互信息，依据信息各自的特点能够有不同的传输方式。其中，signaling plane 信令通道 webRTC 并没有实现，预留好了管制接口。Data plane 和 media plane，webRTC 提供了一套齐备的计划。
信令（signaling plane）：交互协商单方的音视频编解码能力，实现通信链路（data/media plane）建设所必须的信息和参数交互。
数据（data plane）：交互单方非音视频类的信息，个别实时性要求不高。
媒体（media plane)：交互音视频数据，实时性要求高。
三条通信通道各有各的角色，各自实现本人的工作。media plane 的整个链路解决最为简单，实时要求也最高。本文仅就 media plane 的视频流（video）在 SFU 架构下端到端处理过程做一个残缺解剖，参考 webRTC m79 分支做了逻辑形象，对其余非 webRTC 的视频解决零碎也有参考意义。
WebRTC 的视频流要害门路
视频从发送端摄像头采集到接收端显示器渲染，咱们定义为一个端到端的处理过程。接下来形容的过程是典型的精简零碎的处理过程，理论生产线上的处理过程有可能还会多一些额定步骤。一件事件如果能抓住它的主线，那这件事件就不会跑偏。
media plane 的传输通道的协定栈如图 3 所示，ICE（Interactive Connectivity Establishment）用来防火墙穿透和链路连通性监测。DTLS（Datagram Transport Level Security）过程实现密钥的替换，是后续 media 加密的辅助过程，如果不加密能够跳过，浏览器是默认关上加密性能的。在通过 ICE 和 DTLS 两个辅助过程后，media 最终在 (S)RTP/(S)RTCP 之上传输。咱们重点关注在这个媒体信息的传输门路。接下来咱们看一下视频画面是怎么流过端到端的，要害门路如图 4 所示。
依照视频画面的解决程序咱们逐渐看一下每个步骤产生了什么事件
发送方向（采集端 - 媒体服务器）
video capture：webRTC 提供了丰盛的设施治理性能，能够依据摄像头的能力和业务须要订阅不同等级的视频输入，能够管制摄像头输入的分辨率和帧率。
video adapter：视频帧适配器，能够裁剪视频画面，升高 / 升高视频辨率或丢帧以扭转输出到 encoder 的数据量。video adapter 与 encoder 之间会有交互，两者配合能够管制编码器的码率输入。
encoder：编码器，webrtc 应用了 openh264 开源实现。
RTP/RTCP packetizer：组包器，依照 RTP/RTCP 协定标准组包。
Pacer queue：发送队列，组包器输入的 RTP 包放入该队列中期待发送。
Pacer&prober：发包器 & 带宽探测器，发包器依据以后预估的带宽限度，往 Transport 安稳发包。带宽探测器用于探测以后网络带宽下限，探测包的发送跟以后发送的理论无效包速率无关。
Transport：网络传输模块，加密，端口复用等网络传输性能。
接管方向（媒体服务器 - 播放端）
Transport：网络传输模块，解密，de 端口解复用等网络传输性能。
RTP/RTCP depacketizer：解包器，依照 RTP/RTCP 协定标准解包，。
Packet buffer：视频包缓存，和解包器一起负责 RTP 包的乱序和丢包解决。去掉 RTP 包头后，视频包会存入该 buffer，每次来了新包都会查看以后的缓存外面是否曾经能够形成残缺的视频帧，如果残缺则组成残缺帧持续下一步的解决，否则则完结以后包的解决。
Frame queue：帧队列，负责缓存以后待解码的视频帧。
Decoder：解码器，负责视频帧解码。解码的开始机会思考了网络抖动、编码器提早、渲染提早。
Video render：渲染器，视频渲染接口模块。
媒体服务器
媒体服务器的实现不在 webRTC 的范畴内，但也有不少优良的开源实现，比方 Kurento/Jitsi/Janus/Srs/OWT 等。为了更好的服务业务需要，更多的音视频解决方案公司打造本人的媒体服务器，将 webRTC 媒体流引入到本人的媒体解决方案中。以 Kurento 为例，介绍一下 Media server 上的视频流解决。图片起源 https://www.kurento.org/kurento-architecture
Kurento Media Server 的媒体解决流水线是基于 GStreamer 实现的，其模块化和可扩展性做的十分好。一路视频流依据不同的业务需要，可能通过不同复杂程度的解决。列举几类典型的解决流水。
Stream s1：媒体流做了个传输层的路由后间接进来，这时 Media Server 只是做了简略的路由。这也是很有意义的，很多公司的音视频专网或者 SDN 依赖于这样的性能，使得用户能够就近接入到音视频云端服务器。注: 云端的媒体流路由计划很多，media server 集成 route 性能是其中一种形式。
Stream s2：媒体流做了残缺的编解码 - 转码的过程，这个过程对 Media Server 的考验就比拟重了，须要耗费很多计算资源。转码的局部可能是不同编码的转换如 H.265->H.264，也能够是同一 codec 的码率转换。
Stream s3：媒体流绝对 s2 还做了更多的操作，比方图像增强、混流等，甚至更多。
三条流 s1-s2-s3，复杂度逐级在回升，须要哪些解决齐全取决于业务需要。参加解决的服务器节点能够是媒体网关，能够是媒体路由，能够是转码服务器，能够是录制服务器，或者多个性能的叠加。设计正当的架构、优良的功能模块形象与划分，做到性能易扩大、集群易扩容，这是优良架构师的修炼指标。
总结
本文对 webRTC 框架下典型的视频流端到端解决做了一次梳理，对了解相似音视频解决计划多有裨益。音视频的零碎好比咱们的自来水零碎，该文解说了整个处理过程是怎么的，然而输水管道不同段不同工夫有大有小，有的管道有时还漏水，怎么在这样的传输通道上高效的输水？怎么在简单网络条件下的互联网上传输实时要求很高的音视频？webRTC 还有很多法宝，比方拥塞管制、码率自适应、容错机制等等，这些管制模块计算感知以后的传输和计算资源状况（网络、CPU、时延等），实时控制要害门路上的模块做出调整，力求偏心高效的传输音视频。
自己原创文章，首发在 infoq
https://xie.infoq.cn/article/…