RTP诞生记

LiveVideoStack

发布于 2021-07-30 11:55:26

7540

发布于 2021-07-30 11:55:26

文章被收录于专栏：音视频技术

RTP和RTCP是处理所有多媒体传输的重要协议，于1996年1 月在RFC 1889中定义。在本篇文章中，RTP协议的作者之一Ron Frederick将为我们讲述这个如此重要的协议是如何诞生的。

前因

1992年10月，我开始试验Sun VideoPix的图像采集卡，因为我打算基于IP 组播写一个网络视频会议工具。该工具以vat（由LBL开发的音频会议工具）为模型，其中用到了一个类似的轻量级会话协议，可以让用户加入到会议中，在这个过程中，你只需要发送数据到特定的组播组，并观察是否有来自其他组员的流量。

为了使程序能够成功运行，必须在发送视频数据前将它们压缩。我的目标是将数据流压缩到约128 kbps，或者适用于家用ISDN线路的带宽。我还希望即使只用到带宽的一半，视频依然能正常观看，这意味着我要将图片大小和帧频压缩到原来的1/20。最后我终于达到了这个目标，并为其中用到的技术成功申请了专利：US5485212A（远程会议软件视频压缩技术）。

1992年11月初，我在网上发布了视频会议工具nv（Network Video），经过初步的测试，它已经可以用来向全球视频直播部分IETF 11月的会议，来自15个国家的200个子网络能够接收直播，在一周内有大概50~100人通过nv观看视频。

在接下来的几个月里，有三个工作坊和一些小型会议通过nv向互联网直播，三个工作坊包括意大利的NetWorkshop、MCNC Packet Audio and Video workshop和位于瑞典的关于分布式虚拟现实的MultiG workshop。

nv源代码随后在1993年2月公布，3月份我发布了一个基于小波理论压缩方案的新版本nv。5月，我为这个工具添加了彩色视频支持。

用于nv和其他互联网会议工具的网络协议成为了RTC的基础，通过IETF的标准化，首次在RFC 1889-1890中发布，之后在RFC 3550-3551中和其他RFC一起被修订，这些 RFC 涵盖了用于承载特定格式的音频和视频的配置文件。

在接下来的几年中，我继续nv的工作，并把它移植到了许多其他的硬件平台和视频采集工具里。nv成为当时互联网直播会议的主要工具之一，甚至被NASA选中直播航天飞行任务的现场报道。

1994年， nv开始可以支持其他人开发的视频压缩算法，包括硬件压缩方案，如由SunVideo视频采集卡支持的CellB格式。这使得nv可以通过CUSeeMe格式发送视频，并将视频发送给在 Mac 和 PC 上运行 CUSeeMe 的用户。

3.3 beta版本是nv最后一个发布的版本，发布于1994年7月。我当时正在准备4.0alpha版本的发布，并打算将这个版本迁移到RTP协议的第2版上，但我后来转向了其他项目，所以这项工作从未完成过。

nv提供的框架成了Jupiter multi-media MOO项目（此项目属于施乐帕洛阿尔托研究中心）中视频会议的基础，这个项目最后独立出来成立了PlaceWare公司，后来被微软收购。nv也被用于各种硬件视频会议项目，使得这些项目可以通过高带宽以太网和 ATM 网络发送完整的 NTSC 高质量直播视频。

为什么要自己压缩视频？

那个时候我刚开始开发nv，我当时所知道的用于视频会议的系统都是价格昂贵的专业硬件。比如，那个时候Steve Casner用过一款来自BBN的被称为DVC的系统，压缩时需要专业的硬件，解压缩可以在软件中完成。nv的独特之处在于压缩和解压缩都是在软件中完成的，唯一的硬件要求是将输入的模拟视频信号数字化。

