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

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

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

RTSP 流媒體的歷史

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

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

它建立在當時的現有標準之上，在操作上類似于 HTTP（因此很容易與現有的 HTTP 網絡兼容），并且能夠使用 SDP（會話描述協議，1998 年標準化）進行多媒體通信會話。

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

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

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

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

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

RTSP 協議是如何工作的？

從廣義上講，協議是規定數據如何從一個系統傳輸到另一個系統的規則。例如，眾所周知的超文本傳輸??協議 (HTTP) 管理 Web 服務器和瀏覽器之間的通信，定義頁面數據和超文本/鏈接如何通過 Web 發送。

如上所述，RTSP 在功能上在概念上類似于 HTTP，并且在最初開發時很容易與現有的 HTTP 網絡兼容。

我們之前注意到，它的作者將 RTSP 描述為媒體服務器的“網絡遠程控制”。它旨在控制流而不需要本地下載。當視頻流啟動時，使用該協議的設備會向啟動設置過程的媒體服務器發送 RTSP 請求。

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

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

在當今的互聯網上，包含 RTSP 的視頻流工作流很可能會使用媒體服務器來攝取通過 RTSP/RTP 傳輸的流（根據其指定為“貢獻協議”或“第一英里”技術），然后利用另一種方式交付以重新打包并發送要在各種設備上觀看的內容。

RTSP 與 RTMP

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

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

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

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

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

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

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

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

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

RTSP 是本地化流的不錯選擇，并且經常內置在 IoT 軟件中以訪問視頻源。 RTSP 也是大多數 IP 攝像機的標準，這使得您在會議或監控系統中依賴流輸入的部分或全部設備可能會使用該協議。

示例 RTSP 到 RTMP 攝取解決方案

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

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

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

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

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