YouTube 是全球流量最大的影音平台之一，每分鐘有超過 500 小時 的全新影片被上傳至伺服器。用戶上傳的影片格式五花八門（從手機拍的 4K MOV、直播錄製的 FLV 到老舊攝影機的 AVI），檔案大小從幾 MB 到上百 GB 不等。

要在全球數十億種不同的客戶端設備（4K 智慧電視、旗艦 iPhone、低頻寬 3G 網路的廉價 Android 手機）上實現秒開、零卡頓、畫質自適應的播放體驗，背後需要一套極度複雜的分散式影片處理管線。

本文基於 Google Cloud Media Architecture 文獻 與 ByteByteGo System Design 101，深入剖析 YouTube 影片從用戶點擊「上傳」到在全球邊緣節點流暢播放的端到端技術實現。

YouTube 海量影片非同步上傳與分塊轉碼串流架構 展示從客戶端可中斷續傳分塊上傳 (Chunked Upload)，經 API 閘道進入 BlobStore 原始儲存，由 DAG 工作流排程引擎切分為 GOP 影片分塊，透過分散式轉碼工作叢集進行多編碼與多解析度平行轉碼，最終生成 HLS/DASH 清單並分發至全球邊緣 CDN。01. INGESTION可續傳分塊上傳• Resumable Chunked• 5MB-20MB 局部區塊• 斷網自動重試與校驗HTTP Range / TUS ProtocolSTORAGE原始儲存與中繼庫• Colossus / BlobStore• Bigtable 影片中繼資訊• 完整性 SHA-256 驗證Raw Video Retention02. ORCHESTRATIONDAG 工作流引擎• GOP 關鍵幀精準分塊• 5-10 秒影片切片 (Chunks)• 音訊/視訊/字幕軌分離• 任務依賴圖 (DAG Engine)• 轉碼失敗局部自動重試動態算力資源調度WORKER POOL 1H.264 / AVC 轉碼陣列• 360p / 720p / 1080p最大化老舊設備相容性WORKER POOL 2 (MODERN)VP9 / AV1 轉碼陣列• 1440p 2K / 4K / 8K HDR節省 30%-50% 串流頻寬AUDIO & THUMBNAILS多音軌與精靈圖處理• AAC / Opus / 多國語音預覽縮圖 / AI 字幕生成03. PACKAGING自適應封裝• HLS (.m3u8 清單)• DASH (.mpd 描述檔)• DRM 加密保護分段索引清單合成04. STREAMING全球 CDN & ABR• Google Edge PoPs• 自適應碼率 (ABR)• 毫秒動態切換畫質零緩衝流暢播放
01. 可續傳上傳 (Ingestion)

Chunked Upload & 原始儲存

客戶端透過 5MB-20MB 分塊上傳，斷網可精確續傳；原始大檔寫入分散式 BlobStore 並寫入中繼資料。

↓ 觸發非同步轉碼 DAG
02. 任務排程中心

GOP 分塊切片與 DAG 工作流

依關鍵幀切分成 5-10 秒小片段，自動建立跨編碼器與解析度的轉碼依賴有向無環圖。

↓ 萬核平行矩陣轉碼
03. 分散式轉碼叢集

多編碼矩陣 (H.264 / VP9 / AV1)

數百台工作節點平行壓製各清晰度切片，兼顧老舊裝置相容性與現代高效頻寬節省。

↓ 清單封裝與邊緣分發
04. 串流分發與 ABR

HLS / DASH 封裝與全球 CDN 邊緣快取

產生動態清單，播放器依據用戶即時頻寬毫秒動態切換解析度，達到極致零停頓觀影體驗。

圖 1：YouTube 影片非同步上傳與分塊轉碼全景架構：分塊續傳、DAG 任務排程、分散式編碼矩陣與 CDN 自適應串流。

階段 1：可續傳分塊上傳（Resumable Chunked Upload）

當用戶上傳一個 50 GB 的 4K 影片時，若採用傳統的單一 HTTP POST 請求，任何網路中斷（WiFi 波動、行動基地台切換）都會導致整個檔案必須從頭重傳，這在工程上是不可接受的。

YouTube 採用了基於 HTTP 的可中斷續傳分塊上傳協議（類似 TUS 或 Google Resumable Media Upload）：

YouTube 可中斷續傳分塊上傳協議時序圖展示客戶端與 API 閘道之間初始化會話、上傳分塊、中斷後發送 HEAD 查詢已接收 Range 並續傳的完整時序。客戶端 (Client / Web / App)API 閘道 / 分散式 BlobStore1. POST /upload/init (50GB, SHA-256, Codec) ➔ 回傳專屬 Upload URL2. PUT Chunk #1 (Bytes 0-10485759 / 10MB) ➔ 200 OK 確認已寫入⚠️ 網路突發中斷 (WiFi 基地台切換 / 逾時重試)3. HEAD /upload/status ➔ 308 Resume Incomplete (Range: 0-10485759)4. PUT Chunk #2 (Bytes 10485760-20971519) ➔ 平滑續傳，零冗餘重跑！
STEP 1: 會話初始化

