直播加浮水印、隨選影片燒字幕——這類需求聽起來簡單，真正的麻煩在於影片處理是長時間、重 CPU 的行程，跟一般請求導向的 serverless 模型根本對不上。2026 年 10 月 2 日，Cloudflare 在官方部落格發表了開發者 playground Streamline，示範怎麼在他們的開發者平台上拼出一條完整的自訂視訊管線。對 builder 來說，值得看的不是產品本身，而是它示範的架構拆法。
為什麼影片處理和 serverless 天生不對盤
一條視訊管線可能要跑幾分鐘到幾小時，媒體行程的生命週期必須獨立於啟動它的那個請求。應用程式應該能啟動管線、送入素材、檢查狀態、中途停掉，而不是把一個 HTTP 請求掛著不放。Cloudflare 在原文中的說法是，這需要可預測的記憶體與 CPU 容量、能跑編譯後的專用程式碼的長時間執行環境。
他們的解法是把三個原語各用其所：Container 負責長時間的媒體處理，Durable Objects 負責編排，Workers 負責控制訊號與監控。
兩個元件：Media Engine 和控制端應用
Streamline 的部署分成兩半。Media Engine 跑在 Container 裡，內部又分兩層：一個用 Go 寫的 Controller，實作 HTTP server、把請求翻譯成媒體操作；底下則是實際處理的 Processor，目前用 FFmpeg，但 Cloudflare 明確說這是內部實作細節，不是對外的 API。模組化的意思是，未來可以換成專用的編碼服務。
控制端應用建在 Workers 上，包含 UI 和一個由 Durable Object 實作的 Orchestrator，負責 session、Container 生命週期和預覽中繼。比較關鍵的設計是：session 啟動之後，Worker 可以安全地斷線重連，Container 繼續處理直到應用主動停止。為了避免管線失控，系統內建最大執行時長上限。由於 Container 閒置太久會自動休眠，實作上覆寫了 onActivityExpired() 回呼——沒到期限就續期，到了就銷毀。
API 怎麼設計成「誰來控制都行」
Streamline 匯出兩個套件：@cloudflare/streamline/client 提供以 session 為單位的高階 API，@cloudflare/streamline/ 則暴露 Container 對應的 Durable Object 基底類別，負責路由請求、實作預覽中繼，並提供安全與存取控制的掛點。整套 API 的操作面相當小：建立 session、啟動管線、送入影片區塊、更新 PNG 註記、讀指標、停止。
session.start() 吃一個 JSON 設定物件，結構就是「輸入、操作、輸出」。輸入可以是 RTMPS 直播訊號、Stream 託管影片的 HLS manifest，或由應用端直接 ingest（例如 webcam、工廠攝影機）。目前支援的操作只有四種——filter、overlay、subtitle、encode——而且操作的執行順序由引擎固定，設定陣列裡的順序不影響結果。換句話說，這是一個能力受限但介面乾淨的版本，不是全能的 FFmpeg 前端。
預覽輸出走 WebSocket：Container 把 fMP4 片段推到 Durable Object，應用連到 /relay/view 收即時畫面。本機開發時更簡單——Container 就是本地 Docker，不需要 Durable Object 和存取控制。
安全與限制
Cloudflare 在原文中列了幾條底線：只有授權的使用者能建立或接管 session、session 之間互相隔離、Stream 的 RTMPS 金鑰視為不該洩漏給控制端應用的機密、資源使用必須有界。原始碼在安全段落處被截斷，所以完整的存取控制實作細節，建議直接讀原文。
對想在影音產品上動手的團隊，實際的下一步很清楚：先在本地用 Docker 模式驗證管線設定，再決定要不要部署到 Cloudflare。這種「控制面與資料面分離、長時行程與請求解耦」的拆法，也不只適用於影片——跟我在先前談 Cloudflare AI Gateway 路由時提到的控制平面思路，其實是同一套平台哲學。