在 HLS 和 HTTP-FLV 之間做選擇，不僅僅是決定哪種格式較新的問題。正確的選擇取決於觀眾需要做什麼、他們在哪裡觀看、平台必須支援多少並發連線，以及應用程式能容忍多大的延遲。公開網路直播、基於瀏覽器的監控控制台和行動即時檢視應用程式可能始於相同的視訊來源，但需要不同的傳輸路徑。
本指南說明每項技術的角色，並展示如何將它們組合到實用的串流架構中。它保留了本質區別：HLS 專為透過標準 HTTP 基礎設施進行可靠、自適應的傳輸而設計，而 HTTP-FLV 透過 HTTP 連線傳送連續的 FLV 串流，通常在瀏覽器播放需要更接近即時時被選用。
首先區分協定、傳輸和容器
HLS、FLV、HTTP-FLV 和 RTMP 這些術語經常被當作描述同一層來使用，但事實並非如此。
-
HLS（HTTP Live Streaming） 是 Apple 最初開發的媒體傳輸協定。它使用播放清單和透過 HTTP 或 HTTPS 傳輸的一系列媒體區段。
-
FLV（Flash Video） 是一種容器格式，可以承載編碼後的音訊和視訊。FLV 本身並不定義串流如何在網路上傳輸。
-
HTTP-FLV 透過 HTTP 連線保持 FLV 串流持續開啟。播放器連續接收媒體，而不是請求播放清單和個別區段。
-
RTMP 是獨立的串流協定，歷史上與 Flash 相關。它在推流或輸入端仍然常見，即使觀眾接收的是 HLS 或其他輸出格式。
這種區分在系統設計時很重要。平台可以從編碼器接收 RTMP，一次性處理來源，然後為不同觀眾群發佈 HLS 和 HTTP-FLV 輸出。因此，選擇傳輸方法不一定需要變更攝影機、編碼器或上游推流協定。
為什麼分段傳輸在大規模場景下表現出色
HLS 將直播或隨選節目分成媒體區段，並在 M3U8 播放清單中列出它們。傳統部署通常使用 MPEG-2 傳輸串流區段，通常以 .ts 副檔名識別。現代 HLS 也可以使用碎片化 MP4（常稱為 fMP4），這為當代編碼和封裝工作流程提供了實用的基礎。音訊和字幕可以作為獨立的轉譯版本與視訊一同提供。
由於播放清單和區段是普通的 HTTP 資源，它們可以透過標準網頁伺服器、反向代理和內容傳遞網路（CDN）來提供。邊緣快取可以將熱門區段保存在靠近觀眾的位置，從而減少對來源的重複流量。這使得 HLS 非常適合公開直播活動、培訓入口網站、行動應用程式和具有地理分散受眾的服務。
自適應位元率傳輸是另一個核心優勢。平台會準備同一節目的多個不同解析度和位元率的轉譯版本。根據當前吞吐量、緩衝區狀態和裝置能力，播放器可以在這些變體之間切換，以保持播放穩定。在行動網路變化中的觀眾可能會接收到較低解析度的版本，而不是經歷完全中斷。
其代價是傳統的 HLS 播放通常需要等待區段建立、播放清單更新和播放緩衝區。實際延遲取決於區段持續時間、播放清單設計、播放器設定和網路條件。低延遲 HLS 可以減少這種延遲，但需要在封裝器、來源、CDN 和播放器之間進行協調支援。應將其視為端對端的設計選擇，而不是在最後階段添加的開關。
區段持續時間應根據服務目標來選擇。較短的區段可以幫助播放器更快地發現新媒體，但也會增加播放清單更新、物件請求和封裝開銷。較長的區段減少請求頻率，可能提高傳輸效率，但可能增加啟動時間並使品質切換反應變慢。編碼器的關鍵幀間隔必須遵循封裝計劃，以便每個轉譯版本在相同位置提供清晰的切換點。
連續 HTTP 串流仍然適用的場景
HTTP-FLV 透過長時間的 HTTP 回應傳送 FLV 標籤。一旦播放開始，媒體資料會透過同一連線持續到達。無需重新整理區段播放清單，因此正確調校的系統通常可以比傳統的分段工作流程更接近即時來源。
這種行為在面向操作員的應用中非常有用，這些場景下人員需要觀察事件並快速反應：視訊監控頁面、生產儀表板、設備監管、遠端檢查以及內部即時檢視系統。它還可以簡化透過已經允許 HTTP 或 HTTPS 流量的網路的傳輸。
然而，不應將 HTTP-FLV 與瀏覽器的原生視訊支援混為一談。Adobe Flash Player 的終結移除了舊的外掛程式播放路徑：Adobe 於 2020 年 12 月 31 日終止 Flash Player 支援，並於 2021 年 1 月 12 日開始封鎖 Flash 內容。因此，現代 HTTP-FLV 播放依賴於 HTML5 播放器，通常使用 JavaScript 解析 FLV 串流，並透過瀏覽器媒體 API 將受支援的音訊和視訊編解碼器饋入解碼器。
這帶來了相容性依賴。瀏覽器必須支援所需的媒體 API 以及 FLV 容器內承載的編解碼器。因此，HTTP-FLV 更適合受控的網頁客戶端和專用應用程式，而非無限制的公開受眾。大量持續連線也會對傳輸伺服器和中間網路裝置造成比可快取的分段物件更持續的壓力。
根據觀看需求匹配傳輸路徑
協定決策應從營運需求出發，而不是從功能清單開始。以下比較提供了一個有用的起點。
| 決策因素 | HLS | HTTP-FLV |
|---|---|---|
| 傳輸模型 | 播放清單 + 媒體區段 | 透過 HTTP 或 HTTPS 的連續 FLV 串流 |
| 典型優先事項 | 穩定播放和廣泛分發 | 降低即時觀看的延遲 |
| 自適應位元率 | 透過變體串流內建於協定中 | 非固有；通常需要應用程式特定的串流切換 |
| CDN 效率 | 高，因為區段可作為 HTTP 物件快取 | 較有限，因為每個觀眾維持一個持續回應 |
| 客戶端覆蓋範圍 | 在 Apple 裝置、行動平台、智慧裝置和網頁播放器生態系中表現強勁 | 在受控瀏覽器或具備相容播放器的專用應用中最佳 |
| 網路變化應對 | 當提供多個轉譯版本時，能很好地處理頻寬變化 | 更敏感，除非應用程式自身提供品質切換邏輯 |
| 營運適合性 | 公開直播、行動觀看、視訊入口網站和大規模受眾 | 監控控制台、內部系統和低延遲瀏覽器觀看 |
當受眾規模不可預測、觀眾使用各種裝置、播放連續性比即時性更重要，或者 CDN 分發屬於計劃的一部分時，請將 HLS 作為主要輸出。當平台控制網頁播放器、受眾已知、同時觀看人數可管理，並且降低即時觀看延遲具有明確的營運價值時，請使用 HTTP-FLV。
在批准任一方案之前，請為每個階段定義延遲預算：擷取、編碼、網路接收、媒體處理、分發、播放器緩衝和解碼。這可以防止將傳輸協定歸咎於其他環節引入的延遲。低延遲輸出無法彌補編碼器長 GOP、過載的轉碼器或配置了較大安全緩衝區的播放器。請在最終生產環境和網路上測量實際結果。
兩種選項都不適用於所有形式的即時通訊。如果使用者必須進行雙向對話或操作需要極緊密互動時序的裝置，則即時通訊技術可能更合適。關鍵點是在選擇傳輸架構之前，將單向視訊分發與互動式媒體區分開。
混合設計可涵蓋更多使用者，而無需複製來源
許多專案並不需要非此即彼的決策。混合平台可以接收一個來源，統一時間戳記和編解碼器，然後為不同客戶端封裝獨立的輸出。
-
接收來源。 透過現場設備支援的推流協定，從攝影機、編碼器、閘道器或上游平台接收直播視訊。
-
檢查媒體。 在決定串流是可直接重新封裝還是必須轉碼之前，驗證編解碼器、解析度、幀率、音訊格式和時間戳記連續性。
-
建立傳輸轉譯版本。 為 HLS 生成自適應位元率階梯。僅為需要且能解碼其媒體設定的客戶端生成 HTTP-FLV 輸出。
-
分離受眾路徑。 將 HLS 透過來源和 CDN 發送，用於外部或大規模觀看。將 HTTP-FLV 透過受控的傳輸叢集路由給營運使用者。
-
套用存取控制。 根據每條路徑使用 HTTPS、短期授權、來源保護和會話政策。
-
測量完整鏈路。 監控接收連續性、轉碼負載、封裝錯誤、首幀時間、緩衝、斷線和端對端延遲。
這種模式避免強迫每個客戶端接受同一種妥協方案。公開觀眾獲得有彈性、可擴展的串流，而操作員可以使用低延遲路徑。媒體平台也成為將舊式來源格式轉換為當前瀏覽器和應用可消費輸出的轉換點。
在重新封裝和轉碼之間選擇
如果輸入的編解碼器已經符合傳輸設定，平台可能只需要重新封裝壓縮媒體。重新封裝會變更容器或輸出結構，而無需解碼和編碼每一幀，因此通常消耗較少的處理資源並保持來源品質。僅當編解碼器支援、時間戳記、關鍵幀放置和音訊參數已經適合目標播放器時才適用。
當目標客戶端無法解碼來源編解碼器、需要多個解析度和位元率，或者必須正規化幀率、音訊格式和關鍵幀結構時，則需要轉碼。它會增加運算成本和處理延遲，因此容量應根據峰值並發頻道數而非平均使用量來計算。硬體加速可以增加頻道密度，但仍需使用所選播放器測試輸出品質和行為。
生產系統還應消除單點故障。使用冗餘來源、受控的播放器重連和經過測試的故障轉移規則，同時避免建立會放大故障的激進重試迴圈。
可避免可預防故障的部署檢查項目
僅選擇協定並不能保證服務的可靠性。上線前，請驗證完整的媒體和網路路徑。
-
確認端點的編解碼器支援。 傳輸可以成功到達播放器，但播放仍然可能失敗，因為瀏覽器無法解碼音訊或視訊設定。
-
保持時間戳記連續。 損壞或非單調的時間戳記可能導致卡頓、音訊漂移和品質切換失敗。
-
使關鍵幀與封裝規則對齊。 HLS 轉譯版本應使用協調的關鍵幀邊界，以便播放器能在無明顯干擾的情況下切換品質。
-
規劃從來源到播放器的 HTTPS。 安全頁面不應請求不安全的媒體，且憑證必須在來源和分發層均有效。
-
測試真實網路條件。 在有限頻寬、封包遺失和短暫中斷下驗證啟動、恢復和品質變化，而不僅僅是在本地網路上測試。
-
根據連線行為規劃容量。 HLS 容量規劃主要側重區段請求、儲存和快取命中率。HTTP-FLV 規劃必須考慮長生命週期的並發連線和持續輸出流量。
-
提供後備策略。 如果首選播放器或格式不可用，應用程式應返回受支援的替代方案或明確的錯誤，而不是無限期重試。
對於大多數面向外部的服務，HLS 是更安全的預設選擇，因為它將自適應位元率播放與成熟的 HTTP 分發相結合。當受管播放器和更低延遲比通用覆蓋更重要時，HTTP-FLV 仍然有用。當同一個直播來源必須同時服務這兩類群體時，混合架構通常是最實際的答案。
常見問題
能否在直播工作流程中新增字幕？
可以。字幕可以在上游生成或在媒體處理期間插入。對於 HLS，WebVTT 字幕轉譯版本是常見選擇。自訂 HTTP-FLV 播放器可能需要獨立的定時文字頻道及其自身的同步邏輯。
直播活動進行時，觀眾可以回退嗎？
如果服務保留了足夠長的直播視窗並且播放器提供時移控制，則可以。在啟用直播回退之前，應定義保留視窗、儲存容量和內容版權。
當視訊頻寬不可用時，播放器能否後退到僅音訊？
可以，前提是平台發佈了純音訊轉譯版本或獨立的音訊串流，並且播放器配置為選擇它。這可以在高度受限的連線上保留關鍵解說或指示。
分析能否區分觀眾退出和網路故障？
僅憑單次斷線事件無法區分。結合播放器事件、心跳間隔、工作階段識別碼、重試行為和伺服器連線日誌，可以更可靠地對退出進行分類。
直播結束後的 URL 應該如何處理？
平台可以關閉直播工作階段、發佈結束畫面，或在處理完成後將使用者重新導向到封存節目。請提前定義轉換方式，以免嵌入式播放器和共享連結在沒有說明的情況下失敗。
