RTP和RTCP是處理所有多媒體傳輸的重要協議，于1996年1 月在RFC 1889中定義。在本篇文章中，RTP協議的作者之一Ron Frederick將為我們講述這個如此重要的協議是如何誕生的。

01

—

前因

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 高質量直播視頻。

02

—

為什么要自己壓縮視頻？

那個時候我剛開始開發nv，我當時所知道的用于視頻會議的系統都是價格昂貴的專業硬件。比如，那個時候Steve Casner用過一款來自BBN的被稱為DVC的系統，壓縮時需要專業的硬件，解壓縮可以在軟件中完成。nv的獨特之處在于壓縮和解壓縮都是在軟件中完成的，唯一的硬件要求是將輸入的模擬視頻信號數字化。

許多關于壓縮視頻的基本概念那個時候已經存在。MPEP-1標準幾乎是和nv同一時期出現的，但當時卻絕不可能使用MPEP-1進行實時編碼。我當時所做的改變是：提取出其中最基本的概念，并使用成本低得多的算法來實現，在這些算法中我避免使用余弦變換和浮點數，甚至整數乘法，因為它們在 SPARC Station上非常慢。為了恢復速度，看起來仍然像視頻，我盡量只做加減法、位屏蔽和移位運算。

在nv發布的一兩年期間，除了MBONE，其他平臺上也出現很多不同的音視頻工具，比如Mac上運行的CUSeeMe。顯然，流媒體時代已然到來。最后，我讓nv可以支持其他音視頻工具，有時其他工具也會使用nv的編解碼器，這樣它們就能在使用我的壓縮方案時相互操作。

03

—

起草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就此誕生！

04

—

RTP趣事

其中一件趣事是，我開發了一版使用IP組播的經典Spacewar游戲。沒有任何中央服務器的情況下，多個客戶端可以各自運行 Spacewar，并開始廣播他們飛船的位置、速度、行駛方向以及所發射的子彈等信息。其他用戶也會獲取到這些信息并將其在本地渲染，這樣他們就能看到彼此的飛船和子彈，當飛船相互撞擊或者被子彈擊中，就會發生爆炸。我甚至讓爆炸后的殘骸也“活起來”，去一一擊毀其他飛船，有時還會發生一連串的爆炸，哈哈。

在最初的游戲中，我使用模擬矢量圖形對其進行了渲染，所以人們可以放大或縮小游戲中的一切。飛船本身是一堆矢量線段，是我邀請我在施樂帕洛阿爾托研究中心的同事們幫忙設計的，所以每個飛船看起來都很不一樣。

總的來說，RTP可以傳輸任何不需要完美有序交付的實時數據流。因此，除了音頻和視頻，我們還可以創建諸如共享白板之類的東西，甚至還可以讓RTP傳輸文件，尤其是與 IP 組播一起使用時。

試想類似BitTorrent的場景，但你并不需要讓所有的數據都是peer to peer的。原始數據發送者可以一次向所有接收者發送組播流，且如果傳輸過程中發生丟包，任何成功接收數據的一方都可以重傳數據。你甚至可以確定重傳請求的范圍，方便附近的接收者傳送數據副本，并且也可以組播給該區域的其他接收者，因為網絡傳輸中的丟包往往意味著下游有一堆客戶端在那一點上都錯過了相同的數據。

??

05

—

RTP遺憾

對于RTP我并沒有什么遺憾。但我知道，人們對RTP最多的抱怨是實現RTCP的復雜性（RTCP是與主要RTP數據流量并行運行的控制協議）。我認為RTP之所以沒有被廣泛應用多數是因為這種復雜性，尤其是在一些不需要RTCP特性的單播情況下。當網絡帶寬變得沒那么稀缺，擁塞問題也變得容易解決，許多人就通過TCP（后來是HTTP）傳輸音頻和視頻，既然這種解決方案已經“足夠好”，那RTP就派不上用場了。

遺憾的是，使用TCP或者HTTP傳輸，意味著多個音視頻應用需要向接收對象多次發送相同數據，從帶寬的角度來說，這種方式太低效了。我有時會想，如果當初我們能將IP組播推廣到更多領域（不僅是科研）該有多好。如果是那樣的話，我們能更快看到從有線和廣播電視到基于互聯網的音視頻的轉變。

RTP四位作者簡介：

Ron Frederick：美國計算機科學家，RTP協議作者之一，他的Github：https://github.com/ronf/。

Van Jacobson：美國計算機科學家，TCP/IP主要貢獻者之一，他以在TCP/IP網絡性能和擴展方面的開創性成就而聞名。

Steve Casner：美國計算機科學家，RTP協議作者，2020年因其對互聯網多媒體協議標準的突出貢獻而獲得IEEE Internet Award。

Henning Schulzrinne：哥倫比亞大學計算機科學系教授，FCC（美國聯邦通信委員會）CTO，他共同開發的協議標準包括RTP、RTSP、SIP。

翻譯?/ Alex?

技術Review / 劉連響

原文鏈接：

https://webrtcforthecurious.com/docs/10-history-of-webrtc/#webrtc

---

詳情請掃描圖中的二維碼或點擊閱讀原文了解大會更多信息。

總結

以上是生活随笔為你收集整理的RTP诞生记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。