直播技術的公開資料有一個結構性問題：絕大多數「2026 年延遲比較」「編碼節省百分比」「浮水印檢測時間」的數字，來自賣相關產品的公司，而且幾乎都沒有附測試方法。這篇把本專欄的每一類陳述按證據強度分開，明確標出哪些可以當事實用、哪些只能當量級參考、哪些應該直接要求對方提供測試樣本。
📖 學
A 級：標準文件與規格可查證
這些有正式規格或官方文件背書，不會因廠商而異：
協定與格式
- HLS 的清單格式、LL-HLS 的四個機制（partial segment、blocking playlist reload、preload hint、delta playlist）由 Apple 的 HLS 規範定義。
- CMAF 是 ISO/IEC 標準（ISO/IEC 23000-19），fMP4 容器與 HLS/DASH 共用分片的可行性有規格依據。
- WebRTC 的媒體保護：標準 RTP 媒體由 DTLS-SRTP 保護，Data Channel 走 SCTP over DTLS——兩者是不同路徑，見 RFC 8827。
- SRT 的 latency 是一個可設定參數，這是協定設計本身，不是實作差異。
- SRT 自 1.5 版起支援 connection bonding（broadcast / backup / balancing 三種模式）。
加密與 DRM
- FairPlay 只支援 cbcs 加密模式；Widevine 與 PlayReady 支援 cenc 與 cbcs。因此 CMAF ＋ cbcs 可以用同一份分片服務三家 DRM。這是格式層面的事實，有 Apple 官方文件與各 DRM 規格支撐。
- Widevine 分 L1/L2/L3 三個安全等級，L3 在軟體中解密。
- JWT 的實作陷阱清單（演算法白名單、
kid取用限制、用途隔離、iss/aud/exp驗證）見 RFC 8725。 - DPoP 的機制（發送者綁定、
ath、nonce、重放檢測）見 RFC 9449。
數學恆等式
bpp = bitrate ÷ (width × height × fps)。- 出流頻寬 = 平均碼率 × 同時觀看人數；每用戶每小時 GB = Mbps × 3600 ÷ 8。
- HLS 延遲 ≈ 分片長度 × 緩衝分片數 ＋ 其他環節。
- A/B 浮水印的識別時間 ∝ 載荷位元數 × 分片長度。
B 級：機制上必然成立的推論
沒有單一文件直接寫明，但從機制可以直接推出，且被多方獨立實作驗證：
- TTL 到期不等於斷流。 HLS 因為逐分片請求所以接近「到期即停」；WebRTC 連線建立後不再查詢授權，必須由媒體節點執行伺服器端租約。這是 RTP 連線模型的直接後果。
- CDN 簽名授權不提供即時撤銷。 簽名在有效期內恆為有效，CDN 無從得知後台的停權動作。
- 鑑權必須發生在快取命中之前，否則第一個合法請求把內容帶進快取後，後續無憑證請求也會拿到 200。
- A/B 浮水印依賴「分片」這個單位，而 WebRTC 的 RTP 流沒有這個單位，所以 OTT 方案不能直接移植。
- 並發計數跨區相加在網路分區時會放大額度，必須原子執行。
- 逐會話個體化編碼把成本從「每條流」變成「每個觀眾」，與 SFU 轉發的成本模型互斥。
- 低延遲必然降低抗抖動能力，因為緩衝就是抗抖動的全部來源。
- GOP 必須 ≤ 分片長度，否則切不出分片。
- B 幀必然增加編碼延遲，因為它依賴尚未到達的未來幀。
C 級：量級參考，數字因實作而異
這些方向正確、廣泛採用，但具體數字差異很大，且多數來源是供應商：
- 各協定的延遲數字（WebRTC 0.2–0.5 秒、LL-HLS 2–6 秒、SRT 0.5–2 秒、RTMP 2–5 秒、傳統 HLS 10–30 秒）。這些在本專欄中一律當成量級使用。流通的數字有兩個系統性問題：「協定延遲」與「glass-to-glass」常被混用（前者明顯較小），而且幾乎沒有來源說明測試網路條件。
- codec 的碼率節省百分比（H.265 相對 H.264 約 25–50%、AV1 約 30–50%）。實際數字高度依賴內容複雜度、編碼器實作、preset 與評估指標（VMAF / PSNR / 主觀）。同一組數字在不同內容上可以差一倍。
- per-title / per-shot 編碼的節省幅度（流傳的 18–22% 說法）。這類數字幾乎都來自點播場景，直播因為無法預先分析整個內容，ROI 明顯較低——把點播數字套用到直播預算上是常見的高估。
- ABR 階梯的建議值（相鄰階 1.5–2 倍、5 階左右）。這是廣泛實務共識，但沒有理論最優解。
- 唇音同步的容忍範圍（影像領先約 +45 ms 到落後約 −125 ms）。來自廣電領域的經驗區間，個體差異大。
- 音訊響度目標 −16 到−14 LUFS。平台政策會變動。
- AV1 即時編碼的可用 preset 區間。硬體支援度與編碼器版本變動很快，任何具體說法半年內就可能過期。
- 方案文件中的所有參數（Launch Token 30–60 秒、Playback Token 60 秒、租約 15 秒、撤銷 P95 ≤ 3 秒等）。文件本身明確標示這些是「待壓測確認的參考設計」，不是承諾值——引用時必須保留這個限定。
D 級：應視為行銷話術，要求提供測試方法
遇到以下說法，正確反應是要求對方提供測試樣本、攻擊類型與誤判率，而不是採信：
「我們的方案能 100% 防止盜播。」 不可能。合法觀看之後可以外部攝影機翻拍，沒有任何技術能阻止。可信的說法只會是「縮短存活時間」「提高成本」「可追溯來源」。
「浮水印幾秒就能識別出盜播者。」 識別時間 ∝ 載荷位元數 × 分片長度，有數學下限。方案文件直接寫了「不能承诺几秒必然识别」。要問的是：載荷多少位元？分片多長？在哪些攻擊下測的？錯歸因率多少？
「我們支援 DRM，所以內容是安全的。」 DRM 不防盜連、不防共用帳號、不防錄屏轉播。而且「支援 Widevine」沒有資訊量——要問的是強制要求哪一個安全等級，以及不滿足時降級還是拒播。
「上了 token 鑑權就不會被盜連。」 要問：所有入口都保護了嗎？（備用網域、低碼率階、音軌、字幕、金鑰端點、直接打源站）鑑權發生在快取命中之前嗎？
「我們的 CDN 支援即時撤銷。」 CDN 原生簽名機制做不到這件事。要問的是撤銷事件如何傳播到邊緣、邊緣如何本地判斷、以及有沒有執行確認（ACK）。
「VPN 偵測準確率 90% 以上。」 這類數字全部是自報，而且誤判率幾乎從不公布。誤判直接傷害合法使用者（企業 VPN、CGNAT、出差旅行）。
任何沒有說明測試網路條件的延遲數字。 在理想區網測出來的 200 ms，與跨國行動網路的體驗沒有關係。
E 級：本專欄中屬於我的判斷
以下是我的編輯判斷，不是任何來源的主張，應該當成起點而非結論：
- 「H.264 在 2026 年對直播仍是最安全的預設」——這是權衡（相容性 ＋ 編碼成本 ＋ 延遲可控）後的判斷，不是壓縮效率的結論。
- QoE 指標的排序建議（首幀 > 卡頓 > 失敗率 > 碼率 > 延遲）——有大量產業研究支持「首幀影響跳出率」與「卡頓傷害最大」的方向，但精確排序依產品類型而異。
- 「延遲優化從最大的那塊開始」的診斷順序——算術上成立，但具體順序是我的整理。
- 「架構決定成本的幅度遠大於參數調優」——在混合架構的案例上明顯成立，但不是普遍定律。
- 把方案文件的「四個技術缺口」當成通用檢查表——原文是針對該場景寫的，我判斷它可推廣到任何低延遲 ＋ 強保護的系統，這個推廣是我做的。
🧠 記
公開延遲數字幾乎都來自供應商且常混用兩種定義，當量級用，不當規格用。
codec 節省百分比高度依賴內容，同一組數字在不同素材上可以差一倍。
點播的 per-title 節省不能套用到直播。
遇到「100% 防盜」「幾秒識別」「支援 DRM 所以安全」就要求測試方法，這三句話各自違反一條機制上的硬限制。
方案文件自己標示參數為待驗證，引用時要保留這個限定。
✍️ 實踐
把本專欄的 D 級清單做成一份供應商提問表，下次評估時直接拿出來用：
- 你們報的延遲是 glass-to-glass 還是協定延遲？在什麼網路條件下測的？
- 浮水印：載荷幾位元？分片多長？在錄屏／降解析度／兩輪轉碼／裁剪／多源混合下，檢出率與錯歸因率各是多少？
- DRM：強制哪一個 Widevine 等級？不滿足時降級還是拒播？
- 能否強制關閉一條已建立的 WebRTC 連線？延遲多少？
- CDN 能否在快取命中之前檢查撤銷狀態？
- 撤銷有執行確認（ACK）嗎？節點狀態落後時的行為是什麼？
- 所有入口（備用網域、低碼率、音軌、字幕、金鑰端點、源站）都鑑權了嗎？
- VPN 偵測的誤判率是多少？怎麼量的？
第 2、4、5 題是分辨「真的做過」與「讀過文件」的分水嶺——這三題沒有實測過的供應商答不出具體數字。
🔗 延伸資源
標準與規格（一手）
- Apple — HTTP Live Streaming——HLS/LL-HLS 規範、FairPlay 內容保護要求。
- IETF RFC 8827 — WebRTC Security Architecture
- IETF RFC 8725 — JWT Best Current Practices
- IETF RFC 9449 — OAuth 2.0 DPoP
- AWS — CloudFront Signed Cookies
開源實作（可讀原始碼驗證行為）
- hls.js、dash.js——播放端 ABR 與 buffer 行為的參考實作。
- OBS — Streaming With SRT or RIST
- FFmpeg 文件——轉碼、打包、SRT 參數的權威說明。
技術寫作（品質較高，但仍屬供應商）
- Mux — Low-Latency Live Streaming for Developers
- Unified Streaming — DRM 文件
- Elecard — RIST and SRT overview
使用者提供的方案文件
- 《真人视频流防盗刷与防盗播技术方案——架构图解版 V2.0》（2026-10-02，20 頁）。拆解見 案例篇。該文件自述為獨立設計、不代表任何特定營運商的內部實現，參數均須壓測確認。
閱讀建議：先讀 Apple 的 HLS 文件與 RFC 8827，這兩份給你最多的結構性理解；協定比較文章一律當成量級參考。供應商的技術部落格值得讀機制說明，但所有數字都要問測試方法。