【音視頻】Http-FLV 介紹

一、Http-FLV 原理

HTTP-FLV 是基于 HTTP 協議的 FLV（Flash Video）流媒體傳輸方式。它使用 HTTP 協議而不是傳統的 RTMP 協議來傳輸 FLV 格式的視頻流。HTTP-FLV 在 Web 視頻直播場景中得到了廣泛應用，尤其是在不支持或不希望使用 RTMP 協議的情況下，它為 Web 端用戶提供了流暢的直播體驗

HTTP-FLV 的核心是 “流式傳輸”，而非一次性下載文件，依賴兩個關鍵技術：

FLV 容器格式：FLV 是輕量級容器，僅包含「文件頭（Header）+ 標簽（Tag）」兩部分，無復雜索引結構。

Tag 是數據傳輸的最小單元，分為三類：
- 視頻 Tag（H.264/H.265 編碼）
- 音頻 Tag（AAC/MP3 編碼）：存儲實際媒體數據；
- 腳本 Tag（ScriptTag）：包含元數據（如編碼格式、分辨率、比特率、時長）
HTTP Chunked Encoding（分塊編碼）：HTTP 協議默認是 “請求 - 完整響應”，但 HTTP-FLV 利用 Transfer-Encoding: chunked 響應頭，將 FLV 流切分為連續的二進制塊（每塊 1-2s 數據），服務器實時向客戶端推送塊，客戶端接收后立即解碼播放，實現 “邊傳邊播”。

二、Http-FLV 傳輸過程

HTTP-FLV 需 “推流端 - 流媒體服務器 - 播放端” 三方協作，流程如下：

推流端：通過 RTMP 協議（如 OBS、FFmpeg）將原始視頻流（攝像頭 / 本地文件）推送到流媒體服務器（如 SRS、Nginx-RTMP-Module、EasyDarwin），
服務器轉流：服務器接收 RTMP 流后，會實時接收主播推來的視頻 / 音頻數據（比如通過 RTMP 推流到服務器），并即時封裝成 FLV 格式的 “數據單元”，實時封裝為 FLV 格式（無需完整生成 FLV 文件），然后，服務器會把這些 FLV 數據按 “1-2 秒的播放時長” 切成一塊一塊，并通過 HTTP 端口（80/443）對外提供訪問地址（如 http://xxx.com/live/stream.flv）；
客戶端：按塊處理，收到第一塊數據（1-2 秒的 FLV 內容），立即解析其中的 FLV Tag（提取視頻幀、音頻幀和時間戳），然后調用解碼器（比如 H.264 視頻解碼器、AAC 音頻解碼器）解碼這部分數據，解碼完成后直接播放，不用等后續塊。同時，客戶端會繼續接收第二塊、第三塊… 重復 “接收→解碼→播放” 的流程，直到收到 “大小為 0 的空塊”（直播結束）。
- 瀏覽器通過 flv.js（開源插件）或原生支持 FLV 的播放器（如 Video.js）發起 HTTP GET 請求，獲取流地址；
- 服務器返回 Content-Type: video/x-flv 響應頭，以 Chunked 模式持續推送 FLV 數據塊；
- 客戶端解析 FLV Tag，分離視頻 / 音頻數據，通過 HTML5 <video> 標簽解碼播放。

在這里插入圖片描述

三、Http-FLV 對比HLS、本地FLV

3.1 Http-FLV 特點

優勢：
- 低延遲：基于 Chunked 傳輸，延遲通常控制在 1-5 秒（遠低于 HLS），適合半實時場景（如電商直播、教育直播）；
- 防火墻穿透：使用 HTTP 標準端口（80/443），避免 RTMP 1935 端口被攔截的問題；
- 兼容性：原生瀏覽器雖然不支持，但可以通過 flv.js 庫解析，在 Chrome、Firefox、Edge 等現代瀏覽器運行，移動端也支持。
局限性補充：
- 無原生自適應比特率（ABR）：若網絡波動，需服務器額外提供多碼率流（如 720P/480P），客戶端手動切換；
- 連接穩定性依賴 HTTP 長連接：若網絡中斷，需重新請求并恢復播放，可能丟失部分數據
- 它的傳輸特性會讓流媒體資源緩存在本地客戶端，也就是說保密性不怎么樣；直到目前仍然不兼容iOS的瀏覽器

3.2 HLS 特點

HLS（HTTP Live Streaming）是蘋果推出的基于 HTTP 的自適應比特率流媒體協議，核心是 “切片傳輸”，與 HTTP-FLV 同為 Web 流媒體主流方案，但技術路徑差異顯著。

1. HLS 協議簡述

HLS 將視頻流切分為 10-30 秒的 TS 片段（MPEG-TS 格式，支持 H.264/AAC），并生成一個 M3U8 索引文件（文本格式，記錄 TS 片段的 URL、時長、碼率）。
客戶端先請求 M3U8，再按順序請求 TS 片段播放，支持自動切換不同碼率的 M3U8（如網絡差時切 480P，網絡好時切 1080P）。

2. HTTP-FLV 對比HLS

對比如下：

