历史

历史 #

本节仍在进行中,我们还没有还原全部事实。我们正在进行采访,以修订数字通信的历史。

RTP #

RTP和RTCP是处理WebRTC的所有媒体传输的协议。它是在1996年1月的RFC 1889中定义的。 我们很幸运地邀请一位作者Ron Frederick自己谈论这个问题。 罗恩最近上传了 Network Video tool,一个展示了RTP的项目。

用他自己的话说:

在1992年10月,我开始尝试使用Sun VideoPix帧采集卡,当时的想法是编写一个基于IP多播的网络视频会议工具。它是根据"vat"建模的,“vat"是LBL开发的一个音频会议工具,它为参加会议的用户使用了类似的轻量级会话协议,您可以简单地使用此工具将数据发送到特定的多播组,并监听来自该组中其他小组成员的任何流量。

为了使程序真正成功,它需要先压缩视频数据,然后再将其发布到网络上。我的目标是在大约128 kbps或标准家庭ISDN线路的带宽上生成可接受的可视数据流。我还希望在一半带宽下生成仍能被观看到的东西。这意味着我需要将特定图像尺寸和帧率的视频压缩到大约20分之一的大小。我实现了这种压缩,并申请了专利,专利是 US5485212A:用于电话会议的软件视频压缩。

1992年11月上旬,我向互联网社区发布了视频会议工具"nv”(二进制形式)。经过一些初步测试后,它被用于在全球范围内对11月Internet工程任务组的部分进行视频广播。在15个国家/地区中,大约有200个子网能够接收此广播,并且一周中的某个时候,大约有50-100人使用"nv"接收了视频。

在接下来的几个月中,另外三个研讨会和一些较小的会议使用"nv"向整个Internet进行广播,包括澳大利亚NetWorkshop,MCNC分组音频和视频研讨会以及瑞典的分布式虚拟现实MultiG研讨会。

随后,在1993年2月,我发布了"nv"的源代码,并在3月发布了该工具的一个版本,在其中引入了新的基于小波的压缩方案。在1993年5月,我增加了对彩色视频的支持。

用于"nv"和其他Internet会议工具的网络协议成为了实时传输协议(RTP)的基础,该协议通过Internet工程任务组(IETF)进行了标准化,该工作组首先在RFCs 1889-1890中发布,后来又与其他各种RFC一起,在RFCs 3550-3551中进行了修订,它们涵盖了用于传递特定音频和视频格式的配置文件。

在接下来的几年中,关于"nv"的工作继续进行,该工具被移植到了许多其他硬件平台和视频捕获设备上。它仍然被用作当时在Internet上广播会议的主要工具之一,包括被NASA选中以在线直播的方式进行航天飞机飞行任务的实时报道。

1994年,我在"nv"中添加了对其他人开发的视频压缩算法的支持,其中包括一些硬件压缩方案,如SunVideo视频捕获卡支持的CellB格式。这也使得"nv"可以用CUSeeMe格式发送视频,并将视频发送给在Mac和PC上运行CUSeeMe的用户。

最新的"nv"版本是1994年7月发布的3.3beta版本。当时我正在开发"4.0alpha"版本,该版本旨在将"nv"迁移到RTP协议v2,但因为我转到了其他项目上,这项工作从未被完成。为了保持完整性,Network Video tool归档文件中包含4.0 alpha代码的副本,但它是未完成的,并且存在已知问题,尤其是在RTPv2支持不完整的情况下。

“nv"中提供的框架后来成为Xerox PARC的"Jupiter multi-media MOO"项目中视频会议的基础,该项目最终分拆为独立公司"PlaceWare”,后来该公司被Microsoft收购。它也被用作许多硬件视频会议项目的基础,这些项目允许通过高带宽以太网和ATM网络发送完整的NTSC广播质量的视频。后来我还使用了其中一些代码作为"Mediastore"的基础,“Mediastore"是基于网络的视频记录和回放服务。

您还记得草案中其他人的动机/想法吗?

我们都是IP多播的研究人员,并且帮助创建了Internet多播主干网(又名MBONE)。MBONE由Steve Deering(IP多播的首位开发者),Van Jacobson和Steve Casner创建。 我和Steve Deering在斯坦福大学有同一位顾问,Steve离开斯坦福大学后就去了Xerox PARC工作,我作为IP多播相关项目的实习生在Xerox PARC呆了一个夏天,后来在斯坦福大学还继续为他们兼职工作,再后来转为全职。Van Jacobson和Steve Casner是最初的RTP RFC的四位作者中的两位,还有Henning Schulzrinne和我本人。我们所有人都使用MBONE工具进行各种形式的在线协作,并且试图提炼出所有这些工具可以使用的通用基本协议,RTP就是这样出现的。

多播很棒。而WebRTC完全是单播的,可以说一下是为什么吗?

在前往斯坦福大学并学习IP多播之前,我花了很长时间致力于让计算机成为人们相互交流的方式。这是从80年代初期开始的,当时我运行了一个拨号公告板系统,人们可以登录并留下彼此的消息,既可以是私人的(相当于电子邮件),也可以是公共的(讨论小组)。大约在同一时间,我还了解了在线服务提供商CompuServe。 CompuServe的很酷的功能之一就是所谓的"CB Simulator”,人们可以在其中进行实时交谈。这些都是基于文本的,但是它具有"频道"的概念,就像真正的CB广播一样,只要他们在同一个频道中,大家就可以看到其他人键入的内容。我构建了自己的CB版本,该版本在我可以访问的分时共享系统上运行,该系统可以让该系统上的用户实时向彼此发送消息,然后在接下来的几年中,我与朋友一起开发了更复杂的各种版本的实时通信工具,可以在几个不同的计算机系统和网络上运行。事实上,其中一个系统仍在运行,我每天都会用它与30多年前上大学的人们进行交流!

