RTSP 是目前仍在使用的兩種運行時間非常長的媒體流協(xié)議之一；由于 RTSP 的流媒體服務(wù)器實用程序，您可能熟悉該首字母縮略詞。您可能不太熟悉 RTSP 的悠久歷史（它是 1996 年發(fā)明的！）及其現(xiàn)狀和應(yīng)用。

隨著協(xié)議的發(fā)展，RTSP 流媒體有時被認(rèn)為是其他“老式”流媒體技術(shù) RTMP 的不那么受歡迎的競爭對手，或者與基于 Web 服務(wù)器的新協(xié)議相比不太相關(guān)。技術(shù)隨著時間的推移發(fā)生了變化，舊的協(xié)議已經(jīng)改變了角色并且仍然有用，但是在大多數(shù)情況下，它們本身不再被用作流媒體解決方案。相反，RTSP 和 RTMP 現(xiàn)在最常用于編碼和攝取媒體，作為更大的流式工作流的“第一英里”，而不是它們以前作為“最后一英里”交付格式的角色。

流媒體協(xié)議和視頻廣播可能會變得非常復(fù)雜和技術(shù)性很強，更不用說充滿了首字母縮略詞，但本文將在幾個簡明的項目符號中列出您需要了解的有關(guān)實時流媒體協(xié)議的所有信息，以確定是否使用 RTSP工作流程的關(guān)鍵部分，并建議潛在的 RTSP 到 RTMP 攝取解決方案，可以幫助您的 RTSP 設(shè)備輸入與支持 RTMP 編碼的平臺更兼容。

RTSP 流媒體的歷史

RTSP 流媒體已經(jīng)存在了很長一段時間。 RealNetworks、Netscape 和哥倫比亞大學(xué)之間的合作伙伴關(guān)系于 1996-97 年首次開發(fā)并交付了該協(xié)議。 RTSP 協(xié)議是通過 RealNetworks 的 RealAudio 和 Netscape 的 LiveMedia 的流媒體實踐的實踐經(jīng)驗開發(fā)的。正如 Mozilla 的 wiki 所說，它的主要目的是對媒體流進行“類似 VCR 的控制”（年輕的讀者，問你的父母）——換句話說，現(xiàn)在常見的播放、暫停、倒帶和以其他方式指導(dǎo)觀看體驗的能力.

RTSP 在 1998 年被標(biāo)準(zhǔn)化為 RFC 2326，并立即成為一種有用的方式，用戶可以直接從 Internet 播放音頻和視頻，而不必先將文件下載到他們的設(shè)備上。

它建立在當(dāng)時的現(xiàn)有標(biāo)準(zhǔn)之上，在操作上類似于 HTTP（因此很容易與現(xiàn)有的 HTTP 網(wǎng)絡(luò)兼容），并且能夠使用 SDP（會話描述協(xié)議，1998 年標(biāo)準(zhǔn)化）進行多媒體通信會話。

本質(zhì)上，RTSP 是一種應(yīng)用層協(xié)議，它與媒體服務(wù)器進行通信以建立會話并發(fā)送諸如“暫停”和“播放”之類的命令，而不是傳輸實際的流數(shù)據(jù)。傳統(tǒng)上，大多數(shù) RTSP 服務(wù)器還使用 RTP（實時傳輸協(xié)議）和 RTCP（實時控制協(xié)議）來傳遞其媒體流。

了解 Kaltura 的實時流媒體解決方案可以為您做什么。

REQUEST A DEMORTSP 立即被用于各種用途，例如現(xiàn)場演示、網(wǎng)絡(luò)攝像頭站點、在線教育和網(wǎng)絡(luò)廣播，隨后被包括在 YouTube 和 Spotify 等仍在使用的平臺、Skype 等通信應(yīng)用程序和媒體播放器中WMP 和 VLC。

RTSP 和 RTMP 曾經(jīng)是互聯(lián)網(wǎng)音頻和視頻流的領(lǐng)先技術(shù)，但是由于這兩種協(xié)議都需要專用服務(wù)器來進行最后一英里的內(nèi)容交付，因此它們無法很好地擴展到大型廣播。隨著時間的推移，基于 HTTP 的漸進式下載技術(shù)和自適應(yīng)比特率流解決方案開始超越舊的首選技術(shù)。原作者 Anup Rao 和 Rob Lanphier 以及其他人在 2016 年提出了 RTSP 2.0 版，其更新旨在縮短與媒體服務(wù)器的往返通信并解決網(wǎng)絡(luò)地址轉(zhuǎn)換 (NAT) 的一些問題。

