看 · 瀏覽器開起來就是監看牆
主控台依牆上發佈的版型排列畫格，每格帶燈號、頻道號、TSL 位址、頻道名、音訊電平與傳送鏈色條。單擊一格監聽該路音訊，雙擊看 720p 高畫質單路畫面，按 W 進全牆模式。多螢幕工作站可以把模組拆到獨立視窗；無人值守的監看牆用裝置憑證開機直入全牆。
- WebRTC 直送瀏覽器，不裝客戶端
- Solo 監聽、高畫質單路、全牆模式
- 一站最多 32 面牆，無人值守顯示端
多畫面監看：
瀏覽器就是監看牆，
告警在同一張卡上處理完。
端點科技的 Kaster View 是廣播級 Web 多畫面監看系統。訊號在媒體伺服器解碼、GPU 合成後以 WebRTC 直送瀏覽器，值班人員開瀏覽器就是監看牆。黑畫面、凍結、靜音、訊號中斷與響度異常經防抖判定後進入告警處理區，在同一張卡片上確認、切換備援、插入墊片、重啟編碼器，並回溯告警前後的畫面。
約 130 ms訊源到瀏覽器顯示 · 開發環境 9 路實測
8種內建故障偵測
3種一鍵快速處置
120 秒告警即時回溯
30 路同框，
紅色那張卡不是人盯出來的。
- 偵測到黑畫面CH09 變黑，格子轉琥珀色，進入防抖判定，還不響鈴。
- 進入告警處理區持續超過 2 秒，告警卡出現在右側並響鈴，格子轉紅。
- 值班人員確認按下確認，鈴聲停止，5 秒內可復原；卡片留著繼續追蹤。
- 在同一張卡上切換備援設備回報結果與耗時，事件日誌與稽核同時記下。
- 訊號恢復，觀察後釋放卡片轉綠進入恢復觀察，期滿自動離開告警處理區。
值班只有三件事：
看、判斷、處理。
Kaster View 的五個模組（主控台、傳送鏈、排版、回溯、設定）都圍繞這三件事設計。下面每一張特寫都是產品的實際畫面。
判斷 · 異常先防抖，再進告警處理區
媒體節點對每一路做第一層偵測：黑畫面 · 畫面凍結 · 靜音 · 訊號中斷 · 抖動過大 · 響度偏離目標 · 削波 · MPEG-TS 第一優先級錯誤（TR 101 290）。異常先進入防抖判定，持續超過頻道設定檔的秒數才成為告警並響鈴；同一個上游造成的多路故障合併成一起事件並標出根因，確認一次就好。維護窗與系統維護期間不告警。
- 8 種偵測，依新聞 / 體育 / 電影設定檔調閥值
- 防抖判定、恢復觀察、擱置到期自動恢復
- 根因合併，一次確認整起事件
處理 · 在同一張卡上處置，結果回到同一張卡
告警卡上直接切換備援、插入墊片、重啟編碼器，由設定頁對應的現場設備執行；設備回報的結果與耗時顯示在卡上，寫進事件日誌與稽核。「回溯」帶著頻道與故障時間打開回溯頁，環形快取保留最近 120 秒，告警前後 30 秒自動保留，可匯出 MP4 片段。
- 切換備援：SRT / MPEG-TS 備援位址，或經 NMOS IS-05 與主流路由器控制協定切換路由
- 插入墊片：以主流控制協定操作的墊片源
- 重啟編碼器：SNMP 或 REST 控制的編碼器
- 120 秒即時回溯、MP4 匯出
從硬體 Multiview 機箱加監看牆，
到伺服器合成、瀏覽器顯示。
傳統監看牆是 SDI 矩陣、硬體 Multiview 機箱與一排實體螢幕，每一個監看位都要再拉一條線；告警靠人輪流盯，處置要換到另一套系統。Kaster View 把解碼、偵測與合成放在伺服器的 GPU 上，畫面以 WebRTC 送到任何一台開著瀏覽器的電腦；新增一路訊號是新增一個 IP 訊源，新增一個監看位是多開一個分頁。偵測、告警、處置與回溯在同一個畫面完成，每一步寫進稽核。
| 項目 | 硬體監看牆 | Kaster View |
|---|---|---|
| 新增一路訊號 | 拉線、調矩陣，路數滿了再加機箱 | 新增一個 SRT、MPEG-TS、HLS 或 DASH 訊源 |
| 新增一個監看位 | 再接一台顯示器與一組線路 | 多開一個瀏覽器分頁 |
| 改版型 | 到機箱上設定 | 在瀏覽器編輯，發佈後下一幀生效，一鍵回到上一版 |
| 告警到處置 | 靠人輪流盯，處置要換到另一套系統 | 防抖後進入告警處理區，在同一張卡上確認、切換備援、插入墊片或重啟編碼器 |
| 事後追查 | 很難知道是誰、何時、做了什麼 | 每一步寫入只可追加的稽核日誌，告警前後 30 秒自動保留 |
| 延遲 | 依機箱而定 | 訊源到瀏覽器顯示約 130 ms（開發環境 9 路實測） |
影像走媒體節點直送瀏覽器，
控制平面只傳元數據。
每一路訊源由一條解碼工作者處理；合成器把格子以固定時脈合成一面牆、編碼後經 SFU 送到瀏覽器。Kaster Core 負責帳號、告警狀態機、設定與稽核，和媒體節點之間只走 gRPC 與 NATS，不經手影像。
- SourcesSRT（caller / listener） · MPEG-TS over UDP / RTP · HLS · DASH
- Decode + Sense每路一條解碼工作者 · 第一層偵測 · 縮成格子
- ComposeGPU 合成 · 固定時脈 · NVENC 編碼
- WebRTCSFU 直送瀏覽器 · 監看牆顯示端
- Kaster Core告警狀態機 · 快速處置 · 稽核 · 整合
上線後只剩三件事：
排版、閥值、通知。
三頁都在瀏覽器裡。排版發佈後下一幀生效、一鍵回到上一版；設定改動先存草稿，檢視差異後才套用，可回滾，每一次都留版本與稽核。
產品畫面：排版編輯器，1+7 範本與螢幕接縫。 排版
從 9 種範本開始，拖曳合併格子、放入訊源、疊加時鐘與網頁；發佈前檢查列出還缺什麼。發佈後合成器在下一幀換上，錯了一鍵回到上一版。
產品畫面：體育設定檔的黑畫面、凍結、靜音閥值。 閥值
每種故障要持續多久才算告警，依新聞、體育、電影三個設定檔各自設定，灰色刻度是內建預設值。改動先存草稿，檢視差異後才套用，可回滾。
產品畫面：三層升級政策與通知通道。 通知
未確認的告警依升級政策逐級通知：值班、傳輸工程、On-call 主管各有自己的通道與等待分鐘數。事件管理平台、團隊通訊軟體、Email 與簡訊通道可個別停用與傳送測試。
工程規格。
數字只列實測值並註明環境；正式機的路數以評估時的實測報告為準。
| 訊源攝取 | SRT（caller / listener） · MPEG-TS over UDP / RTP · HLS · DASH；SRT 與 MPEG-TS 可設主備位址自動切換；訊源探測檢查鎖定、碼率、丟包與延遲 |
|---|---|
| 監看牆輸出 | WebRTC（WHEP）直送瀏覽器；單一牆最多 64 格、4K 輸出（設計目標）；一站最多 32 面牆，可跨牆派送版型 |
| 延遲 | 訊源到齊至瀏覽器顯示 p50 約 130 ms（開發環境 9 路實測；設計目標 500 ms） |
| 故障偵測 | 黑畫面 · 畫面凍結 · 靜音 · 訊號中斷 · 抖動過大 · 響度偏離目標 · 削波 · MPEG-TS 第一優先級錯誤（TR 101 290）；防抖秒數、恢復觀察與門檻依頻道設定檔設定 |
| 告警處理 | 確認（5 秒內可復原）· 擱置到期自動恢復 · 根因合併 · 升級政策 · 維護窗 · 快速處置：切換備援 / 插入墊片 / 重啟編碼器 |
| 回溯 | 每路 120 秒環形快取 · 告警前後 30 秒自動保留 · 時間軸事件標記 · 逐幀與 J / K / L 變速 · MP4 片段匯出 |
| 排版 | 2×2 / 3×3 / 4×4 / 5×5 / 6×5 / 1+5 / 1+7 / 2+8 / 1+12 範本與自訂網格 · 合併格 · 浮動時鐘與網頁 · 發佈前檢查 · 發佈後下一幀生效 · 一鍵回到上一版 |
| 整合 | Webhook（HMAC 簽章） · SNMP Trap 與 MIB · TSL UMD / Tally v3.1–v5.0 · Prometheus / Grafana · 事件管理平台 · 團隊通訊軟體 · Email · 簡訊 · WebSocket 事件串流與 API 金鑰 |
| 設備控制 | NMOS IS-05 與主流路由器控制協定（路由切換）· 主流墊片源控制協定（墊片）· SNMP / REST（編碼器重啟） |
| 帳號與稽核 | 本機帳號與 MFA · Viewer / Operator / Admin 三種角色 · 關鍵操作重新驗證 · 只可追加、雜湊鏈防竄改的稽核日誌，可匯出 CSV |
| 部署 | 地端容器化安裝，支援離線安裝 · Kaster Core：x86 伺服器（Ubuntu 22.04 / 24.04）· 媒體節點：x86 + NVIDIA 資料中心或專業 GPU · 瀏覽器端 Chrome / Edge |
數據來源：端點科技 2026 年 10 月開發環境實測，9 路 1080p30 連續運作 1 小時、端到端延遲量測各兩次。標示「設計目標」者尚未在正式機實測。
依循的標準
| ETSI TR 101 290 | MPEG-TS 傳輸流量測，第一優先級錯誤進入告警 |
|---|---|
| ITU-R BS.1770 | 響度（M / S / I）與真峰值量測、響度偏離與削波判定 |
| SRT | 訊源攝取（caller / listener），可設主備位址 |
| HLS（RFC 8216） | 訊源攝取 |
| MPEG-DASH（ISO/IEC 23009-1） | 訊源攝取 |
| WebRTC / WHEP | 監看牆與高畫質單路畫面送到瀏覽器 |
| TSL UMD v3.1 / v4.0 / v5.0 | Tally 與 UMD 標籤送到外部設備 |
| AMWA NMOS IS-05 | 切換備援時的路由切換 |
| SNMP v2c / v3 | 告警以 SNMP Trap 送出，附 MIB |
三步，從評估到上線。
申請試用
填寫聯絡表單，業務將於一個工作天內回覆，安排技術顧問評估。
訊源與設備盤點
技術顧問盤點訊源協定、路數、現場的路由器、墊片源與編碼器，決定媒體節點規格並以候選伺服器實測路數。
部署與上線
在客戶機房安裝 Kaster Core 與媒體節點，建立帳號與電視牆，以非播出頻道演練告警、處置與回溯後正式上線。
常見問題。
Multiview 和 Kaster View 是同一個產品嗎？
是。端點科技的多畫面監看產品更新後以 Kaster View 為名，網址與既有洽詢管道不變；Multiview 是這類產品的通稱，也就是「多畫面監看（multiviewer）」。這一版改為伺服器合成、瀏覽器顯示，並加入告警處理區、一鍵快速處置與告警回溯。
Web multiviewer 和硬體 multiviewer 差在哪？
硬體 multiviewer 是機箱接 SDI 矩陣、再輸出到實體螢幕，每加一個監看位就多一組硬體與線路。Web multiviewer 在伺服器的 GPU 解碼與合成，以 WebRTC 送到瀏覽器，加一個監看位只是多開一個分頁。Kaster View 另外把偵測、告警處理、處置與回溯放在同一個畫面，訊源到瀏覽器顯示約 130 ms（開發環境 9 路實測）。
監看牆要幾台螢幕？用筆電可以看嗎？
不需要專用螢幕。任何裝 Chrome 或 Edge 的電腦都能開主控台，筆電也可以。多螢幕工作站可以把模組拆到獨立視窗；牆面顯示器接一台電腦，以裝置憑證開機直入全牆模式，不用登入個人帳號。同時觀看的瀏覽器設計在 10 個以內。
Kaster View 一套可以同時監看幾路訊號？
路數由媒體節點的 GPU 決定，不是固定數字。設計目標是單一監看牆最多 64 格、4K 輸出，單站 100 路偵測；開發環境以 9 路 1080p30 連續運作 1 小時沒有遺失任何一幀。正式機的路數以評估時用候選伺服器實測的數字為準，端點科技會附上測試報告。
Kaster View 支援哪些訊源？SDI 訊號怎麼接？
攝取支援 SRT（caller / listener） · MPEG-TS over UDP / RTP · HLS · DASH。SRT 與 MPEG-TS 訊源可以設主備兩個位址，主路中斷自動切到備路。SDI 或 HDMI 訊號先經編碼器轉成 SRT 或 MPEG-TS 再接進 Kaster View，端點科技的 Broadcast Encoder 可以做這一段。目前不直接攝取 NDI 與 SMPTE ST 2110。
告警處理區是什麼？和一般的告警清單有什麼不同？
告警處理區是主控台右側的工作區，介面上沿用主控室的說法叫「懲罰箱」。偵測到的異常先進入防抖判定，持續超過設定秒數才成為告警並響鈴；值班人員在卡片上確認（5 秒內可復原）、擱置、切換備援、插入墊片或重啟編碼器，訊號恢復並觀察期滿後卡片自動離開。同一個上游造成的多路故障會合併成一起事件，確認一次就好。
Kaster View 和 LiveQC 怎麼分工？
Kaster View 是值班人員的即時工作台：看畫面、收告警、在卡片上處置、回溯取證，一切都在瀏覽器裡。LiveQC 是逐頻道的品質量測與合規層：長期的響度、字幕與訊號品質量測，以及給主管機關與廣告主的報表。兩套可以各自導入，也可以同時監看同一組頻道。
需要什麼硬體？怎麼部署？
Kaster View 以容器化方式安裝在客戶機房：Kaster Core（控制平面）跑在 x86 伺服器，媒體節點是 x86 伺服器加 NVIDIA 資料中心或專業 GPU，兩者可以同機也可以分開。安裝包含離線安裝流程，不需要機房連外網。值班人員與監看牆只要 Chrome 或 Edge 瀏覽器，不用安裝客戶端。
Kaster View 可以接到既有的告警與監控系統嗎？
可以。告警與事件可送到 Webhook（HMAC 簽章） · SNMP Trap 與 MIB · TSL UMD / Tally v3.1–v5.0 · Prometheus / Grafana · 事件管理平台 · 團隊通訊軟體 · Email · 簡訊 · WebSocket 事件串流與 API 金鑰。切換備援、插入墊片與重啟編碼器透過 NMOS IS-05、主流路由器與墊片源控制協定、SNMP 與 REST 控制現場設備。每一筆操作與設定變更都寫入只可追加、以雜湊鏈防竄改的稽核日誌，可匯出 CSV。
相關產品：LiveQC 即時品質監控、Broadcast Encoder；名詞：多畫面監看、SRT。