線上影片是如何播放的：從點擊到畫面

你在 YouTube 上按下播放鍵，一秒之內螢幕上就出現畫面。那一秒裡發生了什麼？考慮到影片並不在你的裝置上、你看的「檔案」根本不以單一檔案的形式存在於任何地方，而且照亮你顯示器的位元組甚至不是來自 YouTube 的伺服器——這一切其實非常驚人。它們來自和你家位於同一個都會區某處的快取——一份預先準備好的副本，以防你或另外一千個觀眾要求觀看那部電影的那一段。

整個流程是這樣的。你的瀏覽器與一台伺服器對話，後者交給它一個描述影片的小型文字檔。播放器讀取該檔案，從幾個畫質選項中挑一個，然後開始向 CDN 索取短的音訊與視訊區塊——通常每塊 2 到 6 秒。這些區塊透過提供一般網頁的同一條 HTTPS 連線抵達。播放器在你的手機或筆電原本就有的硬體上將它們解碼，並把畫面繪製到螢幕。當你正在觀看第一塊時，播放器已經在抓取接下來的三塊。若 Wi-Fi 不穩，它會悄悄為下一塊切到較低畫質版本，讓播放永不停頓。整個迴圈——抓取 manifest、抓取片段、解碼、繪製、測量、調整——正是 Netflix、YouTube、Twitch、Disney+ 和 TikTok 上每一部影片背後默默運作的東西。

這是我們串流系列的支柱文章。我們將以白話文走完整條管線，從一端的攝影機到另一端的螢幕畫面。我們會在不被術語淹沒的前提下，將技術層次說得夠精確，看看哪些服務使用哪些層次組合，並以許多讀者最初來到這裡的實際問題作結：當你看完影片後，能否保留一份副本？

影片串流是把影片以一連串連續編號的短檔案片段透過 HTTPS 送到你的裝置，由一個小型 manifest 檔案引導、即時解碼，並在下一個片段抵達後立即丟棄。