许多关于压缩视频的基本概念那个时候已经存在。MPEP-1标准几乎是和nv同一时期出现的，但当时却绝不可能使用MPEP-1进行实时编码。我当时所做的改变是：提取出其中最基本的概念，并使用成本低得多的算法来实现，在这些算法中我避免使用余弦变换和浮点数，甚至整数乘法，因为它们在 SPARC Station上非常慢。为了恢复速度，看起来仍然像视频，我尽量只做加减法、位屏蔽和移位运算。

在nv发布的一两年期间，除了MBONE，其他平台上也出现很多不同的音视频工具，比如Mac上运行的CUSeeMe。显然，流媒体时代已然到来。最后，我让nv可以支持其他音视频工具，有时其他工具也会使用nv的编解码器，这样它们就能在使用我的压缩方案时相互操作。

起草RTP

Steve Deering, IP组播创造者，IPv6首席设计师

当时我们所有人都在做IP 组播的开发工作，并协助创建了MBONE（多播主干网）。Steve Deering（最先开发了IP组播）、Van Jacobson和Steve Casner一起开发了MBONE。Steve Deering和我是斯坦福大学的同学，他毕业以后去了施乐帕洛阿尔托研究中心，我作为实习生曾在那里度过了一个夏天（从事IP组播项目的相关工作），之后又利用课余时间继续在那里工作并最终成为了一名全职员工。Van Jacobson、Steve Casner、Henning Schulzrinne和我是最初创建RTP协议的四位作者。我们正在开发的MBONE使得各种形式的在线协作成为可能，所以我们希望设计一种所有工具都可以使用的网络协议，RTP就此诞生！

RTP趣事

其中一件趣事是，我开发了一版使用IP组播的经典Spacewar游戏。没有任何中央服务器的情况下，多个客户端可以各自运行 Spacewar，并开始广播他们飞船的位置、速度、行驶方向以及所发射的子弹等信息。其他用户也会获取到这些信息并将其在本地渲染，这样他们就能看到彼此的飞船和子弹，当飞船相互撞击或者被子弹击中，就会发生爆炸。我甚至让爆炸后的残骸也“活起来”，去一一击毁其他飞船，有时还会发生一连串的爆炸，哈哈。

在最初的游戏中，我使用模拟矢量图形对其进行了渲染，所以人们可以放大或缩小游戏中的一切。飞船本身是一堆矢量线段，是我邀请我在施乐帕洛阿尔托研究中心的同事们帮忙设计的，所以每个飞船看起来都很不一样。

总的来说，RTP可以传输任何不需要完美有序交付的实时数据流。因此，除了音频和视频，我们还可以创建诸如共享白板之类的东西，甚至还可以让RTP传输文件，尤其是与 IP 组播一起使用时。

试想类似BitTorrent的场景，但你并不需要让所有的数据都是peer to peer的。原始数据发送者可以一次向所有接收者发送组播流，且如果传输过程中发生丢包，任何成功接收数据的一方都可以重传数据。你甚至可以确定重传请求的范围，方便附近的接收者传送数据副本，并且也可以组播给该区域的其他接收者，因为网络传输中的丢包往往意味着下游有一堆客户端在那一点上都错过了相同的数据。

RTP遗憾

对于RTP我并没有什么遗憾。但我知道，人们对RTP最多的抱怨是实现RTCP的复杂性（RTCP是与主要RTP数据流量并行运行的控制协议）。我认为RTP之所以没有被广泛应用多数是因为这种复杂性，尤其是在一些不需要RTCP特性的单播情况下。当网络带宽变得没那么稀缺，拥塞问题也变得容易解决，许多人就通过TCP（后来是HTTP）传输音频和视频，既然这种解决方案已经“足够好”，那RTP就派不上用场了。

遗憾的是，使用TCP或者HTTP传输，意味着多个音视频应用需要向接收对象多次发送相同数据，从带宽的角度来说，这种方式太低效了。我有时会想，如果当初我们能将IP组播推广到更多领域（不仅是科研）该有多好。如果是那样的话，我们能更快看到从有线和广播电视到基于互联网的音视频的转变。