前言
隨着計算機技術和 Internet 的日新月異,視頻點播技術因其良好的人機交互性和流媒體傳輸技術倍受教育、娛樂等行業青睞,而在當前, 雲計算平臺廠商的產品線不斷成熟完善, 如果想要搭建視頻點播類應用,告別刀耕火種, 直接上雲會掃清硬件採購、 技術等各種障礙,以阿里云爲例:
這是一個非常典型的解決方案, 對象存儲 OSS 可以支持海量視頻存儲,採集上傳的視頻被轉碼以適配各種終端,CDN 加速終端設備播放視頻的速度。此外還有一些內容安全審查需求, 比如鑑黃、鑑恐等。
而在視頻點播解決方案中,視頻轉碼是最消耗計算力的一個子系統,雖然您可以使用雲上專門的轉碼服務,但在很多情況下,您會選擇自己搭建轉碼服務。比如:
- 您已經在虛擬機/容器平臺上基於 FFmpeg 部署了一套視頻處理服務,能否在此基礎上讓它更彈性,更高的可用性?
- 您的需求只是簡單的轉碼需求,或是一些極其輕量的需求,比如獲取 OSS 上視頻前幾幀的 GIF、獲取視頻或者音頻的時長,自己搭建成本更低。
- 各種格式的音頻轉換或者各種採樣率自定義、音頻降噪等功能
- 您有更高級的自定義處理需求,比如視頻轉碼完成後, 需要記錄轉碼詳情到數據庫, 或者在轉碼完成後, 自動將熱度很高的視頻預熱到 CDN 上, 從而緩解源站壓力。
- 您有併發處理大量視頻的需求。
- 自定義視頻處理流程中可能會有多種操作組合, 比如轉碼、加水印和生成視頻首頁 GIF。後續爲視頻處理系統增加新需求,比如調整轉碼參數,希望新功能發佈上線對在線服務無影響。
- 您的視頻源文件存放在 NAS 或者 ECS 雲盤上,自建服務可以直接讀取源文件處理,而不需要將它們再遷移到 OSS 上。
如果您的視頻處理系統有上述需求,或者您期望實現一個 彈性、高可用、低成本、免運維、靈活支持任意處理邏輯 的視頻處理系統,那麼本文則是您期待的最佳實踐方案。
Serverless 自定義音視頻處理
在介紹具體方案之前, 先介紹兩款產品:
- 函數計算 :阿里雲函數計算是事件驅動的全託管計算服務。通過函數計算,您無需管理服務器等基礎設施,只需編寫代碼並上傳。函數計算會爲您準備好計算資源,以彈性、可靠的方式運行您的代碼,並提供日誌查詢、性能監控、報警等功能。
- 函數工作流:函數工作流(Function Flow,以下簡稱 FnF)是一個用來協調多個分佈式任務執行的全託管雲服務。您可以用順序,分支,並行等方式來編排分佈式任務,FnF 會按照設定好的步驟可靠地協調任務執行,跟蹤每個任務的狀態轉換,並在必要時執行用戶定義的重試邏輯,以確保工作流順利完成。
免費開通函數計算,按量付費,函數計算有很大的免費額度。
免費開通函數工作流,按量付費,函數工作流有很大的免費額度。
函數計算可靠的執行任意邏輯, 邏輯可以是利用 FFmpeg 對視頻任何處理操作, 也可以更新視頻 meta 數據到數據庫等。
函數工作流對相應的函數進行編排, 比如第一步的函數是轉碼, 第二步的函數是轉碼成功後,將相應 meta 數據庫寫入數據庫等。
至此,您應該初步理解了函數計算的自定義處理能力 + 函數工作流編排能力幾乎滿足您任何自定義處理的需求,接下來,本文以一個具體的示例展示基於函數計算和函數工作流打造的一個彈性高可用的 Serverless 視頻處理系統,並與傳統方案進行性能、成本和工程效率的對比。
簡單視頻處理系統
假設您是對短視頻進行簡單的處理, 架構方案圖如下:
如上圖所示, 用戶上傳一個視頻到 OSS, OSS 觸發器自動觸發函數執行, 函數調用 FFmpeg 進行視頻轉碼, 並且將轉碼後的視頻保存回 OSS。
OSS 事件觸發器, 阿里雲對象存儲和函數計算無縫集成。您可以爲各種類型的事件設置處理函數,當 OSS 系統捕獲到指定類型的事件後,會自動調用函數處理。例如,您可以設置函數來處理 PutObject 事件,當您調用 OSS PutObject API 上傳視頻到 OSS 後,相關聯的函數會自動觸發來處理該視頻。
您可以直接基於示例工程部署您的簡單音視頻處理系統服務, 但是當您想要處理大視頻(比如 test_huge.mov ) 或者對小視頻進行多種組合操作的時候, 您會發現函數很大概率會執行失敗,原因是函數計算的執行環境存在一些限制, 比如最大執行時間爲 10 分鐘, 最大內存爲 3G。
爲了突破函數計算執行環境的限制,引入函數工作流 FnF 去編排函數實現一個功能強大的全功能視頻處理系統。
全功能視頻處理系統
如上圖所示, 假設用戶上傳一個 mov 格式的視頻到 OSS,OSS 觸發器自動觸發函數執行, 函數調用 FnF,並行進行提取音頻文件,同時進行 avi,mp4,flv 格式的轉碼。 所以您可以實現如下需求:
- 一個視頻文件可以同時被轉碼成各種格式以及其他各種自定義處理,比如增加水印處理或者在 after-process 更新信息到數據庫等。
- 當有多個文件同時上傳到 OSS,函數計算會自動伸縮, 並行處理多個文件。
-
對於每一個視頻,先進行切片處理,然後並行轉碼切片,最後合成,通過設置合理的切片時間,可以大大加速較大視頻的轉碼速度。
所謂的視頻切片,是將視頻流按指定的時間間隔,切分成一系列分片文件,並生成一個索引文件記錄分片文件的信息
- 結合 NAS + 視頻切片, 可以解決超大視頻(大於 3G )的轉碼。
示例效果:
函數計算 + 函數工作流 Serverless 方案 VS 傳統方案
卓越的工程效率
自建服務 | 函數計算 + 函數工作流 Serverless | |
---|---|---|
基礎設施 | 需要用戶採購和管理 | 無 |
開發效率 | 除了必要的業務邏輯開發,需要自己建立相同線上運行環境, 包括相關軟件的安裝、服務配置、安全更新等一系列問題 | 只需要專注業務邏輯的開發, 配合 FUN 工具一鍵資源編排和部署 |
並行&分佈式視頻處理 | 需要很強的開發能力和完善的監控系統來保證穩定性 | 通過 FnF 資源編排即可實現多個視頻的並行處理以及單個大視頻的分佈式處理,穩定性和監控交由雲平臺 |
學習上手成本 | 除了編程語言開發能力和熟悉 FFmpeg 以外,可能使用 K8S 或彈性伸縮( ESS ),需要了解更多的產品、名詞和參數的意義 | 會編寫對應的語言的函數代碼和熟悉 FFmpeg 使用即可 |
項目上線週期 | 在具體業務邏輯外耗費大量的時間和人力成本,保守估計大約 30 人天,包括硬件採購、軟件和環境配置、系統開發、測試、監控報警、灰度發佈系統等 | 預計 3 人天, 開發調試(2人天)+ 壓測觀察(1 人天) |
彈性伸縮免運維,性能優異
自建服務 | 函數計算 + 函數工作流 Serverless | |
---|---|---|
彈性高可用 | 需要自建負載均衡 (SLB),彈性伸縮,擴容縮容速度較 FC 慢 | FC系統固有毫秒級別彈性伸縮,快速實現底層擴容以應對峯值壓力,免運維,全功能視頻處理系統 (FnF + FC) 壓測;性能優異, 詳情見下面的轉碼性能表 |
監控報警查詢 | ECS 或者容器級別的 metrics | 提供更細粒度的 FnF 流程執行以及函數執行情況, 同時可以查詢每次函數執行的 latency 和日誌等, 更加完善的報警監控機制 |
函數計算 + 函數工作流 Serverless 方案轉碼性能表
實驗視頻爲是 89s 的 mov 文件 4K 視頻: 4K.mov,雲服務進行 mov -> mp4 普通轉碼需要消耗的時間爲 188s, 將這個參考時間記爲 T
視頻切片時間 | FC轉碼耗時 | 性能加速百分比 |
---|---|---|
45s | 160s | 117.5% |
25s | 100s | 188% |
15s | 70s | 268.6% |
10s | 45s | 417.8% |
5s | 35s | 537.1% |
性能加速百分比 = T / FC轉碼耗時
從上表可以看出,設置的視頻切片時間越短, 視頻轉碼時間越短, 函數計算可以自動瞬時調度出更多的計算資源來一起完成這個視頻的轉碼, 轉碼性能優異。
更低的成本
- 具有明顯波峯波谷的視頻處理場景(比如只有部分時間段有視頻處理請求,其他時間很少甚至沒有視頻處理請求),選擇按需付費,只需爲實際使用的計算資源付費。
-
沒有明顯波峯波谷的視頻處理場景,可以使用預付費(包年包月),成本仍然極具競爭力。
- 假設有一個基於 ECS 搭建的視頻轉碼服務,由於是 CPU 密集型計算, 因此在這裏將平均 CPU 利用率作爲核心參考指標對評估成本,以一個月爲週期,10 臺 C5 ECS 的總計算力爲例, 總的計算量約爲 30% 場景下, 兩個解決方案 CPU 資源利用率使用情況示意圖大致如下:
由上圖預估出如下計費模型:
- 函數計算預付費 3CU 一個月: 246.27 元, 計算能力等價於 ECS 計算型 C5
- ECS 計算型 C5 (2vCPU,4GB)+雲盤: 包月219 元
- 函數計算按量付費佔整個計算量的佔比 <= 10%,費用約爲 3×864×10% = 259.2 元,(3G 規格的函數滿負載跑滿一個月費用爲:0.00011108×3×30×24×3600 = 863.8,詳情查看計費)
ITEM | 平均CPU利用率 | 計算費用 | 總計 |
---|---|---|---|
函數計算組合付費 | >=80% | 998(246.27×3+259.2) | <= 998 |
按峯值預留ECS | <=30% | 2190(10*219) | >=2190 |
在這個模型預估裏面,可以看出 FC 方案具有很強的成本競爭力,在實際場景中, 基於 ECS 自建的視頻轉碼服務 CPU 利用甚至很難達到 20%, 理由如下:
- 可能只有部分時間段有視頻轉碼請求
- 爲了用戶體驗,視頻轉碼速度有一定的要求,可能一個視頻轉碼就需要 10 臺 ECS 並行處理來轉碼, 因此只能預備很多 ECS
因此,在實際場景中, FC 在視頻處理上的成本競爭力遠強於上述模型。
-
即使和雲廠商視頻轉碼服務單價 PK, 該方案仍有很強的成本競爭力
<br />經實驗驗證, 函數內存設置爲3G,基於該方案從 mov 轉碼爲 mp4 的費用概覽表:實驗視頻爲是 89s 的 mov 文件視頻, 測試視頻地址:
480P.mov 720P.mov 1080P.mov 4K.mov
測試命令:ffmpeg -i test.mov -preset superfast test.mp4
- 格式轉換
分辨率 | bitrate | 幀率 | FC 轉碼耗費時間 | FC 轉碼費用 | 騰訊雲視頻處理費用 | 成本下降百分比 |
---|---|---|---|---|---|---|
標清 640*480 | 618 kb/s | 24 | 11s | 0.00366564 | 0.032 | 88.5% |
高清 1280*720 | 1120 kb/s | 24 | 31s | 0.01033044 | 0.065 | 84.1% |
超清 1920*1080 | 1942 kb/s | 24 | 66s | 0.02199384 | 0.126 | 82.5% |
4K 3840*2160 | 5250 kb/s | 24 | 260s | 0.0866424 | 0.556 | 84.4% |
成本下降百分比 = (騰訊雲視頻處理費用 - FC 轉碼費用)/ 騰訊雲視頻處理費用
騰訊雲視頻處理,計費使用普通轉碼,轉碼時長不足一分鐘,按照一分鐘計算,這裏計費採用的是 2 min,即使採用 1.5 min 計算, 成本下降百分比也在 80% 左右
- 從上表可以看出, 基於函數計算 + 函數工作流的方案在計算資源成本上具有顯著優勢。
操作部署
免費開通函數計算,按量付費,函數計算有很大的免費額度。
免費開通函數工作流,按量付費,函數工作流有很大的免費額度。
免費開通文件存儲服務NAS, 按量付費
詳情見各自示例工程的 README
總結
基於函數計算 FC 和函數工作流 FnF 的彈性高可用視頻處理系統天然繼承了這兩個產品的優點:
- 無需採購和管理服務器等基礎設施,只需專注視頻處理業務邏輯的開發,大幅縮短項目交付時間和人力成本
- 提供日誌查詢、性能監控、報警等功能快速排查故障
- 以事件驅動的方式觸發應用響應用戶請求
- 免運維,毫秒級別彈性伸縮,快速實現底層擴容以應對峯值壓力,性能優異
- 成本極具競爭力
最後一一回答一下之前列出的問題:
Q1: 您已經在虛擬機/容器平臺上基於 FFmpeg 部署了一套視頻處理服務,能否在此基礎上讓它更彈性,更高的可用性?
A: 如工程示例所示,在虛擬機/容器平臺上基於 FFmpeg 的服務可以輕鬆切換到函數計算, FFmpeg 相關命令可以直接移值到函數計算,改造成本較低, 同時天然繼承了函數計算彈性高可用性特性。
Q2:您的需求只是簡單的轉碼需求,或是一些極其輕量的需求,比如獲取 OSS 上視頻前幾幀的 GIF 等。 自己搭建成本更低。
A: 函數計算天生就是解決這些自定義問題, 你的代碼你做主, 代碼中快速執行幾個 FFmpeg 的命令即可完成需求。<br />典型示例: fc-oss-ffmpeg
Q3: 您有更高級的自定義處理需求,比如視頻轉碼完成後, 需要記錄轉碼詳情到數據庫, 或者在轉碼完成後, 自動將熱度很高的視頻預熱到 CDN 上, 從而緩解源站壓力。
A: 詳情見全功能視頻處理系統(函數計算 + 函數工作流方案),after-process 中可以做一些自定義的操作, 您還可以基於此流程再做一些額外處理等, 比如:
- 再增加後續流程
- 最開始增加 pre-process
Q4: 您有併發同時處理大量視頻的需求。
A: 詳情見全功能視頻處理系統(函數計算 + 函數工作流方案), 當有多個文件同時上傳到 OSS, 函數計算會自動伸縮, 並行處理多個文件。詳情可以參考 全功能視頻處理系統 (FnF + FC) 壓測
Q5: 自定義視頻處理流程中可能會有多種操作組合, 比如轉碼、加水印和生成視頻首頁 GIF,後續爲視頻處理系統增加新需求,比如調整轉碼參數,希望新功能發佈上線對在線服務無影響。
A: 詳情見全功能視頻處理系統(函數計算 + 函數工作流方案), FnF 只負責編排調用函數, 因此只需要更新相應的處理函數即可,同時函數有 version 和 alias 功能, 更好地控制灰度上線, 函數計算版本管理
Q6: 您的視頻源文件存放在 NAS 或者 ECS 雲盤上,自建服務可以直接讀取源文件處理,而不需要將他們再遷移到 OSS 上。
A: 函數計算可以掛載 NAS, 直接對 NAS 中的文件進行處理
“阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐,做最懂雲原生開發者的技術圈。”