注意：本文仅代表作者个人观点，与所属机构无关。
多点视频通讯的发展时间轴（Alex Eleftheriadis)
前几天，我的好友 Alex Gouaillard 发了一条关于 2014 年 WebRTC 先锋奖的推特。
在美国佐治亚州亚特兰大举办的 WebRTC Conference & Expo IV 一共有 64 位获奖者，我是其中之一，而且颁奖那天正好是我的生日，让我特别开心。
对大多数人而言，WebRTC 可能只是个毫无意义的缩写，但它是能让 web 浏览器发送并接收音视频的重要软件。WebRTC 以万维网（W3C）和互联网工程工作小组（IETF）制定的标准为基础，把浏览器作为视频会议的终端。用户只需连接一个摄像头和一个麦克风（目前大部分电脑和平板都自带摄像头和麦克风）就可以通过浏览器进行视频会议。
看到 Alex 的推特时，我突然意识到我们太幸运了，因为通讯技术和基础架构已经为新冠疫情做好了准备。我手机上能进行视频或音频通话的应用有 15 个，而且这 15 个应用都支持多点通信。只要有电脑，任何人都能使用 Zoom、Skype、WebEx、Teams、Hangouts、Vidyo 等应用。而且这些应用都非常好用，有的甚至还免费。
如果疫情发生在 10 年前，人们的沟通会严重受限。我们今天能使用这么多视频聊天应用，是从 20 世纪 70 年代末开始刻苦研究和开发的结果。当人们庆祝医学研究带来的惊人成果，惊讶于基于 mRNA 的疫苗的高效生产和运输时，大多数人并没意识到即时通讯在其中发挥的重要作用，所以我打算在本文探讨这些内容。
早在 2014 年，为了第五届 WebRTC Conference ＆ Expo （圣何塞）上的主题演讲，我做了一些历史研究。我想列出多点视频通信各个关键创新的时间点，我一共用了两张幻灯片画了一个时间轴，时间轴上有近 50 个条目。本文缩小了范围，只探讨其中的七大创新。
视频问题
视频实时通讯的核心是常规清晰度，相机拍摄普通清晰度的原始数据视频需要 120 兆比特/秒的速率，如果想要更高分辨率的视频（高清及以上），就需要比 120 高几倍以上的速率，这会导致视频过大而无法传输或存储。通过多年的努力，人们已经开发出了在不影响视觉效果的前提下，将速率减少几个数量级的技术——压缩。压缩是通过软件或定制芯片中的“编码器”完成的，将压缩后的数据集存储或传输，达到目的地后，通过“解码器”将其转换为原来格式，再通过软件或芯片进行播放。我们编码器和解码器统称为“编解码器”。
如果 Netflix 想在其系统中播放电影，就必须先进行编码和存储。当用户想看电影时，系统就会把电影从服务器传输（推流）到终端（如计算机、平板、Apple TV、智能 TV 等），然后，解码器会将接收的压缩电影解压并呈现在用户的设备屏幕上。
实时通讯与观看电影是不同的。在两个或多人音视频通话中，有另外一个限制因素：延迟。为保证通话质量，语音传输的端到端延时必须小于 180 毫秒（数字越小越好），这最早是长途电话的标准。而在看电影时，用户不介意在播放正式开始前等一两秒钟。因为要实现低延迟，而且视频是实时编码且无法预存，所以实时通讯与推流的环境大不相同。尽管两者都是视频传输应用，但工具、架构甚至商业模型都完全不同。
发展早期
早在 1978 年，R. D. Widergren、W. H. Chen、S. C. Fralick 和 A. G. Tescher （Andy Tescher 至今仍活跃在视频编码标准化领域！）授予压缩实验室一项专利（美国专利号 4,302,775）。该专利这样描述速率控制：如何将每秒产生可变比特数的视频编码器与每秒传输固定比特数的频道连接起来。速率控制类似于汽车的油门，可以控制行驶速度。
此外，还需要一个良好的引擎，通过所谓的混合编解码器来实现。混合编解码器首次出现在 1981 年 Jain 和 Jain 发表在 IEEE Trans 上的论文中描述的“位移测量及其在帧间图像编码中的应用”，使用的是一种基于块的运动估计与变换编码的技术，这项技术是目前所有与商业相关的视频编解码器的基础。随着每代编解码器的更新，不同的块变得更加复杂，但整体块的结构没有变化。
这两项创新从此打开了主要商业应用市场：由 Brian Hinman、Jerefrey Bernstein 和 David Staelin 于 1984 年创立的 PictureTel。有趣的是，希腊裔的麻省理工学院教授 Michael Dertouzos （已故）和他当时的研究生格雷格·帕帕多普洛斯（Greg Papadopoulos）和理查德·索利（Richard Soley）都是初创团队的一员。
PictureTel 以 C-2000 视频编码器和解码器起家，面向当时的高速数据连接 ISDN 频道，创造了一系列产品，但最终在 2001 年 10 月被 Polycom 收购，Polycom 随后于 2018 年被 Plantronics 收购，合并为现在的 Poly。
起步阶段——多点视频
最初，PictureTel 的设计旨在点对点连接。尽管 PictureTel 开发了几个支持多个参与者的设计，但业内普遍采用的设计是 M. H. Willebeek-LeMair、D. D. Kandlur 和 Z. Y. Shae （ 1994 年 1 月本地计算机网络第 19 次会议）撰写的 On Multipoint Control Units for Videoconferencing 论文中描述的设计。
该设计就是的转码多点控制单元或 MCU，其工作原理如下：多点会议中的所有参与者都对其视频进行编码，然后传输到 MCU。MCU 将传入的视频解码、缩放、并将视频按照指定的布局放置在集成的视频帧中，然后对获得的视频编码，将其传回给所有参与者。更复杂的 MCU 会为每个参与者创建自定义布局并编码，这个设计运行顺畅，在 2011 年之前（详见下文）一直是所有多点系统的基础。
MCU 设计的主要短板是需要强大的处理能力。传入视频后，MCU 必须对传入的视频先进行解码再重新编码。另外，个性化布局功能需要为每个参与者单独编码，所以，MCU 的成本高达几万甚至几十万美元，且只能支持有限的参与者（通常少于 32 人）。
网上视频
最初，视频实时通讯需要专门的端点：放置在会议室并且连接一个或多个显示器和摄像头的盒子。MCU 的成本很高，再加上购买运行完整系统的成本，视频会议服务成为了商业奢侈品。总成本的很大一部分是用于站点之间的连接——站点之间通信链接的建立和月租费用，再把视频质量考虑在内，光是每月提供特殊通信线路的费用都要数千美元。
到 20 世纪 90 代后期，随着万维网的发展，互联网成为了全球首选的通信平台，在互联网上传输音频和视频只是时间问题。其实，1992-1994 年我在哥伦比亚大学进行博士研究期间就建立了一个名为 Xphone 的系统（点击这里下载代码）。
1996 年 1 月，我当时在哥伦比亚的同事 Henning Schulzrinne 和 Stephen Casner、Ron Frederick 和 Van Jacobson 共同发布了实时协议（RTP）的第一个规范（“RTP: A Transport Protocol for Real-Time Applications,” RFC 3550）。
RTP 介绍了如何从音频或视频编码器（或任何其他实时推流）提取比特，并将其放入数据包中，以便在 IP 网络上传输。它还可以传送定时信息，这是正确回放以及同步多媒体信息的关键。RTP 允许用户使用单个网络来传输视听数据和通用计算数据，使基于网络的视听通信应用更具性价比。从那时起，RTP 就被用于所有基于网络的音频或视频通信应用，包括 VoIP 电话（互联网连接的电话，不是老式的铜基电报）。
实时视频的起步并不是非常成功。只要人们在 RTP 上部署实时视频，IP（和 RTP）的损耗特性所带来的问题就暴露无遗。不同于损失很少的其他数字网络（如 ISDN），IP 网络的尽力传送以及基于数据包的特性给网络环境带来了巨大的挑战，经常遇到高达 20％ 的突发损失，而视频编码和传输机制尚不足以解决这些问题，导致最终呈现出来的视频不完整、卡顿且充满严重的块状伪像。
另外，用于视频会议的终端也开始发生变化。普通计算机也可以运行视频编码和解码的应用程序。2007 年推出的 iPhone 和 2010 年推出的 iPad 为终端用户提供了高质量的显示屏和强大计算能力。业内开始采用统一通信（UC）来指代电话、Web 和视频会议、台式机和应用程序共享等的融合。在终端和网络不断发展的同时，多点视频仍依赖于老式的转码 MCU。
因此，我们迫切需要一款适应网络需求的新设计。
多点视频的正确打开方式
2005 年，Ofer Shapiro、Avery More 和我创立了 Vidyo（于 2019 年被 Enghouse 收购），目标是引入多点视频的新架构。该架构可以同时解决差错复原和服务器复杂性的问题，并且这种架构是基于两项创新：可扩展视频编码和所谓的选择转发服务器。
可扩展视频编码是指在时间和空间维度上以多种分辨率创建视频信号的多种编码版本。举例来说，无论是 1080p（高清）还是 720p（标准电视）的视频，编码器都可以以每秒 60 帧和每秒 30 帧的速度进行编码，开发者只需选择与所需分辨率对应的组件（比特组），无需进行任何处理就能提取较低分辨率版本的信号。还有一个好处是，通过 Vidyo 引入的重传技术可以使信号以极高的稳健性进行传输，避免视频损坏或失真。
对可扩展编码的编解码器的支持始于 2007 年的 H.264 标准，之后的视频编码标准（H.265，VP9，H.266，AV1）都是在此基础上的扩展。误差鲁棒性技术（error robustness）也都相应获得了视频传输标准的支持。
现在的服务器充分利用了所有参与者传入的视频信号的可扩展编码，我们能够用所谓的选择性转发单元或 SFU 来代替转码 MCU。这种新服务器体系架构的运行原理为: 所有参与者都将其可扩展编码视频发送到 SFU，SFU 只需根据每个参与者需要接收的内容（即参与者想看的具体参与者和分辨率），从传入视频中选择相关的视频数据包，并转发给该参与者就可以了。这就是该产品被称为“VidyoRouter”的原因。
低延迟
SFU 架构的直接好处在于能很大程度减少延迟。MCU 可能会导致大约 150-200 毫秒的延迟，而 SFU 在绝大多数数据包的操作延迟都小于 10 毫秒，这能大大提高用户的使用体验。就算有几十个用户，也照样可以进行交互式视频会议。其实，低延迟是让终端用户忽略科技的缺点的关键：只有延迟足够低，用户才不会在长时间视频会议中感到疲倦，也不会像之前那样在等待对方回应的沉默中尴尬。
可扩展
SFU 的最大优点大概是服务器不需要进行信号处理。成本在几千美元的标准服务器就可以实现 SFU，且每台服务器可以支持数百个同时在线用户，专门的 MCU 最多只能同时支持 32 个用户，但价格却比它高出近 100 倍，所以 SFU 非常适合目前在所有计算机应用中占主导地位的公共云服务。
网络准备
与传统的视频会议终端不同，新架构的接收端点能接收多个视频信号。它可以对视频信号逐一解码，然后在用户屏幕上合成。 这与使用 MCU 的传统视频会议系统是不同的（MCU 的合成是在 MCU 上完成的）。SFU 方法与 Web 服务器和浏览器交互的方式类似：浏览器从不同的 Web 服务器获取内容，然后在用户的显示器上执行合成。这能为服务器省去很多不必要的操作，还能为上千位用户提供服务，这是让 web 快速扩展的关键原因，SFU 设计将这种架构带入了多点视频通信领域。
Vidyo 于 2008 年推出了第一款产品。
截止到 2011 年，所有多点供应商都采用了这种架构或其变体。微软在 Lync 2013 中使用了这一架构，Lync 2013 随后与 Skype 合并，最后成为 Teams。
2012 年 9 月，Radvision 在其 SCOPIA Elite 5000 系列中加入了可扩展编码。
2012 年 10 月，Polycom 提供了免版税的可扩展视频编码。
2013 年 5 月，谷歌使用该设计创建了群聊，即现在的 Google Meet。埃里克·袁（Eric Yuan）在 2011 年创立的 Zoom 于 2013 年推出了首款产品，也使用了同样的运作方式。Emil Ivov 创立的的开源多点视频会议项目 Jitsi 在 2013 年推出了其首个 VideoBridge SFU（Jitsi 在 2015 年被 Atlassian 收购，随后在 2018 年被 8x8 收购）。
浏览器中的视频
至此，我们似乎万事皆备：我们拥有可扩展编码的编码工具，这些编码工具无需处理即可进行信号处理，我们还有配备了 SFU 的服务器架构以及基于云的服务的强大部署机制。
但是还是有一些棘手的细节：用户每使用一个视频通信服务，就必须下载一个软件客户端。这虽然比必须购买不同的硬件来使用服务好了很多，但是仍然被许多用户诟病。最理想的状态是直接从其网络浏览器加入任何会议，无需下载任何内容，而这正是谷歌于 2011 年 5 月启动的 WebRTC 项目想要解决的问题。
WebRTC 是开放源代码软件，提供所有必要的频道，允许 Web 浏览器（或任何应用）直接从计算机上获取视频和音频，对其进行编码并通过网络发送。同时，它可以接收多个视频和音频推流并将其混合以进行播放或显示。WebRTC 公开了 W3C 定义的一组 JavaScript API，允许应用程序员对其进行控制。媒体传输是使用 IETF 定义的标准化通信协议执行的，而信令（如何在各方之间建立连接）则完全由程序员控制。
WebRTC 在过去的 9 年中有了相当不错的发展，所有主流浏览器的主流操作系统上都支持 WebRTC。虽然有的浏览器不支持其某些功能，但是都支持其基本功能。最有趣的是，WebRTC 经常被嵌入在根本不使用网络浏览器的应用程序中。目前，有数十亿个终端是用 WebRTC 构建的，它已经成为实时视频和音频最常用的软件堆栈。
Messenger 和 Instagram 等应用程序中的 Facebook 音频和视频通信频道都是使用 WebRTC 堆栈构建的，可以想见 WebRTC 使用范围到底有多大。就在几天前，Facebook 刚宣布要进行彻底改写以使其更高效（“为我们应用提供更小更快的视频通话库”，2020 年 12 月 21 日）。
视频和新冠疫情
快进到 2020 年 3 月：疫情的蔓延迫使很多人远程工作，学校也不得不转向远程学习，于是大家都被迫开始学习使用各种音频和视频通信软件。而大多数供应商只需要扩展其后端基础架构就能满足不断增长的需求，虽然扩展绝非易事，但他们不用重新设计系统了，因此可以非常快速地做出响应。
因此，当大家在使用 Zoom、WebEx、Teams、Skype、Messenger、Meet、Vidyo 或其他视频电话应用时，当你们看到亲人或同事的笑容时，不妨停下来思考一下：是什么让这一切如此简单。
原文作者：Alex Eleftheriadis
原文链接：https://www.linkedin.com/pulse/video-communications-covid-19-why-battle-won-alex-eleftheriadis/ 1