重點摘要 {#key-takeaways}

• 串流不是特殊協定——它是普通 HTTP 之上聰明的設計模式。 manifest 和片段就只是 CDN 上的檔案。
• 你「觀看」的影片並不以單一檔案的形式存在。 它在你的播放器中由一個 manifest 加上數百個小片段重新組成。
• 編碼會為相同內容產生多個位元率變體。 播放器根據即時頻寬測量在它們之間挑選。
• 大多數片段來自鄰近你的 CDN 邊緣節點，而非源伺服器。 邊緣快取就是串流感覺即時的原因。
• 自適應位元率串流是為什麼畫質會在播放途中悄悄改變——播放器在片段之間切換變體以維持緩衝區健康。
• 三層加密可以獨立堆疊：HTTPS 用於傳輸、AES-128 用於片段內容、DRM 用於需要授權的商業串流。
• HLS 和 DASH 占主導地位。 HLS 是 Apple 的規格（RFC 8216、.m3u8）；DASH 是 ISO/IEC 標準（23009-1、.mpd XML）。多數主要服務兩者皆提供。
• 儲存一條串流意味著解析 manifest、抓取每一個片段、處理加密並重新封裝——不是右鍵另存新檔。

簡單的解釋

假設你要把一部劇情片送到全球一億位觀眾手上。這部片很龐大——單一一部 2 小時的 1080p H.264 電影約 4 到 8 GB——觀眾連線從千兆光纖到行進中列車上的不穩 4G 都有。你不能把同一個巨大檔案送給每個人。你甚至送不對檔案：列車觀眾需要低位元率版本，光纖觀眾想要高位元率版本，而當列車觀眾在電影中途切到 Wi-Fi，你必須在不重新開始播放的情況下幫他升級。

業界最後採用的模式簡單到讓人覺得反高潮。把電影切成幾百個短片，每片以幾種畫質編碼，把所有片段儲存在世界各地的伺服器上，讓觀眾的播放器決定下一個要播哪一片。 就這樣。所謂「串流」背後其實只是依特定順序透過網路抓取資料夾裡的檔案。

整個生命週期從一端到另一端是這樣：

1. 攝影機或渲染引擎擷取原始畫面。 對直播來說是真正的攝影機；對隨選視訊來說是製片廠交付的成品母帶。
2. 編碼器將原始畫面壓縮成編碼器格式——視訊是 H.264、H.265 或 AV1，音訊是 AAC 或 Opus。編碼器通常從一個輸入產出多個不同位元率的輸出。
3. 封裝器將編碼後的串流切成短片段並寫出 manifest。 每個變體成為自己的片段資料夾加上各自的 manifest；變體列在頂層的主 manifest 裡。
4. 片段和 manifest 上傳至源並複製到 CDN。 Cloudflare、Akamai、Fastly、AWS CloudFront——服務所使用的任一 CDN——將檔案快取到世界各地的邊緣節點。
5. 你按下播放。 你的播放器下載 manifest、挑一個變體、從鄰近的 CDN 邊緣節點抓取前幾個片段，並開始解碼。
6. 播放器解碼每個片段並繪製畫面到你的螢幕，緩衝區領先你正在觀看的位置幾秒。
7. 播放器在片段抵達時測量頻寬，並在片段之間調整變體，讓畫質符合你的即時連線。

整條管線就是這樣。沒有別的事情在發生——沒有特殊伺服器、沒有專屬協定在線上、沒有魔法。每個步驟用的都是你只要有耐心就能寫腳本對付的工具與格式。聰明之處在於設計：每個片段夠短，可以在它們之間切換變體；manifest 夠小，所以往返時間很短；片段像任何其他靜態檔案一樣可快取；播放器跑在已經能解碼藍光和 FaceTime 通話的同一個硬體上。整個串流網站就是用 HTTPS、檔案和時序蓋出來的。 我們接下來會講的協定和編碼器，只是讓這些零件在規模上互通的慣例。

串流影片實際運作的方式

這是本支柱文章的技術核心。我們會從頭到尾走完整條管線。讀完之後，你應該能打開任何串流網站的網路面板，並指認每個請求屬於哪個階段。

攝影機 → 編碼器 → 封裝器 → 源 → CDN 邊緣 → 播放器 → 解碼器 → 螢幕

這個圖就是整條路徑。下面的每個概念——位元率階梯、manifest、片段、ABR、加密——都落在那條箭頭的某一點上。

源端與編碼

從原始影片開始。對直播而言那是攝影機（遊戲串流的話則是螢幕擷取），以 1920×1080、每秒 60 影格產出未壓縮的畫面。未壓縮的話大約是每秒 3 Gbps。沒有人會把原始影片透過公開網際網路送出去。第一個工作就是壓縮。

視訊編碼器藉由利用時間冗餘（大多數像素和上一影格的像素相似）和空間冗餘（影像中大多數區域和鄰近區域相似），將原始畫面轉成壓縮位元流。2026 年的主流編碼器有：

• H.264（AVC）——2003 年標準化。雖老但仍是網際網路上支援最廣的編碼器。過去 15 年內生產的每一台裝置都能硬體解碼它。
• H.265（HEVC）——在相同畫質下比 H.264 大約多 50% 的效率。受權利金限制，這拖慢了它在網路上的採用，但在手機、智慧電視和 Apple 平台上已經無所不在。
• AV1——免權利金、開放，比 HEVC 略具效率優勢。YouTube、Netflix 和 Vimeo 是大型的 AV1 發佈者。截至 2025–2026 年，硬體解碼支援終於到處都有。
• AAC 和 Opus——音訊編碼器。AAC 在 HLS 中是強制的；Opus 主導 WebRTC，並在 DASH 中越來越常見。

同樣的內容幾乎一定會被編碼成多個位元率變體。典型的編碼階梯看起來像這樣：

表中的每一列都是對同一個來源獨立的編碼。它們在時間上對齊，因此播放器可以在同一個牆鐘時刻於變體之間切換，而不必重設解碼器。關於每個變體內部實際包含的內容——容器 vs 編碼器——詳見像 MP4 的容器與像 H.264 的編碼器。

封裝——片段與 manifest

編碼之後是封裝：將每個變體的位元流切成稱為片段的短區塊，並寫出列出它們的 manifest。

片段通常是 2 到 10 秒的視訊和音訊。它們在關鍵影格邊界（位元流中的 I-frame）切開，這樣播放器才能從任一片段的開頭開始解碼。當 manifest 宣告 EXT-X-INDEPENDENT-SEGMENTS（HLS）或 DASH 中的對應宣告時，每個片段都保證可以獨立播放；缺少該宣告時，部分片段可能依賴更早片段中所攜帶的資料。

片段容器格式各有不同：

• MPEG-TS（.ts）——傳統 HLS。原本是 1990 年代衛星／有線廣播格式，對位元錯誤具備穩健性。仍在使用中，但正逐漸被淘汰。
• Fragmented MP4（.m4s，有時是 .mp4）——現代 HLS 和整個 DASH 使用的格式。和一般檔案同樣是 MP4 容器，但被切成片段，每片各自有 header，因此可獨立播放。
• CMAF——Common Media Application Format（ISO/IEC 23000-19）是 fragmented-MP4 的設定檔與封裝約束，並非 .ts 和 fMP4 的合併。它精確地定義 fMP4 片段該如何結構化，讓同一組 fMP4 檔案可被 HLS .m3u8 和 DASH .mpd 同時引用。現代服務出貨 CMAF，而非依協定重複位元組；傳統 .ts 片段仍與其並存，供無法處理 fMP4 的舊版 HLS 用戶端使用。

manifest 本身有兩種形式：

• HLS manifest 是 .m3u8 文字檔。一個主播放清單列出變體及其頻寬；每個變體有一個媒體播放清單，列出片段 URL 與時長。詳見一個 m3u8 檔案實際包含什麼以了解完整解析。
• DASH manifest 是 .mpd XML 檔案。單一檔案以樹狀結構描述整個呈現——adaptation sets、representations、segment timelines、BaseURLs。詳見 DASH 與它的 .mpd manifest，與 HLS 進行對比。

兩種設計做的是同一件事：manifest 告訴播放器有哪些變體存在、每個片段位於何處，以及每個片段有多長。其餘的就交給播放器。

CDN 分發

當片段和 manifest 以檔案形式存在後，串流服務會將它們上傳至源伺服器——通常是 S3 或 R2 之類的物件儲存——並讓內容傳遞網路將它們複製到全球各地的邊緣節點。你會在網路請求中看到的 CDN 包括 Akamai、Cloudflare、Fastly、AWS CloudFront、Google 的邊緣網路，以及 Netflix（Open Connect）和 YouTube 在 ISP 內部運作的私有 CDN。

CDN 對串流如此關鍵的原因是可快取性。片段是 URL 不變的靜態檔案。一個區域內第一位觀眾從源拉下片段；邊緣節點將它快取；接下來一兩個小時內，該區域內每位觀眾都從距離只有幾十毫秒的伺服器取得它。對熱門 YouTube 影片而言，大多數片段請求從來不會碰到 YouTube 的源——它們是由物理上就在你的 ISP 機房內的快取盒提供。

這也是串流為何擴展性如此良好。在東京新增一百萬位同時觀眾並不會給加州新增一百萬次往返——只會給東京邊緣節點增加負載，而該節點原本就有那個檔案。在這種數學上的寬容是 2010 年前任何串流協定都做不到的。

播放器的工作流程

現在我們回到你的裝置。你的瀏覽器載入頁面，頁面啟動一個 JavaScript 播放器（通常是 shaka-player、hls.js、video.js 或某家廠商在這些之上的客製版本），播放器要求頁面的 <video> 元素開始播放。從那裡開始，播放器跑一個緊湊的迴圈：

1. 抓取 manifest。 一次 HTTPS GET。回應是幾 KB 的文字。
2. 解析 manifest 並挑選初始變體。 播放器根據頻寬估計（由最近歷史或裝置的網路資訊播種）、裝置的螢幕解析度，以及安全邊際來挑選，使第一個片段不致卡頓。
3. 抓取前幾個片段。 現代播放器透過單一 HTTP/2 或 HTTP/3 連線並行處理。片段同時抵達。
4. 將片段位元組推入瀏覽器的 Media Source Extensions 緩衝區。 MSE 是 W3C API，讓 JavaScript 以程式化方式餵入 <video> 元素的影片資料。瀏覽器內建的解碼器接手處理。
5. 解碼並繪製。 解碼器——基本上每台過去十年內生產的裝置都支援硬體加速——將壓縮畫面轉成原始像素，GPU 以影片的影格率繪製它們。
6. 持續填滿緩衝區。 使用者觀看片段 N 時，播放器正在抓取片段 N+1、N+2、N+3。
7. 每個片段重新評估。 每次下載完成後，播放器都有了關於連線速度的新資料。它用這個來決定下一個片段是否要切換變體。

播放器程式碼的大多數都是簿記工作：追蹤緩衝區健康狀況、重試失敗的片段抓取、處理拖曳與暫停、插入廣告片段、切換音訊軌道、渲染字幕。串流的部分在概念上很小——抓取、解碼、重複——而工程的複雜度都活在它周圍的所有邊角情況裡。

自適應位元率（ABR）

自適應位元率是讓整套安排值得使用的關鍵功能。沒有 ABR 的話，播放器會挑一個畫質、卡在那兒，並在連線無法維持時立刻重新緩衝。有了 ABR，播放器在每個片段上測量頻寬，並在飛行中切換變體。

基本迴圈是這樣的。每個片段下載完成後，播放器計算有效頻寬：片段大小除以下載時間。把它和近期測量的移動平均比較。若頻寬趨勢向下，下一個片段請求送往較低位元率變體。若頻寬趨勢向上而緩衝區健康，播放器便往上爬。決策在片段之間做出，永遠不在片段中途，因此切換是無縫的。

實際的 ABR 實作更為精細。它們追蹤緩衝區佔用率（健康的緩衝區可以承擔較高的變體；正在抽乾的緩衝區必須迅速下降）、考量螢幕解析度（沒必要對 720p 筆電串流 4K），並使用預測模型——移動平均、低通濾波器，有時是機器學習估計器——以避免在變體之間擺盪。2026 年的兩大主流 ABR 演算法是 BOLA（緩衝區為基礎）和 MPC（模型預測控制），兩者都出現在開源播放器中。完整剖析詳見每個現代播放器內部的 ABR 邏輯。

使用者看得到的結果是：你不用選擇畫質。播放器逐秒替你選，而且切換通常是看不見的。當看得見時——當你在 Netflix 畫面上注意到突然的柔焦——那是 ABR 為了讓播放連續而挑了較低的變體。

加密：經常被混為一談的三層

串流中的加密比一般人以為的更複雜，三個獨立層常被混淆。它們不是同一回事。

HTTPS = 傳輸安全。 每一條現代串流都透過 TLS 提供。這保護位元組免於網路上的竊聽者：ISP、Wi-Fi 攻擊者或企業代理伺服器無法讀取流過它們的內容。HTTPS 並不阻止接收端瀏覽器讀取位元組——它嚴格只是線上的事。

AES-128 片段加密 = 內容層。 HLS 和 DASH 都支援以 CBC 或 CTR 模式的 AES-128 加密片段本身。manifest 攜帶金鑰 URL；播放器透過 HTTPS 抓取金鑰，並在解碼之前解密每個片段。這是內容層的保護：即使有人取得位元組，它們依然無用，但金鑰 URL 本身就是入口。能存取金鑰 URL 的人就能解密片段。許多直播和創作者平台使用 AES-128 片段加密作為基本保護層。

DRM = 由授權伺服器把關、由硬體支援的解密。 Widevine（Google）、FairPlay（Apple）和 PlayReady（Microsoft）在片段加密之上加了一層政策。片段仍然以 AES 加密（在 MPEG Common Encryption，ISO/IEC 23001-7 之下），但內容金鑰被包裝起來，只有裝置上的受信任執行環境才能拆封。授權伺服器在簽發授權前會檢查訂閱、裝置信任度與地區。解密發生在硬體支援的安全模組中——GPU 直接接收已解密的畫面，不會經過應用程式記憶體。這就是保護 Netflix、Disney+、Apple TV+ 與多數付費串流的方式。深入了解請見 Widevine 和 FairPlay 如何把關高級串流。

這些層次堆疊在一起。一條 Netflix 高級串流使用 HTTPS 作傳輸、在 CENC 下加密的 CMAF 片段，以及 Widevine 或 FairPlay 用於授權閘控的金鑰傳遞。一條 Twitch 直播只使用 HTTPS。付費課程平台可能同時使用 HTTPS 和 AES-128 片段加密，但沒有 DRM。知道哪些層次在運作，就告訴你存取位元組的技術門檻實際上是什麼——以及合法使用的邊界在哪裡。

即使是儲存未加密的串流也需要依序、正確地說出所有那些協定，並處理播放器默默處理的邊角情況。VidMost 就是為了在背景做這些工作而設計——manifest 解析、片段抓取、AES 處理、透過內嵌 Widevine L3 處理 DRM、容器重新封裝——讓使用者看得到的步驟只剩下「貼上 URL、得到 MP4」。

你在真實世界中看到的它

上面這條管線基本上描述了 2026 年每一個商業串流服務。差異在於各家服務挑了哪些協定、編碼器和 DRM，以及它們如何與你的裝置協商。

• YouTube。 在網頁與 Android 上的主要協定是 MPEG-DASH，對 Safari、iOS、AirPlay 和大多數智慧電視則提供 HLS。幾乎所有內容都是 CMAF——一組 fMP4 片段同時服務兩種 manifest。編碼器：相容性用 H.264，多數播放用 VP9，支援裝置上的高解析度串流用 AV1。電影／電視租借用 Widevine 和 FairPlay DRM；使用者上傳的影片不加密。
• Netflix、Disney+、Apple TV+、HBO Max、Prime Video。 全部依用戶端混合使用 HLS 和 DASH，以 CMAF 作為共同片段格式。DRM 是強制的——Widevine、FairPlay 或 PlayReady 由裝置選擇。編碼器包括 H.264、H.265、AV1 和 Dolby Vision/Atmos 疊加。授權伺服器在每次播放時強制執行地區、訂閱與裝置信任。Netflix 在許多 ISP 內部運作自己的 CDN（Open Connect）。
• Twitch。 僅使用 HLS，.ts 片段仍常與 CMAF 並存。直播在低延遲變體上延遲 2 到 5 秒，在標準變體上 15 到 30 秒。片段未加密——Twitch 的保護模式是身分與帳號層級，而非內容加密。
• Bigo Live、OnlyFans 直播、Chaturbate、Fansly。 以 HLS 為基礎的直播串流，通常使用未加密片段與短（2 秒）區塊以追求低延遲。瀏覽器端播放使用 hls.js 或 Safari 原生 HLS 支援。
• Vimeo、Mux、Cloudflare Stream、JW Player。 託管影片平台。它們會自動將上傳內容封裝為 HLS 和 DASH 兩種格式，並透過自己的 CDN 傳送。Cloudflare Stream 提供 CMAF；Mux 預設 HLS。DRM 在付費方案中可選。
• 體育與新聞——ESPN、DAZN、BBC iPlayer、Sling TV。 使用 HLS 或 DASH 加 DRM，常將 Widevine + FairPlay + PlayReady 一起封裝，讓同一組編碼片段服務每個裝置。低延遲 HLS（LL-HLS）是這裡的趨勢——把過去落後廣播 30 秒的直播活動拉到 3 秒內的延遲。
• TikTok、Instagram Reels、YouTube Shorts。 短影音對最小的片段使用 MP4 漸進下載，對超過一分鐘的內容則使用 HLS 或 DASH。CDN 與編碼器的選擇和長影音服務相同。

不同表面，同樣的機制。故事是帶有變化的重複：每個服務挑一種 manifest 格式、一條編碼器階梯和一個 DRM 組合，然後在數十億觀眾上跑同一個抓取-解碼-繪製迴圈。

如果你想儲存影片，這意味著什麼

了解管線後，一個實際的事實就變得很明顯：沒有單一檔案可以儲存。你「正在看」的「影片」是由你的播放器從一個 manifest 加上數百個小片段重新建構出來的，這些片段即時抓取、邊飛邊解碼，在下一批抵達時就被丟棄。瀏覽器「另存為」拿到的是 manifest——裡面沒有任何影片位元組的小型文字檔。

手動取得可觀看檔案的路徑很長。抓取並解析 manifest（HLS .m3u8 或 DASH .mpd）。挑選正確的變體——通常是你儲存空間能吸收的最高頻寬版本。列舉每個片段 URL。在簽署 URL 過期之前全部抓回來（30 分鐘影片配上 6 秒片段就是 300+ 個請求）。若存在 EXT-X-KEY，抓取 AES-128 金鑰並解密每個片段。若串流受 DRM 保護，沒有能簽發授權的 CDM，這些根本都不會成功——而即使有，已解密的位元組永遠不會離開安全模組。一旦你拿到純片段，就把音訊和視訊重新封裝到單一 MP4 或 MKV 容器。希望你選對了變體；不然就換一個重來一次。

正確的工具會把那條管線壓縮成一個使用者動作。VidMost 解析 HLS 和 DASH manifest，挑選可用的最高畫質變體，從你瀏覽器原本就在通訊的同一個 CDN 並行下載片段，自動處理 AES-128 片段加密，在 L3 播放可行之處支援 Widevine L3 的 DRM 保護串流（畫質可能受服務與 DRM 等級限制——高級平台通常將 L3 上限設在 480p–720p），並把所有東西重新封裝成可在任何媒體播放器中播放的乾淨 MP4。協定層消失了。你貼上 URL，就拿到檔案。

對你有合法觀看權的內容——你付費的講座、想封存的直播、你自己的廣播、自由授權的影片——這就是整個工作流程。本文所描述的管線正是這款工具替你導覽的東西。

常見的陷阱與誤解

關於串流的一些信念反覆出現。值得糾正。

• 「串流使用特殊協定。」 並非如此。現代自適應串流跑在普通 HTTPS 上——和提供 HTML 與 JPEG 的同一個協定。manifest 與片段是 CDN 上的靜態檔案。HLS 或 DASH 中的「協定」只是那些檔案內容的慣例。
• 「我看的時候檔案正在下載。」 並不完全是。片段在剛好要播放時下載，並在下一個抵達時被丟棄。你的裝置從未持有整段影片。這就是為什麼「停止工作階段」生效，也是為什麼當位元組停止抵達時串流工作階段就會崩潰。
• 「頻寬越高，畫質越好。」 只在你的頻寬穩定時成立。100 Mbps 連線在十秒內掉到 2 Mbps，提供的體驗會比穩定的 8 Mbps 還差。編碼階梯也限制了你——若最高的變體是 5 Mbps，超出該值的頻寬不會買到更多畫質。
• 「卡頓代表網路很慢。」 有時是。但同樣常見的是編碼階梯太稀疏（沒有變體符合當前頻寬）、CDN 邊緣未命中快取、對等互連壅塞，或播放器的 ABR 演算法反應太慢。卡頓是播放器在請求時間——並非對你的網路速度下定論。
• 「DRM 和加密是一樣的。」 不一樣。加密是數學運算——需要金鑰的擾亂位元組。DRM 是圍繞那個加密的政策系統：控制誰能拿到金鑰的授權伺服器、使用金鑰的受信任執行環境，以及決定哪台裝置能播放哪些內容的合約執行層。加密是鎖；DRM 是警報系統、金鑰分發與撤銷政策的綜合體。
• 「MP4 是串流格式。」 不是。MP4 是容器——包裝音訊、視訊與中繼資料的檔案格式。HLS 和 DASH 是串流協定，可以攜帶 fragmented MP4 片段。一般 .mp4 檔案不是串流；它是漸進下載。你在 HLS 和 DASH 中看到的 CMAF 片段衍生自 MP4，但結構非常不同。

一旦你內化了管線，大多數混淆就會消失。串流是檔案加時序——其餘都是細節。

結語

網際網路一開始就用送出其他東西的方式來送影片：透過 HTTP 送檔案。然後它開始聰明地選擇要送哪些檔案、以什麼順序、什麼畫質、從哪個邊緣快取、用什麼硬體解碼。那種聰明的模式——manifest 加片段加自適應位元率加 CDN 快取——是串流感覺即時、擴展到數十億觀眾，並在真實世界網路的混亂現實中存活的全部原因。沒有秘密協定、沒有專屬伺服器、沒有特殊魔法。只有檔案、時序和橫跨整個技術堆疊的非常好的工程。

如果你寧可完全跳過協定層、直接儲存影片，VidMost 會在背景處理 HLS、DASH、fMP4、AES-128 和 Widevine L3——manifest 解析、片段抓取、加密處理、寫出 MP4。

延伸閱讀

• 什麼是 HLS 與 M3U8？——大多數串流仰賴的播放清單與片段設計。
• MPEG-DASH 與 HLS 對比——各協定何時勝出，以及為什麼多數串流服務兩者皆提供。
• 自適應位元率串流解析——每個現代播放器內部的 ABR 邏輯。
• 影片容器 vs 編碼器——片段內部實際上是什麼。
• 什麼是 DRM 保護內容？——Widevine、FairPlay 和 PlayReady 如何把關高級串流。