所有这些工具都是基于文本的,因为当时的计算机通常没有任何音频/视频功能,但是当我到达斯坦福大学并学习了IP多播时,我产生了一个想法。做一个真正的"收音机”,您可以将信号发送到网络上,该信号并不是特别发给任何人的,但是调谐到该"频道"的每个人都可以接收到它。碰巧的是,我正在为之移植IP多播代码的计算机是Sun的第一代SPARC-station,而它实际上内置了电话级别的音频硬件!您可以将麦克风中的声音数字化,然后通过内置扬声器(或通过耳机输出)播放。因此,我的第一个想法是弄清楚如何使用IP多播将音频实时发送到网络上,然后看一下是否可以构建一个使用实际音频而不是文本的"CB收音机”。

这里有一些棘手的事情需要解决,例如计算机一次只能播放一个音频流,因此,如果有多个人在讲话,则需要在数学上将多个音频流"混合"为一个,然后才能播放。不过一旦您了解了音频采样的工作原理,这些工作就可以全部通过软件完成。该音频应用程序使我致力于MBONE的开发,并最终通过"nv"实现了到视频的转换。

协议中遗漏了什么您原本希望添加的东西吗?有没有哪些让您后悔加入的内容?

我不觉得有什么后悔的,不过最终人们对RTP抱怨最多的其中一点就是RTCP实现的复杂性,RTCP是与RTP主数据流量并行运行的控制协议。我认为,RTP并未得到更广泛采用的主要原因就是太过复杂,尤其是在单播情况下,对RTCP的某些功能的需求不再那么大。由于网络带宽变得不再那么稀缺,而拥塞也不再是一个大问题,许多人最终只是通过纯TCP(以及后来的HTTP)流式传输音频和视频,一般来说,这就已经"足够好"了,以至于没有必要再去与RTP打交道。

不幸的是,使用TCP或HTTP意味着多方音频和视频应用程序必须通过网络多次向需要接收数据的每个对等方发送相同的数据,从而从带宽的角度来看,效率被大大降低。有时,我希望我们之前能更加努力地推动IP多点广播的应用,使其不仅限于研究领域。我认为,如果我们这么做了的话,可能我们早就可以看到有线电视和广播电视过渡到基于Internet的音频和视频。

有什么东西是您曾经想过使用RTP构建的呢?是不是有一些很酷的RTP项目/想法随时间流逝了呢?

我构建的其中一个有趣的项目是一个使用IP多播的经典游戏"Spacewar"版本。在没有任何类型的中央服务器的情况下,多个客户端可以各自运行spacewar的二进制文件,并开始广播其船舶的位置/速度/所面对的方向以及已发射的任何"子弹"的类似信息,所有其他客户端将收集这些信息并将其呈现在本地,从而使所有人都可以看到彼此的飞船和子弹,如果飞船撞向对方或被子弹击中,飞船就会"爆炸”。我甚至将爆炸中的"碎片"也做成了可以击毁其他船只的活动物体,有时会引起有趣的连锁反应!

本着原始游戏的精神,我使用模拟矢量图形对其进行了渲染,因此您可以执行诸如放大和缩小视图之类的操作,并且一切都会按比例放大/缩小。飞船本身是一堆矢量形式的线段,我在PARC的一些同事帮助我进行了设计,因此每个人的飞船都有独特的外观。

基本上,如果一个东西需要实时数据流,又无需数据按照精确的时序传输,那么它就可以从RTP中受益。因此,除了音频和视频,我们还可以构建共享白板之类的东西。甚至使用RTP进行文件传输,尤其是与IP多播结合使用时。

这就像BitTorrent,但是您不需要在对等方之间点对点地传输所有数据。原始的做种者可以立即将多播流发送到所有接收者,并且通过成功接收数据的任何对等方的重发,就可以快速解决传输中数据包丢失的问题。接收者甚至可以确定重传请求的范围,以便附近的一些对等方能够传递数据的副本,重传请求也可以被多播到该区域中的其他节点,因为网络中间的数据包丢失往往意味着下游有很多客户端错过了相同的数据。

为什么您必须实现自己的视频压缩协议?当时没有其他可用的东西了吗?

在我开始构建"nv"时,我所知道的唯一进行视频会议的系统是非常昂贵的专用硬件。例如,Steve Casner可以从BBN访问一个名为"DVC”(后来商品化为"PictureWindow”)的系统。压缩需要专用硬件,但是解压缩可以通过软件完成。“nv"之所以与众不同,是因为压缩和解压缩都是在软件中完成的,唯一的硬件要求是对输入的模拟视频信号进行数字化处理。

当时,有关如何压缩视频的许多基本概念已经存在了,诸如MPEG-1标准之类的东西大约在"nv"出现的同时出现,但在当时绝对不可能使用MPEG-1进行实时编码。我所做的更改都是关于吸收这些基本概念并使用更便宜的算法对其进行近似模拟,其中我避免了余弦变换和浮点之类的事情,甚至避免了整数乘法,因为在SPARC-stations上这些运算速度非常慢。我尽量只进行加/减法、位屏蔽和移位,这样可以使速度足够快,并使结果看起来仍像是视频。

在"nv"发布的一两年之内,不仅是在MBONE网络上,还有其他地方(如Mac上的CU-SeeMe工具),都出现了许多不同的音视频工具可供选择。很明显的,实时视频的时机成熟了。事实上,我最终使"nv"与许多这些工具互操作,还有某些工具甚至采用了"nv"编解码器,以便在使用压缩方案时它们可以互操作。

SDP #

ICE #

SRTP #

SCTP #

DTLS #