1. 建立專屬可續傳 Upload URL

客戶端發送 POST /upload/init，宣告整檔 50 GB 大小、原始檔 SHA-256 雜湊與容器格式。API 閘道產生帶權限的簽名續傳網址。

STEP 2: 分塊寫入

2. 依序上傳分塊 (Chunked PUT)

客戶端切割 10 MB 分塊並附帶 Content-Range 依序傳送；伺服器驗證局部 MD5 並寫入分散式 BlobStore，回傳 200 OK 確認落盤。

NETWORK EVENT

⚠️ 網路異常斷線容錯

當無線網路切換基地台或連線逾時斷開時，客戶端不必放棄整個 50 GB 檔案，只需暫停並準備斷點查詢。

STEP 3: 狀態探測

3. HEAD 探測伺服器已持久化範圍

客戶端發送 HEAD /upload/status。伺服器查詢中繼資料庫回傳 308 Resume Incomplete 與 Range: 0-10485759。

STEP 4: 精準續傳

4. 續傳下一個位元組 (Chunk #2)

客戶端依據 308 回應直接從位元組 10485760 繼續上傳後續分塊，達到 100% 頻寬零浪費與平滑斷點續傳。

圖一：YouTube 可中斷續傳分塊上傳協議（Resumable Media Upload）時序流程

核心機制設計

  1. 分塊切片（Chunking）：客戶端將檔案切為 5MB ~ 20MB 的 Chunk，逐塊上傳。
  2. 狀態持久化：伺服器在分散式中繼資料庫（Bigtable / Spanner）中記錄已成功接收的 Byte Range。
  3. 校驗與去重：每個 Chunk 攜帶 MD5 / CRC32 校驗碼；整檔完成時驗證全域 SHA-256。
  4. 原始儲存：完成後的完整原始影片（Raw Video）沉澱於高可靠物件儲存（Colossus / Distributed BlobStore）中，作為轉碼的唯讀來源。

階段 2：GOP 切片與非同步 DAG 任務排程

如果將整個 2 小時的 4K 原始影片丟給單台伺服器進行轉碼，單次轉碼可能需要數小時，且一旦中途記憶體溢位（OOM）或硬體故障，所有計算前功盡棄。

為了實現極致的轉碼速度，YouTube 將轉碼任務拆解為細粒度的 DAG（有向無環圖）工作流：

1. 基於 GOP（Group of Pictures）的精準切片

  • 視訊編碼由 I 幀（關鍵幀，獨立圖像）、P 幀（前向預測） 與 B 幀（雙向預測） 組成。
  • 影片切分引擎不能隨意在任意時間戳截斷，必須在 I 幀（Keyframe）邊界 處精準切片（通常為 5 ~ 10 秒一段）。
  • 每個切片可以完全獨立解碼與重新編碼，無需依賴前後切片。

2. DAG 依賴工作流編排

系統自動將單個影片轉換為包含數千個獨立子任務的 DAG 圖：

YouTube GOP 切片與 DAG 任務排程編排圖展示原始 4K 影片解耦為音訊軌與視訊 GOP 關鍵幀切片，分發為數千個獨立 Chunk 平行轉碼為 H.264 與 AV1 格式。原始 4K 影片上傳完成 (Raw Blob Storage)50 GB ｜ 60 FPS ｜ 無損母片音訊軌解封裝與多音軌轉碼AAC-LC ｜ Opus ｜ 5.1 空間音訊 ｜ 多國語言視訊 GOP 關鍵幀（I-Frame）切片切分 Chunk_001 ~ Chunk_100 (5~10 秒無損切片)Chunk_001 WorkerH.264 (1080p, 720p)AV1 / VP9 (4K, 1440p)Chunk_002 WorkerH.264 (1080p, 720p)AV1 / VP9 (4K, 1440p)Chunk_003 ... WorkerH.264 (1080p, 720p)AV1 / VP9 (4K, 1440p)
STAGE 1: 原始輸入

1. 原始 4K 影片入庫 (Raw Video)

完整的未轉碼無損影片（50GB+）安全沉澱於分散式 BlobStore，觸發非同步轉碼 DAG 工作流。

STAGE 2A: 音訊分離

2. 音訊軌解封裝與多音軌編碼

解耦音訊串流，獨立並行轉碼為 AAC、Opus、立體聲、5.1 空間音訊與多語系音軌。

STAGE 2B: 視訊 GOP 切片

3. 視訊關鍵幀 (Keyframe) 精準切分

嚴格在 I-Frame 邊界精確切分為 5~10 秒獨立 Chunk，確保每一個小切片都能獨立並行解碼編碼而無上下文依賴。

STAGE 3: 萬核轉碼矩陣

4. 分散式平行轉碼矩陣

數千個 Worker 並行領取切片任務，同時產出全解析度階梯（360p ~ 4K）與多格式轉碼（H.264、VP9、AV1）。

圖二：YouTube GOP 切片與分散式 DAG 任務轉碼編排工作流

階段 3：平行萬核分散式轉碼矩陣

轉碼工作節點（Transcoding Workers）從任務佇列中領取小切片任務進行平行壓製。YouTube 會同時產生多編碼格式與多解析度階梯（Encoding Ladder）：

多編碼格式矩陣（Codec Tradeoffs）

編碼格式壓縮效率 (頻寬節省)計算複雜度 (轉碼耗時)設備硬體解碼支援度策略定位
H.264 / AVC基準 (1x)極低 (快)接近 100%（全設備）兜底相容：老舊瀏覽器與低階裝置
VP9比 H.264 省 30-40%中等高（Android / PC）主力串流：一般高清 1080p / 1440p
AV1比 VP9 再省 20-30%極高 (慢、需專用 ASIC)逐步普及（旗艦晶片）極致頻寬：4K / 8K HDR 超高清首選

階段 4：自適應封裝（HLS / DASH）與邊緣 CDN 串流

轉碼完成的所有音視訊切片會被重新封裝為現代串流協議格式：

  1. HLS（HTTP Live Streaming）：產生 .m3u8 主索引清單與 .ts / .m4s 切片。
  2. MPEG-DASH（Dynamic Adaptive Streaming over HTTP）：產生 .mpd XML 媒體描述檔。

Manifest 清單結構示例（自適應碼率梯隊）

#EXTM3U
#EXT-X-VERSION:6

# 4K AV1 高碼率流
#EXT-X-STREAM-INF:BANDWIDTH=15000000,RESOLUTION=3840x2160,CODECS="av01.0.12M.08"
4k_av1_master.m3u8

# 1080p VP9 中碼率流
#EXT-X-STREAM-INF:BANDWIDTH=4500000,RESOLUTION=1920x1080,CODECS="vp09.00.41.08"
1080p_vp9_master.m3u8

# 360p H.264 低碼率流
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360,CODECS="avc1.4d401f"
360p_h264_master.m3u8

播放端的自適應碼率演算法（ABR Heuristics）

用戶播放影片時，播放器會持續監控兩個指標：

  • 即時下載頻寬吞吐量（Throughput-Based）
  • 本地緩衝區剩餘秒數（Buffer-Based）

當用戶走進電梯或訊號變差時，播放器在請求下一個 5 秒分塊時自動平滑切換至 360p 分塊清單；當重回 WiFi 時立即拉取 1080p/4K 分塊，全程無畫面中斷。

YouTube 影音架構演進對比

比較維度早期單體轉碼架構 (Monolithic Transcoding)現代分散式 GOP 切片 DAG 架構
轉碼單元整部影片單檔處理5 ~ 10 秒 GOP 獨立切片
轉碼耗時線性增長（2 小時影片需 1~2 小時）萬核平行（2 小時影片在 5 分鐘內完成）
故障恢復力崩潰需 100% 重跑僅需重跑失敗的 5 秒切片
頻寬優化單一固定碼率HLS / DASH 多碼率階梯 + AV1 自適應切換
播放啟動延遲需下載較大 Buffer首分塊極小化，首幀秒開（<200ms）

系統架構師的 4 個核心啟示

  1. 不可變分塊是分散式計算的基石：把大任務（數十 GB 的影片）拆解為不可變的小切片（GOP 塊），才能讓水平擴展、排程調度與故障重試變得極為廉價。
  2. 依頻寬與熱度動態分配算力：高算力編碼器（如 AV1）轉碼成本極高，應配合業務熱度指標分級轉碼，避免為零播放量影片浪費珍貴 GPU/ASIC 算力。
  3. 客戶端自主決策（Client-Driven ABR）：伺服器只負責提供靜態切片與 Manifest 清單，將碼率切換邏輯交給最了解當前硬體與網路狀態的客戶端播放器。
  4. 標準化 HTTP 基礎設施重用：HLS / DASH 的切片就是普通的靜態 HTTP 檔案，可直接享受全球 Cloudflare / Google CDN 的快取加速與邊緣卸載，無需自建昂貴的專用串流協定伺服器（如 RTMP）。

參考資料與一手文獻