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