這篇文章介紹網路影音服務的三大類型——點播（VOD）、直播、錄播——並以直播為主軸，拆解一個完整直播流程的每個環節：採集、編碼與封裝、推流、串流伺服器、拉流、解碼與播放。文末附上 RTMP、HTTP-FLV、HLS 三大傳輸協定的比較表，幫助你在架設串流服務時選對協定。
網路串流服務是怎麼發展起來的？
近年來影音相關的服務越來越火紅，許多的社交軟體都用直播影片來取代舊有的圖文內容。雖然網路影音服務在 2000 年左右就已經出現，但由於當時的移動設備和網路頻寬的限制，使得網路影音的發展受到很多限制。而在 2013 年後網路直播開始爆發，進入了直播影片的年代，一開始的網路直播以 PC 為主，而在移動設備普及後，各種社群媒體的 APP 更是紛紛支援直播串流功能。
因為直播串流的普及、電腦設備及網路速度的進步，也新興了如 Youtuber、實況主、直播主等這種專門經營此區塊的行業，可謂是非常火紅且受到矚目的一個領域。近年來，通信行業也更多的走向網路化，通訊軟體如 Line、Facetime 等，漸漸取代了過去的電話、簡訊。最近因 5G 和 IoT 的發展，未來應有更多的領域會走向網際網路化。
點播、直播、錄播有什麼不同？
所有網路影音相關的服務，大致分為『點播』、『直播』和『錄播』三種。
1. 點播（Video On Demand, VOD）
其中 Demand 意為需求，從字面上理解點播，指的是使用者點選想要看的影片，並將該影片使用實時串流的方式播放出來。相關的服務如 Netflix、Apple TV、HBO 等。
2. 直播（Live broadcast）
直播音視頻會以媒體流的形式推到服務器上（推流）。如果有觀眾收看直播，服務器收到用戶的請求後，會把視頻傳輸到網站、APP、客戶端的播放器，即時播放串流影片。相關的服務平台有 Youtube、Facebook Live、Twitch 等。
3. 錄播
一個完整的錄播系統包含了錄製剪輯、直播推送、影片處理等核心功能，配備了相關的軟體和硬體。能夠按照標準產出比較高質量的影片內容，較多使用在線上教學系統上。
直播服務的原理是什麼？完整流程有哪些環節？
一個完整的直播服務會牽涉到非常多面項領域的技術，從視頻/音頻處理，圖形處理，視頻/音頻壓縮，CDN 分發，即時通訊等技術，每個項目都有很深的技術背景，都需要以年來計算的去鑽研，因此許多部份只會提及基本概念（但光概念就有一大堆艱深知識了…XD…推薦這個系列文，把許多概念知識都整理的很清楚：30天之即時網路影音開發攻略(小白本)）。
一般來說，一個影片的直播流程要經過以下環節：
```
採集影像 → 影像處理 → 編碼 → 封裝 → 推流 → 串流伺服器 → 拉流 → 解封裝 → 解碼 → 播放
```
各個環節都有相關的技術或現成可使用的軟體，下圖為以 SRS 伺服器的流程為例：
上述的事情發生在三個端點：直播主的電腦、串流伺服器、觀眾的電腦，各個事件發生的地點如下圖：
以下分別說明各個環節：
1. 採集
從系統的採集設備中獲取原始音視頻數據，將其輸出到下一個環節。一個影片的採集涉及兩方面數據的採集：音頻採集和影像採集，它們分別對應兩種完全不同的輸入源和數據格式。
2. 編碼與封裝
對於視訊資料而言，視訊編碼的最主要目的是資料壓縮。因為動態影像的畫素形式，資料量極為巨大，儲存空間和傳輸頻寬完全無法滿足儲存和傳輸的需求。舉例來說，若影像的每個畫素的三個顏色 RGB 各需要一個位元組儲存，每一個畫素需要 3 位元組，解析度 1280×720 的影像的大小為 2.76M 位元組，若每秒 FPS 為 25 偵，所需的位元率會達到 553Mb/s。這樣的資料量無論是儲存或傳輸都不可能，因此編碼非常重要，編碼性能、編碼速度和編碼壓縮比會直接影響整個流媒體傳輸的用戶體驗和傳輸成本。
視訊資訊之所以存在大量可以被壓縮的空間，是因為其中本身就存在大量的資料冗餘。其主要型別有：
>
1. 時間冗餘：視訊相鄰的兩幀之間內容相似，存在運動關係
2. 空間冗餘：視訊的某一幀內部的相鄰畫素存在相似性
3. 編碼冗餘：視訊中不同資料出現的概率不同
4. 視覺冗餘：觀眾的視覺系統對視訊中不同的部分敏感度不同
>
3. 推流
推流是影響整個直播串流能不能順暢播放的最根本因素，若是步驟 2 的影片編碼的編碼器效能不好、網路速度不夠，或者編碼的壓縮品質不佳，那麼後面的串流服務再怎麼好，使用者的影片觀看體驗和順暢度也不會好。因此步驟 2 的編碼，會連帶影響到步驟 3 的推流的順暢度。
因此，像一些推流軟體如 OBS，會自動偵測直播主的電腦配備和網路頻寬，去選擇適合的影片壓縮位元率（影響影片的品質）、編碼格式（VP9、MPEG 或 H.264）、編碼工具（如 Quick Sync H.264 或 x264），以及設定適合的 buffer，來達到讓推流能夠順暢的目的。
現有推流最廣泛被使用的通訊協定為 RTMP（Real Time Messaging Protocol），大部份的推流軟體都使用這個協定去做推流。
4. 串流伺服器
主要的工作為接收推流、轉發給拉流客戶端。現在的直播服務由於需要支援行動設備，隨著 flash 從網頁裡被淘汰，網頁端多已不能支持 rtmp 流協定的播放。但因推流的協定仍多為 RTMP，因此大多需要經過轉碼的動作，轉為 HLS 或 HTTP-FLV 的格式，以支援行動端的播放。這部份伺服器的轉碼工作也會影響到直播的延遲時間。
所謂『延遲』(latency) 就是從直播端到播放端的時間差，造成延遲的原因有很多，因使用網路傳輸，影像串流需要經過編解碼並即時於使用者端播放。考量到網路狀況可能不穩定，又需顧及影片播放的順暢性，客戶端播放器的緩衝設定以及其解碼的速度，也是造成延遲的一大主因。不同傳輸方式其搭配的容器格式亦會影響到延遲的時間，一般來說 RTMP 的延遲時間約為 0.3-1 秒間，HTTP-FLV 約 1-3 秒，而 HLS 則需要至少 10 秒以上的延遲（以最佳狀況來說）。
目前市面上較受歡迎的串流伺服器有：
- FMS：FMS 是 adobe 的流媒體服務器，RTMP 協議就是 adobe 提出來的，FMS 一定是重量級的產品。
- WOWZA：由 Wowza Media Systems 開發的串流媒體服務器軟體
- SRS：本系列文主要探討的串流伺服器，產品定位是商用互動式社群直播伺服器叢集，支持 K8S。
- NGINX RTMP：現在非常火紅並且被廣泛使用的開源伺服器
- CRTMPD：使用單線程異步 socket，在當時處於領先水平，但是當 NGINX 出現後就漸漸淡出大眾視野了
5. 拉流
拉流是指伺服器已有直播內容，根據協議類型（如 RTMP、RTP、RTSP、HTTP 等），與伺服器建立連接並接收數據，進行拉取的過程。因為 RTMP 的協定較容易被防火牆檔掉，因此主要移動端的播放都採用 HTTP 的網路協定去做拉流，包括常見的 HTTP-FLV 與 HLS。
6. 解碼與播放
其實所有的串流都會包括音視頻兩個部份，在解碼時會分別解碼音頻和視頻，並且將兩個搭配起來。在這邊播放會遇到的挑戰，很重要的部份就是 buffer 的設製，buffer 會影響到三個點：『首屏』、『延遲』、『卡頓』。首屏指的是點擊畫面後到第一個畫面出來的時間、延遲是指與直播端的時間差、而卡頓則是影片播放時畫面不順暢的次數或時間。
一般來說，若觀看端的 buffer 時間較長，從點擊到看到第一個畫面的時間也會較長、總延遲時間也會變長，但可以在網路狀況較不穩定下仍能維持一定的播放品質。另外若 buffer 設定的過短，機器的解碼的速度在電腦 lag 時短暫趕不上，就有可能會出現跳屏的狀況（ex: 從 1 秒直接跳到 3 秒），因此這部份也需要經過仔細的調校和設定。
RTMP、HTTP-FLV、HLS 三大傳輸協定怎麼比較？
| RTMP | HTTP-FLV | HLS | |
|---|---|---|---|
| 延遲 | 0.3-1s | 2-3s | 10s+ |
| 傳輸協議 | TCP | HTTP | HTTP |
| 瀏覽器支持 | N | Y | Y |
| 數據分段 | 連續流 | 連續流 | 分段（ts 切片） |
一般來說，在架設串流伺服器時，應考量用途和需求，去決定要使用那一種直播協議，每一種格式都有其優缺點，這邊有相關的比較文章：RTMP、HTTP-FLV、HLS，你了解常見的三大直播協議嗎。
延伸閱讀
- 直播相關教學文章庫：串流、編碼、推流與 SRS 學習資源整理：同樣聚焦 直播、串流，可接著比較不同情境的做法。
- TCP/UDP 協議中的串流協定整理：RTP、RTSP、SRT、QUIC、RTMP 與 HLS：同樣聚焦 串流、RTMP，可接著比較不同情境的做法。
- 為 SRS6 編譯支援 HTTP-FLV 的 FFmpeg：H.265 over RTMP 推流實作：同樣聚焦 RTMP、串流伺服器，可接著比較不同情境的做法。
常見問題
點播（VOD）和直播最大的差別是什麼？
點播是使用者主動點選既有的影片內容，伺服器再以串流方式播放，如 Netflix；直播則是音視頻即時推流到伺服器，觀眾端即時收看，內容是「正在發生」的。兩者在延遲容忍度與架構需求上有明顯差異。
為什麼視訊一定要經過編碼壓縮？
未壓縮的視訊資料量極為巨大：1280×720、25FPS 的影像位元率可達 553Mb/s，儲存與傳輸都不可能。視訊本身存在時間、空間、編碼與視覺四類冗餘，編碼就是利用這些冗餘進行壓縮，編碼性能與壓縮比直接影響用戶體驗和傳輸成本。
RTMP、HTTP-FLV、HLS 該怎麼選？
追求最低延遲可選 RTMP（0.3-1 秒），但它走 TCP 且瀏覽器已不支援直接播放；HTTP-FLV 延遲約 2-3 秒且瀏覽器支援；HLS 延遲最高（10 秒以上）但相容性最好、適合行動端與大規模分發。應依用途和需求決定。
什麼是直播的『延遲』（latency）？
延遲是從直播端到播放端的時間差。成因包括編解碼耗時、網路傳輸不穩定、播放器 buffer 設定與解碼速度，以及不同容器格式與傳輸方式的組合。buffer 越長越順但延遲越高，越短則可能卡頓或跳屏。
參考資料
最後更新
2026-08-28（原文發布於 2020-10-13，本文保留原始筆記內容並補上 GEO 結構。）
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2020-10-13