把「重活」做成極簡

以前要搭一套串流服務，得先裝一套媒體框架、接上轉碼器、前面再架一個網路服務，然後維護一整條互相對版本都有意見的元件鏈。改一行設定像在拆炸彈。這裡的提案正好相反：一個執行檔，啟動就跑，完全沒有外部依賴。

它以 Go 撰寫，從一個原本只以單一協定命名的專案長出來。隨著支援的協定越加越多，舊名字已經裝不下它的野心，於是改名。這段來歷同時解釋了它的小體積與廣覆蓋：同一份執行檔在伺服器上跑，也在單板電腦上跑，這一點多數媒體堆疊做不到。

網路意義上的媒體路由器

它最巧妙的定位，是把自己當成媒體路由器而不是平台。一路流可以從攝影機以 RTSP 推進，觀看端則各自挑適合的方式：瀏覽器用 WebRTC 取低延遲、用 HLS 做點播回看，或轉成 RTMP 交給期待這個協定的平台。同一個來源，協定在每一個觀看端的邊緣各自選擇，而來源不必改動。

攝影機匯聚是它最擅長的場景。家裡幾路攝影機全部推給同一個實例，筆電或手機開瀏覽器就能看，不需要用戶端軟體，也不必為每一路攝影機做設定。自架直播同樣順手：推流工具推進來，分發給觀眾這件事已經被處理掉了。

認證、錄製、按路徑分流，全都是設定選項，而不是付費分級或外掛；而整套東西能塞進單板電腦等級的設備。生產級功能配上業餘級硬體，這個組合併不常見。

設定就是一份帶區段的檔案，不必翻手冊也讀得懂。路徑有名稱，協定可以逐條路徑開關，而預設值已經夠合理，第一次測試幾乎不需要加任何東西。這件事比聽起來重要：媒體環境會腐壞，通常不是因為軟體差，而是半年後沒有人記得那五個會動的零件當初是怎麼接起來的。

它也很適合作為更大系統裡的一塊，而那正是路由器該待的位置。只會說一種協定的攝影機可以在這裡被統一，只會說另一種的觀看端可以在不碰攝影機的情況下被服務，錄製可以在旁邊跑而不改變兩端。每一項都是就地解決的小問題，而不是重建整條鏈條的理由。

它證明了基礎設施軟體也可以很輕盈：一個檔案、一份設定、零依賴，把流媒體這門重活辦得舉重若輕。簡單不是天真，而是處理完複雜之後剩下的東西。

把預期擺正

有一條界線要先說，因為它決定這工具合不合用：它做的是流的接入與分發，不做轉碼。如果攝影機送出的格式觀看端解不開，改多少設定都沒用，鏈條上必須再加一道處理。另一條界線是規模：超大規模的觀眾分發應該放在內容網路或叢集後面，把那種負載壓進一台小機器，是誤讀了它的設計。

給第一次嘗試的人一個實務建議。先只開一條路徑，確認某一路攝影機或某一次推流真的進來了，再去加認證與錄製。這類工具的挫折感，大多來自一次把全部設定都填滿，然後完全不知道是哪一段出錯。

但在它的範圍之內，它幾乎是最便宜的答案。家用監控、區域網路直播、兩套互不相讓的軟體之間的協定除錯，這些都是啟動一個檔案就解決的事。開源免費，跨平台一路覆蓋到低功耗 ARM 設備，更新活躍，文件詳盡。以一個下載的成本，值得在動手蓋更複雜的東西之前先試一次。