RTMP 直播協議與 RTSP 有何分別？
RTMP 與 RTSP 都是傳輸視訊與音訊的串流協定，卻各自服務不同的市場：RTSP 是閉路電視與視訊監控系統的支柱，RTMP 則常見於互聯網即時直播的上行環節。本文說明兩種協定的設計取向、延遲與埠口使用的分別，以及它們如何在監控與直播結合的系統中分工。
兩種協定各自服務哪種用途
RTSP（Real Time Streaming Protocol，即時串流協定）與 RTMP（Real-Time Messaging Protocol，即時訊息協定）都負責在網絡上傳輸影音，但兩者的出身與主要用途截然不同。
RTSP 是監控系統的「會話管理員」
RTSP 由 IETF 於 1998 年制定為開放標準（RFC 2326），目前由 RFC 7826 更新，設計目標是控制影音串流的播放：發送 PLAY、PAUSE、TEARDOWN 等指令，通知伺服器或攝影機「開始傳送、暫停、停止」哪一條串流。實際的影音資料則由 RTP 協定承載傳輸。IP 攝影機、NVR、錄影軟件（VMS）之間的互通，幾乎都圍繞 RTSP 建立，因此它是視訊監控領域的事實標準。
RTMP 是直播「上行推送」的主流
RTMP 由 Adobe 於 2002 年提出並公開規格，2009 年起成為 Adobe 開放標準，設計目標是把直播影像「推送」上傳至媒體伺服器，再分發給大量觀眾。各大直播平台與串流工具預設輸出的，正是 RTMP 串流。它使用 TCP 持續連接，能即時調節傳輸速度以配合網絡狀況。
一句話概括：RTSP 長於「叫裝置播放並接收串流」，是監控觀看與錄影的骨幹；RTMP 長於「把串流推上平台分發」，是直播發佈的入口。監控與直播結合的場景，例如把店舖畫面直播到公眾平台，往往兩者都要用。
兩種協定的技術取向對比
RTSP 與 RTMP 的設計取向不同，反映在延遲特性、埠口使用與錯誤處理上。
| 比較項目 | RTSP／RTP | RTMP |
|---|
| 標準來源 | IETF 開放標準（RFC 2326、RFC 7826） | Adobe 公開規格，非 IETF 標準 |
| 傳輸層 | 控制指令用 TCP，影音資料用 RTP | 全程 TCP 持久連接 |
| 預設埠口 | 554 | 1935 |
| 主要角色 | 會話控制與播放管理 | 直播上行推送與分發 |
| 典型延遲 | 數百毫秒級，適合即時監看 | 秒級或更高，適合直播而非即時操作 |
| 典型場景 | IP 攝影機、NVR、VMS 監控系統 | 直播軟件推流至直播平台 |
對監控工程而言，最直接的區別是 RTSP 的互動性：操作人員按一下畫面即可叫攝影機改變碼流或停止傳送，延遲以毫秒計，這是控制室即時監看的基礎。RTMP 把影片「一股腦」推上伺服器，平台再分發給觀眾，秒級的延遲在直播接受範圍內，卻不適合需要即時判斷的監控操作。此外 RTSP 可讓接收端自行決定要觀看的是主碼流抑或子碼流，這個能力與監控系統「大畫面用主碼流、縮圖用子碼流」的省頻寬設計直接相關。
需要協助？串流整合涉及協定支援、埠口放行、上載頻寬與私隱合規，交由工程人員規劃可避免直播窒格或錄影取流互相影響。說明現有攝影機數量與直播平台即可。WhatsApp → 監控系統實際如何選用與並存
實際部署中，RTSP 與 RTMP 很少二擇其一，多數系統兩者並用，各司其職。
以商店或工場需要把監控畫面直播到公眾平台的場景為例：攝影機與 NVR 之間以 RTSP 溝通，這是錄影與內部觀看的骨幹；若要同時把畫面放上平台，常見做法是由錄影主機或媒體閘道把串流轉成 RTMP，再推送至直播平台的分發網絡。RTSP 負責「從攝影機取流」，RTMP 負責「把流推上平台」，一條畫面鏈路由兩種協定接力完成。
另一種常見分工是瀏覽器觀看。傳統 RTSP 並不受主流網頁瀏覽器直接支援，網站內的即時畫面往往須轉成其他形式（例如 HTTP 協議的 HLS）供瀏覽器播放；與此相對，RTMP 是直播平台與串流工具共同接受的入口，專業串流編碼器輸出 RTMP 已是常態。規劃時應先釐清畫面最終要到達哪裡：控制室、手機 App 抑或公眾平台，再決定串流路徑上每一段使用哪種協定。
選型與調試時還要注意防火牆埠口：RTSP 常用埠 554，RTMP 常用埠 1935。若場地防火牆或營運商封鎖相關埠口，串流會靜默失敗，畫面看似正常設定卻遲遲無法播放，排障時先檢查埠口放行與碼流位址拼寫，往往比檢查硬件更快找出問題。
延遲、碼流與位址格式的實務要點
把兩種協定接進實際系統時，有三個實務要點值得先掌握。
- 延遲要求決定協定——需要即時操作的場合（控制室監看、圍欄巡邏）以 RTSP 為主，數百毫秒的反應足以配合；只求「畫面能播」的場合，RTMP 或轉發後的 HTTP 串流已足夠，不必追求極低延遲。
- 碼流格式與相容性——RTSP 對編碼格式（如 H.264、H.265）與封裝的支援因設備而異，攝影機輸出的碼流參數（解析度、幀率、碼率）應配合錄影主機的接收能力；RTMP 則因長期用於直播，對常見編碼格式的相容性較一致。
- 位址格式不同——RTSP 的統一資源識別碼通常以 rtsp:// 開頭並包含埠號與路徑；RTMP 則以 rtmp:// 開頭。填錯前綴是最常見的初階錯誤，不少無法取流的個案，最終都是這一個字符的差異造成。
香港的實際環境對這類串流還有兩層考量。第一是上載頻寬：本地常見光纖寬頻對外上載速度未必與下載對稱，要同時推送多路高清串流到直播平台時，應先計算碼率總和與上載頻寬的差距，避免直播窒格或錄影取流互相爭用頻寬。第二是私隱法規：把監控畫面對外直播涉及公開他人影像，須符合《個人資料（私隱）條例》的要求，包括設置範圍告示與避免拍攝公共通道，這方面我們在CCTV 私隱合規一文有詳細說明。
監控與直播結合的常見做法
當監控系統需要與直播功能結合，市場上已有成熟的做法，可按規模選擇。
單機直接推流
部分支援直播功能的攝影機可直接輸出 RTMP 串流，把畫面推向直播平台，毋須額外硬件。適合單點、低成本的店舖直播或工地展示。
錄影主機集中轉發
由 NVR 或錄影軟件集中接收各攝影機的 RTSP 串流，再統一轉發或轉碼輸出，適合多路攝影機需要同時對外直播的場合，設定集中在一台主機完成。
媒體伺服器閘道
在網絡內部署媒體閘道，把 RTSP 轉成 RTMP 或其他格式，再推送至平台。閘道可加插轉碼與延遲控制，適合畫面品質與播放體驗有較高要求的部署。
無論採用哪種做法，規劃時都應同時考慮錄影頻寬與對外推送頻寬的預算。若直播只是錦上添花而非業務所需，更穩妥的次序是先確保錄影與內部監看正常，再逐步開放對外直播；一旦直播平台中斷或頻寬不足，也不應影響核心的錄影功能。本文所述的兩套協定正正代表這兩種節奏：RTSP 管「穩」，RTMP 管「播」，先穩後播是工程上的合理次序。