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

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

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

RTSP 流媒體的歷史

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RTSP 與 RTMP

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

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

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

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

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

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

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

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

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

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

示例 RTSP 到 RTMP 攝取解決方案

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

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

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

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

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