直播在製作環境中的運作方式

直播的運作方式

1. 擷取： 攝影機、螢幕來源和音訊裝置產生直播節目。
2. 編碼： 硬體或軟體編碼器將節目壓縮為具有特定 codec、bitrate、解析度和幀率的設定。
3. 輸入： 編碼器透過 SRT、RTMPS、RIST 或其他支援的傳輸方式發佈一路 contribution 訊號。
4. 路由與處理： 平台驗證訊號，在需要時建立不同 rendition，進行錄製並分發到各個目的地。
5. 封裝與傳遞： WebRTC、LL-HLS、HLS 或其他播放路徑將節目直接或透過 CDN 送達觀眾。
6. 播放與觀察： 播放器緩衝並呈現 stream，操作人員同時監控輸入狀態、傳遞錯誤和觀眾體驗。

每個階段都會使用部分延遲與可靠性預算。只最佳化編碼器無法彌補播放器的大型緩衝，低延遲播放器也無法修復不穩定的 contribution 路徑。

分別選擇 contribution 與傳遞方案

Contribution 是從製作來源到平台的路徑；傳遞是從平台到觀眾的路徑。兩者解決不同問題，不必使用相同協定。

如需針對延遲做出明確選擇，請使用 低延遲直播架構指南。對於不穩定網路上的 contribution，請查看 SRT contribution workflow。

設定可衡量的服務目標

在選擇協定或供應商之前先寫明目標。至少定義：

• 端到端延遲以及可接受的尾端延遲；
• 依裝置與地區分類的啟動時間和重新緩衝率；
• 編碼器掉幀、輸入 bitrate 波動、封包遺失和 RTT；
• 允許的中斷時間與復原時間目標；
• 所需的解析度、幀率與音訊配置；
• 同時在線觀眾、目的地數量和錄製保留期；
• 存取、營利、審核和法規遵循要求。

平均值會掩蓋活動風險。請追蹤百分位數和群組：健康的中位數可能與某個故障地區、裝置系列或 ISP 同時存在。

依照真實場景設計編碼設定

使用活動中的真實動作、圖形、瀏覽器來源與音訊路由驗證設定。靜態人物測試無法證明運動畫面或螢幕分享會保持穩定。

• 保留上傳餘裕，不要用滿可用連線。
• 讓 GOP 與 keyframe 設定符合目的地要求。
• 使用能反映真實觀眾裝置和頻寬的 bitrate 階梯。
• 在同時錄製和直播時測量 CPU 或 GPU 餘裕。
• 管理已驗證設定的版本，並在開播前凍結非必要變更。

使用 bitrate 計算器 進行初始容量規劃，然後以持續測試驗證結果。

在架構中加入復原能力

可靠的 stream 對訊號來源遺失、網路遺失、目的地故障和播放器降級都有記錄明確的回應方案。

1. 準備一條不依賴相同網路故障域的備用 contribution 路徑。
2. 在活動前監控主要與備用路徑，而不是在事故發生時才發現 standby 失效。
3. 明確設定 failover 是自動或由操作員控制，並指定決策負責人。
4. 為效能較弱的裝置或不穩定的傳遞路徑保留安全的 fallback 設定。
5. 演練目的地憑證過期和單一目的地故障，確保不會停止所有輸出。

對於長期頻道，將設定視為 release 產物：負責人、版本、測試證據、警示門檻和 rollback 說明應保持在一起。

監控完整的觀眾路徑

輸入健康是必要條件，但並不充分。編碼器可能仍保持連線，而觀眾已經遇到 manifest 失敗、分段載入緩慢、解碼錯誤或過度緩衝。

• 來源： 擷取幀率、音訊連續性和編碼器負載。
• Contribution： 連線狀態、輸入 bitrate、RTT、遺失、重傳和延遲封包。
• 處理： 佇列深度、rendition 錯誤、時間戳連續性和錄製狀態。
• 傳遞： origin 錯誤、CDN 快取行為、請求延遲和地區故障。
• 播放： 啟動時間、重新緩衝、嚴重錯誤、與直播邊緣的距離以及 A/V 同步。

執行獨立的播放探測。綠色的輸入面板絕不能成為節目正在直播的唯一證據。

製作前檢查清單

1. 從真實場地或網路，以計畫的 bitrate 與持續時間執行測試。
2. 確認每個目的地、token 到期時間和隱私狀態。
3. 在具有代表性的手機、桌面裝置和電視上驗證播放器。
4. 觸發一次受控故障，並驗證復原與警示。
5. 檢查錄製、字幕、圖形、音訊聲道對應和同步。
6. 記錄 release 負責人、rollback 負責人和升級管道。

產生可重複的測試影片 並使用 直播品質檢查 然後再向觀眾開放活動。

託管路由層何時有幫助

當一路經過測試的輸入需要供給多個平台、錄製或播放 workflow，而不希望製作編碼器為每個目的地分別上傳時，路由層非常有用。它集中目的地控制、可觀察性和復原能力，同時讓來源設定更簡單。

使用 Callaba Multi-Streaming 將一路直播輸入分發到多個目的地並管理傳遞路徑。若需要掌控基礎設施， 自架選項 是獨立的部署選擇，而不是重複的直播 workflow。

常見問題

什麼是直播？

直播是在活動進行期間持續擷取、編碼、傳輸和播放影片。製作系統還包括路由、監控、復原和存取控制。

哪種協定最適合直播？

不存在適合所有情況的最佳協定。SRT 或 RTMPS 可承載 contribution 訊號，而 WebRTC、LL-HLS 或 HLS 可滿足不同的觀眾延遲與擴充需求。

直播需要多少上傳速度？

連線容量必須高於設定的影片與音訊 bitrate。請保留運作餘裕，並測試持續效能、抖動和遺失，而不是只依賴一次測速。

如何提高直播可靠性？

使用經過驗證的編碼設定、獨立備用路徑、端對端監控、演練過的 failover，以及針對弱網路或裝置測試過的 fallback。

一個編碼器可以推送到多個平台嗎？

可以。路由或 multistreaming 服務可接收一路 contribution 訊號並分發到多個平台，從而減少本機上傳和運作複雜度。

最終製作原則

最佳化整條鏈路，而不是單一協定。 定義觀眾結果，測量每個階段，演練一次故障，然後再將 workflow 投入製作。