把延遲推進到亞秒級

看一場球賽，隔壁鄰居的歡呼聲總比手機畫面早到幾秒。那不是你的網路有問題，而是大多數直播一路長大的分發模型所收的費用：把串流切成片段、把片段送出去、讓播放器先緩衝到足以抵抗抖動。它很穩，能撐起幾百萬人同時觀看，代價是真正的互動變得不可能。這套エンジン針對的正是這段落差。改用 WebRTC 播放之後，延遲落在半秒上下，那正是「對話還像對話、而不是無線電喊話」的範圍。

需要它的場景很具體。拍賣直播裡，出價必須在同一個瞬間對所有人成立；線上課堂上，學生舉手期待的是回答，而不是延遲過後的反應；任何期待觀眾對眼前畫面做出回應的形式都一樣。對這些場景來說，一套能自架、又能做到亞秒級分發的方案，一直是缺的那一塊。

往裡看，它是一套 Java 寫成的串流エンジン，社群版以 Apache 授權開源。鏈路是完整的，不是半套：推流接入、轉碼、多協議分發都在同一個產品裡，不必把三個專案用訊息佇列縫起來，再祈禱兩邊的時鐘一致。Docker 部署則讓一個小團隊用一個下午、而不是一個季度，就把整組東西站起來。

3.1 把手伸進專業製作

2026 年 9 月推出的 3.1 版，把注意力轉向製作現場。新增 NDI 來源接入，スタジオ、教室或企業內網裡的專業設備會被自動發現，直接匯入直播流程。SRT 推流支援多音軌與語言標籤，多語同步口譯與備用解說的分發問題，至此有了著落。管理介面重做成更現代的樣貌（目前為測試版），執行環境升級到 Java 21，GPU 編碼在多張卡之間的負載分配也做了改善。

兩套協議在這裡不是互相競爭，而是分工。HLS 負責讓習慣傳統觀看方式的人順利播放，緩衝與相容性由它承擔；WebRTC 負責不能忍受延遲的互動觀眾。依場次而不是依產品來選擇，才是一次真實部署的樣子。

成本這件事值得攤開講，因為自架常被當成玩票。託管的直播平台按傳輸分鐘數加上每位觀眾收費，房間坐滿或空著，計費器都在跑。自己擁有的伺服器則按頻寬與你自己的時間收費。對於本來就在跑基礎建設的組織，第二張帳單熟悉也可預測；對於從沒維運過任何東西的團隊，第一張的各種意義上都更便宜。誠實的判準是：凌晨兩點直播掛掉、有人叫你處理的時候，你答不答得上來。

低延遲這個說法之所以可信、而不是空話，取決於分發的形狀。互動場次不需要那套讓 HLS 對大規模觀眾可靠的切片與緩衝，它需要的是一條夠短的路徑，短到鏡頭前舉起的手還舉著，答案就已經到了。兩條路徑放在同一個產品裡，再依場次選擇，這個設計決定才讓那些數字在實務上站得住。

它代表開源基礎建設的扎實路線：把「低延遲直播」這件難事拆成接入、轉碼、分發、播放，一環一環做透。專業能力開源化，中小團隊是最大的受益者。

選型要講清楚。社群版功能完整，但叢集與部分進階能力屬於企業版。建議從社群版的單機起步，等量體真的起來再談橫向擴充，因為十個觀眾時需要的架構，跟一萬個觀眾時需要的架構不是同一套。至於成本，直播真正的大頭是伺服器頻寬，先算過再對外承諾價格。

對需要自己掌握整條鏈路的團隊——線上教育、互動活動、監控影像匯聚——它是自架方案裡性價比最清楚的那個。你用一筆月費換來一份維運責任，而對合適的團隊來說，這筆交易划算。