簡短回答：選擇接收端實際能夠接受的協議。當兩端都支援且路徑已設定時，SRT 是一種貢獻流選項；RTMP仍是常見的編碼器到平臺或接收伺服器交接方式。觀眾播放和交付仍是單獨設定的下游任務。
從接收端開始，再選擇交接方式
| 決策點 | SRT 路徑 | RTMP 路徑 |
|---|---|---|
| 接收端 | 您控制或被分配的支援 SRT 的貢獻流接收端 | 為發布提供的 RTMP 接收端點或平臺 URL |
| 傳輸 | 基於 UDP 的 SRT 工作階段；直播模式包括定時和重傳控制 | 到已設定端點的基於 TCP 的 RTMP 工作階段 |
| 網路問題 | 兩個對等端能否互達，且模式、延遲和密碼短語設定是否一致？ | 編碼器能否到達主機，且 URL/密鑰是否符合端點約定？ |
| 編解碼器問題 | 單獨驗證接收端接受的容器和編解碼器 | 單獨驗證目標接受的音訊/影片 profile |
| 有用的下一任務 | 進入執行或製作工作流程的貢獻流 | 發布到接收服務或已設定 RTMP Server |
三個常見決策
- 平臺只提供 URL 和流密鑰：按該約定發布 RTMP。
- 您的團隊控制 SRT 接收端：當兩端已一致約定模式、host:port、延遲以及任何 Stream ID/密碼短語時使用 SRT。
- SRT 貢獻流終止於 RTMP/RTMPS 平臺：分別驗證 SRT 貢獻流和平臺發布交接。
SRT 直播模式圍繞已設定的延遲窗口和接收端反饋設計；更大的窗口可提供更多恢復時間，但它仍是部署選擇，而非更好影像的承諾。RTMP 兼容性同樣取決於端點。即使其他位置的貢獻流鏈路使用 SRT，要求 RTMP 或 RTMPS URL 的平臺仍決定最終交接方式。
執行上有什麼變化
| 首次連接前 | 記錄內容 |
|---|---|
| SRT | Caller/listener/rendezvous 模式；host:port；延遲；使用時的 Stream ID 或密碼短語；容器和影片/音訊編解碼器。 |
| RTMP | 完整接收 URL、應用/路徑和密鑰；接收端聲明的 profile（端點要求時通常是 H.264/AAC）；以及其流健康檢查。 |
請勿將憑據放入截圖、聊天記錄或測試錄製中。
SRT 加密與 RTMPS 解決不同的傳輸安全問題：SRT 可設定加密，而 RTMPS 是通過 TLS 承載的 RTMP。RTMPS 目的地並不說明獨立 RTMP Server 的接收選項。
測試一條貢獻流路徑
任一標籤頁使用同一準備好的來源：鎖定節目格式，記錄影片和音訊編解碼器設定，並讓發布者存取選定測試端點。啟動一個協議工作階段，確認發布者狀態，檢查預覽；若工作流程使用下游輸出，再驗證該輸出。
協議演示
選擇一種協議進行測試
每個演示均手動啟動，並保持自己的臨時租約。比較工作流程時請使用匹配的來源設定；此頁面不執行受控延遲基準測試。
即時 SRT 示範
試用即時 SRT 連線
建立一條持續一小時的暫時連線。以 Caller 模式將訊號發送到發布者位址， 將 Stream ID 留空。 可在下方 Multiview 中觀看，或以 Caller 模式將接收端連線到接收端位址。
結果確認選定來源到達了該臨時路徑及其預覽。這是設定檢查，而非比較基準，因此不會對延遲、質量或可靠性排序。將變更後的設定作為新測試重複，並保留接收端日誌或操作員可見的連接資料。
Callaba 的適用位置
Callaba 的 RTMP Server 可以為發布者和接收者提供獨立存取規則，並顯示操作員可見的活動。Guest RTMP Server 則可在沒有預定義存取規則時開放。其SRT Server是兼容 SRT 工作流程對應的貢獻流資源。瀏覽器觀察和觀眾播放使用單獨設定的模塊；RTMP 發布 URL 不能直接在瀏覽器播放。
後續步驟
- 如需已設定的 RTMP 監聽器，請查看RTMP Server及其存取/生命週期控制。
- 如需 SRT 貢獻流接收端，請查看SRT Server。
- 如需明確橋接，僅在確認兩個端點後使用文檔化的RTMP 貢獻流網關路徑。