如今，RTSP 最常被用作貢獻協(xié)議，即一種對內(nèi)容進行編碼的方法，然后通過其他方法將內(nèi)容流式傳輸給觀眾。 RTSP 仍然是 IP 攝像機的首選協(xié)議，它用于大多數(shù)監(jiān)控、CCTV 和會議視頻技術(shù)，所有這些都可以用作直播源。

RTSP 協(xié)議是如何工作的？

從廣義上講，協(xié)議是規(guī)定數(shù)據(jù)如何從一個系統(tǒng)傳輸?shù)搅硪粋€系統(tǒng)的規(guī)則。例如，眾所周知的超文本傳輸??協(xié)議 (HTTP) 管理 Web 服務(wù)器和瀏覽器之間的通信，定義頁面數(shù)據(jù)和超文本/鏈接如何通過 Web 發(fā)送。

如上所述，RTSP 在功能上在概念上類似于 HTTP，并且在最初開發(fā)時很容易與現(xiàn)有的 HTTP 網(wǎng)絡(luò)兼容。

我們之前注意到，它的作者將 RTSP 描述為媒體服務(wù)器的“網(wǎng)絡(luò)遠(yuǎn)程控制”。它旨在控制流而不需要本地下載。當(dāng)視頻流啟動時，使用該協(xié)議的設(shè)備會向啟動設(shè)置過程的媒體服務(wù)器發(fā)送 RTSP 請求。

RTSP 還支持多種控制請求操作（也稱為“命令”），例如播放、暫停、設(shè)置等。初始請求還應(yīng)通過“OPTIONS”命令向客戶端報告可用的選項。從那里開始，用戶可以根據(jù)允許的參數(shù)觀看、提示或關(guān)閉流。 RTSP 與 TCP 保持端到端的連接，通過這種穩(wěn)定的連接打開眾所周知的數(shù)據(jù)插口，無需任何本地下載或緩存，即可實現(xiàn)高傳輸速度。

由于 RTSP 依賴于一個專用的流媒體服務(wù)器，并且依賴于 RTP 來傳輸實際媒體，因此該協(xié)議不支持內(nèi)容加密或丟失數(shù)據(jù)包的重傳。盡管 RTSP 在語法和操作上與 HTTP 相似，但它也存在差異和不兼容性，如果不添加額外的軟件，就無法從 Web 瀏覽器以簡單、直接的方式流式傳輸它。由于這些因素以及前面提到的擴展到大型廣播的問題，它逐漸被更新的流媒體技術(shù)所取代。

在當(dāng)今的互聯(lián)網(wǎng)上，包含 RTSP 的視頻流工作流很可能會使用媒體服務(wù)器來攝取通過 RTSP/RTP 傳輸?shù)牧鳎ǜ鶕?jù)其指定為“貢獻協(xié)議”或“第一英里”技術(shù)），然后利用另一種方式交付以重新打包并發(fā)送要在各種設(shè)備上觀看的內(nèi)容。

RTSP 與 RTMP

由于這兩種協(xié)議都是視頻流世界的長期主力軍，讓我們來看看 RTSP 和 RTMP 如何相互疊加。

RTMP 或?qū)崟r消息傳遞協(xié)議是一種在傳輸控制協(xié)議 (TCP) 之上運行的技術(shù)，最初是作為 Macromedia-Adobe 的專有協(xié)議開發(fā)的，用于音頻、視頻和數(shù)據(jù)的實時流傳輸。 RTMP 的最佳功能是視頻播放器和服務(wù)器之間的持久 TCP 連接，它為觀看者提供一致且可靠的流。

值得注意的是，盡管它最初是為通過 Adob??e Flash Player 進行流式傳輸而設(shè)計的——但遺憾的是，截至 2021 年，F(xiàn)lash 已不復(fù)存在。但與 RTSP 一樣，如今該協(xié)議并未廣泛用于實際面向觀眾的流傳輸。當(dāng)作為工作流程的一部分使用時，RTMP 需要 Flash Player 技術(shù)的問題不再是一個問題。

RTMP 同樣是流式音頻和視頻難以實現(xiàn)的時代（1990 年代）的產(chǎn)物，解決方案必須克服硬件的實際限制。它啟動了互聯(lián)網(wǎng)流媒體的興起，并因其可靠性和效率而成為名副其實的內(nèi)容交付之王。

最終，Adobe 放松了控制，并在 2012 年發(fā)布了該協(xié)議的一個版本供公眾使用，但到那時，文字已成定局：Flash 開始被視為潛在的安全風(fēng)險，也開始被邊緣化為通過自適應(yīng)比特率流和 HTML5 播放器的交付方法。幾年后的 2015 年，YouTube 放棄了 HTML5 的 Flash，RTMP 作為最后一英里的技術(shù)走到了最后。