對比維度	HTTP-FLV	HLS
傳輸協議	HTTP 協議（Chunked Encoding 分塊傳輸）	HTTP 協議（基于 TS 切片 + M3U8 索引）
數據格式	FLV 容器（Tag 結構，二進制流）	TS 片段（MPEG-TS 容器）+ M3U8 索引（文本）
延遲表現	低（1-5 秒），適合半實時場景	高（15-60 秒），切片越長延遲越高
自適應比特率	需額外開發（服務器提供多碼率流，客戶端切換）	原生支持（M3U8 可包含多碼率索引，自動切換）
瀏覽器支持	需 `flv.js` 插件（Chrome/Firefox/Edge 等）	原生支持（Safari 全版本，Chrome/Firefox 需 HLS.js）
設備兼容性	支持 Web 端、Android 端；iOS 需第三方播放器	全平臺支持（iOS 原生支持，Android/Web 需插件）
緩存機制	無持久化緩存（流數據實時播放，不存儲片段）	自動緩存 TS 片段（可離線播放已緩存片段）
帶寬適應性	固定碼率（網絡波動易卡頓）	動態碼率（根據帶寬自動切換，抗卡頓能力強）
部署復雜度	簡單（普通 HTTP 服務器 + 流媒體模塊即可）	較復雜（需切片工具 + 索引生成 + 多碼率管理）
適用場景	低延遲直播（電商、教育、會議）	高容錯直播 / 點播（賽事回放、視頻網站點播）

主要差別：

延遲是關鍵分水嶺：HTTP-FLV 適合需要 “近實時互動” 的場景（如主播與觀眾連麥），HLS 適合對延遲不敏感、追求流暢性的場景（如體育賽事直播）；
自適應能力：HLS 原生支持 ABR，更適合移動端（網絡波動大），HTTP-FLV 需額外開發才能實現類似功能；
兼容性：HLS 在 iOS 端有天然優勢（原生支持），HTTP-FLV 在 Web 端（尤其是 PC）部署更簡單。
HLS 支持加密，通過 “TS 文件加密 + 密鑰授權” 的成熟機制實現內容保護，能有效解決 “未加密流被緩存、竊取” 的問題

3.3 本地FLV 特點

本地 FLV 是存儲在本地設備（電腦 / 手機）的 FLV 文件（如 video.flv），與 HTTP-FLV（流媒體）的核心差異是 “數據形態與傳輸方式”，具體對比如下：

1. 本地 FLV 簡述

本地 FLV 是完整的文件，包含 FLV Header + 所有 Tag（視頻 / 音頻 / 腳本），需通過本地播放器（如 VLC、PotPlayer、暴風影音）加載并播放，無需網絡傳輸（除非從本地服務器讀取）。其播放邏輯是 “加載文件→解析元數據→按時間戳播放 Tag 數據”，支持進度條拖動、倍速播放等交互。

2. Http-FLV 對比本地FLV

對比如下：

對比維度	HTTP-FLV	本地 FLV
數據形態	實時流媒體（無完整文件，僅傳輸數據塊）	靜態文件（完整 FLV 結構，存儲在本地設備）
傳輸方式	網絡傳輸（HTTP 分塊推送，依賴網絡）	本地讀取（從硬盤 / 內存加載，無網絡依賴）
播放機制	邊傳邊播（接收一塊播放一塊，無法提前加載）	可完整加載后播放，或本地流式播放（支持拖動進度條）
延遲表現	網絡延遲（1-5 秒）+ 解碼延遲	無網絡延遲（僅解碼延遲，毫秒級）
存儲需求	服務器存儲（實時生成流，不持久化片段）	本地存儲（需占用設備空間，如 1GB 文件占 1GB 空間）
交互能力	弱（僅支持暫停 / 播放，無法拖動進度條）	強（支持拖動進度條、倍速、字幕加載等）
播放依賴	流媒體服務器 + 瀏覽器插件（如 flv.js）	本地播放器（如 VLC、PotPlayer）
適用場景	實時直播（無本地存儲需求，需網絡）	離線播放（下載后觀看，如本地視頻、離線課程）

主要差異：

“流” 與 “文件” 的本質區別：HTTP-FLV 是 “實時生成、實時傳輸、實時播放” 的流，無完整文件實體；本地 FLV 是 “預生成、本地存儲、按需播放” 的文件；
網絡依賴性：HTTP-FLV 完全依賴網絡（斷網即停），本地 FLV 無需網絡（下載后可離線播放）；
交互體驗：本地 FLV 支持完整的點播交互（如拖動進度條），HTTP-FLV 因是實時流，無法跳轉播放未傳輸的內容。

四、協議場景選擇

選 HTTP-FLV 的場景：
- 需低延遲的 Web 直播（如電商直播、在線教育、企業會議）；
- 網絡環境嚴格（僅開放 80/443 端口，需穿透防火墻）；
- 部署資源有限（僅能搭建普通 HTTP 服務器）。
選 HLS 的場景：
- 對延遲不敏感，但需跨平臺（尤其是 iOS 端）的直播 / 點播（如體育賽事、電影點播）；
- 網絡波動大的場景（如移動端 4G/5G 環境，需自適應比特率抗卡頓）；
- 需支持離線緩存的場景（如用戶希望緩存部分內容稍后觀看）。
選本地 FLV 的場景：
- 離線播放需求（如下載視頻后無網絡觀看）；
- 需高頻交互的點播場景（如反復拖動進度條、倍速播放）；
- 無網絡環境（如飛機、地鐵上的本地視頻播放）。