Streamline 讓自訂影片管線不必自架主機
Cloudflare Blog · 2026-10-02
Cloudflare Stream 原本只能做標準的轉碼與播放，想在直播上疊動態標註、或把字幕燒進影片的人，只好自己架一套伺服器；Streamline 把這件事改成「Go 寫的媒體引擎跑在 Cloudflare Containers，Workers 與 Durable Object 負責控制」的現成骨架。
它由 cloudflare/streamline（容器端，Apache-2.0）與 streamline-demo（範例應用）組成，另有公開的 playground。
原本的問題
文章指出，自訂影片處理需要長時間存活、可預測記憶體與 CPU的環境，並能執行專用的編譯程式。原文的說法是：「A processing pipeline needs a durable, long-running environment that can run specialized, compiled code with predictable memory and CPU capacity.」
Workers 的請求模型不適合這種工作，所以過去的繞路方式是自己維運一組 FFmpeg 主機，再自己處理工作階段、金鑰與預覽。Streamline 的主張是把這些固定套路收進一個可重用的元件。
架構：兩個元件
- Media Engine：容器內以 Go 寫的 HTTP controller，底下用 FFmpeg 處理（文章稱 FFmpeg 是實作細節，不是對外 API）。支援 RTMPS 輸入與輸出、HLS 擷取、以 WebSocket 傳送預覽。容器的生命週期獨立於發起請求。
- Application：Workers 端的使用介面，掛身分與存取政策；Durable Object 負責 session 與容器生命週期，並中繼 WebSocket 預覽。
輸入可以是 RTMPS、HLS 或網路攝影機；輸出為 RTMP，或以 WebSocket 傳送 fMP4 片段做預覽。
管線如何描述
處理步驟用一份宣告式設定描述，目前列出的操作有 filter（模糊、飽和度）、overlay（以 URL 或 PNG 二進位疊圖）、subtitle 與 encode。
| 情境 | 以前 | Streamline |
|---|---|---|
| 直播疊 logo | 自架 FFmpeg 主機加自寫控制程式 | 設定一個 overlay 步驟 |
| 預覽 | 自行設計串流通道 | Durable Object 中繼 fMP4 的 WebSocket |
| 生命週期 | 自行排程與回收 | Durable Object 控制鎖加 session 到期處理 |
await session.start({
input: { type: 'rtmp', profile: 'primary-input' },
pipeline: [{
op: 'overlay',
params: { image: '/app/assets/cf-logo.png', position: 'top-right' }
}],
output: { mode: 'rtmp', profile: 'primary-output' }
})生命週期與安全
容器不會無限運行：session 有最長期限，並在閒置到期時由 Durable Object 在控制鎖內判斷是延長還是 destroy()；斷線時也有機制避免容器提早休眠而中斷處理。
安全面採三層：Cloudflare Access 擋使用者、Stream 金鑰存放在 Worker secrets（唯寫）、預覽以每個 session 的 capability token授權。README 也明說，應用必須在請求到達 Streamline 之前先驗證呼叫者並解出敏感媒體憑證。
影響範圍
最直接受益的是已經在用 Cloudflare Stream 或 Workers、又需要燒字幕、疊動態標註、做 picture-in-picture 的團隊。範例應用就以 Astro 前端示範了疊圖、字幕解碼、濾鏡與 picture-in-picture。
要先確認的限制：Streamline 本身不能單獨部署，必須有宿主應用；README 要求 Go 1.25.4 以上、Docker 與 Node.js 22.12 以上。效能數字與成本，文章與 README 皆未公布，容器計費與吞吐量需自行實測。