就目前的用例而言，RTMP 被廣泛用作現(xiàn)代直播平臺的攝取協(xié)議，通常被轉(zhuǎn)換為 HLS（HTTP Live Streaming）并傳送到適用于瀏覽器和移動設(shè)備的 HTML 5 視頻播放器。 RTMP 在第一英里的主要優(yōu)勢在于它允許用戶利用低成本或開源編碼器來進行直播內(nèi)容。

由于這兩種協(xié)議都沒有廣泛用于最后一英里的流傳輸，因此不能說它們之間已經(jīng)存在真正的競爭。到目前為止，它們有許多相似之處，最好從“正確工作的正確工具”的角度來看待。 RTMP 和 RTSP 都是控制媒體流的應(yīng)用級協(xié)議，都是低延遲協(xié)議，能夠通過穩(wěn)定的連接實時或近乎實時地按需交付媒體。

每個協(xié)議都有優(yōu)點和缺點，沒有正確或錯誤的答案；您是否使用其中一種取決于如何最好地滿足您的流媒體操作的需求以及您要使用的平臺和硬件的需求。

RTSP 是一個開放標(biāo)準(zhǔn)，由當(dāng)時 Adob??e 的競爭對手開發(fā)。通常，RTSP 專為端點之間的通信和控制而設(shè)計，在需要更便宜、更簡單的流式傳輸替代方案的情況下更受歡迎。它在某些方面得到了更好的發(fā)展，因為多年來它被工程師廣泛使用，RTMP 被隔離為專有技術(shù)。然而，由于之前RTMP的主導(dǎo)地位，很多主播對它并不熟悉。

RTSP 是本地化流的不錯選擇，并且經(jīng)常內(nèi)置在 IoT 軟件中以訪問視頻源。 RTSP 也是大多數(shù) IP 攝像機的標(biāo)準(zhǔn)，這使得您在會議或監(jiān)控系統(tǒng)中依賴流輸入的部分或全部設(shè)備可能會使用該協(xié)議。

示例 RTSP 到 RTMP 攝取解決方案

如您所知，RTSP 仍然廣泛用于 IP 攝像頭，這些攝像頭通常用于視頻會議、公共流/網(wǎng)絡(luò)攝像頭以及安全、監(jiān)控和閉路電視系統(tǒng)。它們也可能只是您可以使用的輸入設(shè)備。

在 Kaltura，我們意識到支持 IP 的攝像機在您的直播中的明顯實用性。由于您可能會發(fā)現(xiàn)自己處于輸入設(shè)備的最佳選擇運行 RTSP 協(xié)議但您需要攝取到更喜歡 RTMP 的平臺的情況下，我們的知識庫提供了至少一種編碼解決方法。請記住它是一個潛在的工作流程！

此外，鏈接文章中列出的程序可能適用于其他協(xié)議，例如 RTP、RTMP、MPEG-TS 和 ICY。以下是有關(guān)如何將 RTSP 轉(zhuǎn)換為 RTMP 以進行攝取的快速細(xì)分，以確保您可以無縫地使用 IP 攝像機設(shè)備（以及所有其他 RTSP！）作為流的輸入。

我們建議的方法使用中間服務(wù)器從配置 RTSP 的設(shè)備接收數(shù)據(jù)，然后從那里轉(zhuǎn)換為 RTMP 流，然后將其廣播到您的最終面向觀眾的平臺。隨著數(shù)據(jù)到達您的最終交付系統(tǒng)，它可以廣播成更適合在現(xiàn)代設(shè)備上觀看的其他格式，例如 HLS Viewer、HDS Viewer 或 MPEG-DASH Viewer。因此請記住，IP 攝像機和其他物聯(lián)網(wǎng)設(shè)備并非僅限于 RTSP 流媒體的死胡同。使用 RTSP 設(shè)備捕獲流媒體內(nèi)容時，有多種選擇；如果您的分發(fā)目的地對它接受的協(xié)議有限制，您仍然可以廣播到中間服務(wù)器，配置參數(shù)等等！ …您面向觀眾的目的地正在通過 RTMP 進行攝取。

如果您需要有關(guān)我們的直播產(chǎn)品和技術(shù)解決方案的進一步指導(dǎo)，我們的知識中心還提供了一系列詳細(xì)的文章，涵蓋了使用 Kaltura 進行直播的概述、直播編碼最佳實踐以及在流媒體中使用 RTMP 端點。無論您的技術(shù)問題和要求是什么，我們的目標(biāo)都是為您服務(wù)。