Josh Huang's Engineering Notes
一個轉播中樞，好幾台攝影機，一次無聲的拒絕
把好幾台不同攝影機的 RTSP 影像，集中到同一層轉播架構後面，乾淨地解決了「一對多」的擴充問題——直到其中一台完全沒有音軌的攝影機，撞上了一個沒人會想到「影像明明正常」卻會失敗的 YouTube 健康檢查。
This article is also available in English: English version——內容相同，僅語言不同。
一旦手上的攝影機超過一台，都想放上 YouTube 直播，「每台攝影機各自跑一個 ffmpeg 程序」 這個做法就沒辦法乾淨地擴充下去——不同品牌的攝影機，講的是各自不同、 不完全標準的 RTSP 變體，把編碼邏輯每個來源都複製一份, 正好就是那種該集中處理一次、而不是每台裝置各複製一份的事。 集中處理之後，意外撞上了一個真正讓人意外的 YouTube 要求： 即使影像完全正常，一條直播還是可能因為「完全沒有音訊」而過不了健康檢查。
一對多的擴充問題，以及為什麼一個轉播中樞會贏過 N 個 ffmpeg 程序
不同品牌的攝影機硬體，講的「RTSP」其實有著實質上的差異——有些是貨真價實的標準協定, 有些則是廠商自訂的變體，一般的 RTSP 用戶端根本連不上，需要專門支援該品牌協定才行。 如果每台攝影機、每個品牌都各自跑一整套完整的擷取加編碼流程, 代表連線邏輯、憑證處理、重連／健康檢查的行為都要複製 N 份， 而且有 N 次機會讓這些複製品彼此漸漸不同步。把這一切都集中到同一個轉播服務後面—— 一個在輸入端負責講每台攝影機各自原生協定、在輸出端則為每台攝影機, 統一重新提供一個標準化 RTSP／WebRTC 輸出的服務—— 能讓「加一台新攝影機」這件事，變成「加一筆設定」，而不是「重建一整套流程」。
Unlock this article to keep reading, or subscribe for unlimited access to everything. See Pricing for details.