前言
随着計算機技術和 Internet 的日新月異，視訊點播技術因其良好的人機互動性和流媒體傳輸技術倍受教育、娛樂等行業青睐，而在目前， 雲計算平台廠商的産品線不斷成熟完善， 如果想要搭建視訊點播類應用，告别刀耕火種， 直接上雲會掃清硬體采購、 技術等各種障礙，以阿裡雲為例：
這是一個非常典型的解決方案， 對象存儲 OSS 可以支援海量視訊存儲，采集上傳的視訊被轉碼以适配各種終端，CDN 加速終端裝置播放視訊的速度。此外還有一些
内容安全審查需求， 比如鑒黃、鑒恐等。
而在視訊點播解決方案中， 視訊轉碼是最消耗計算力的一個子系統，雖然您可以使用雲上專門的轉碼服務，但在很多情況下，您會選擇自己搭建轉碼服務。比如：
- 您已經在虛拟機/容器平台上基于 FFmpeg 部署了一套視訊處理服務，能否在此基礎上讓它更彈性，更高的可用性？
- 您有并發處理大量視訊的需求。
- 您有很多超大的視訊需要批量快速處理完， 比如每周五定期産生幾百個 4G 以上的 1080P 大視訊， 但是希望當天幾個小時後全部處理完。
- 您有更進階的自定義處理需求，比如視訊轉碼完成後， 需要記錄轉碼詳情到資料庫， 或者在轉碼完成後， 自動将熱度很高的視訊預熱到 CDN 上， 進而緩解源站壓力。
- 自定義視訊處理流程中可能會有多種操作組合， 比如轉碼、加水印和生成視訊首頁 GIF。後續為視訊處理系統增加新需求，比如調整轉碼參數，希望新功能釋出上線對線上服務無影響。
- 您的需求隻是簡單的轉碼需求，或是一些極其輕量的需求，比如擷取 OSS 上視訊前幾幀的 GIF、擷取視訊或者音頻的時長，自己搭建成本更低。
- 各種格式的音頻轉換或者各種采樣率自定義、音頻降噪等功能
- 您的視訊源檔案存放在 NAS 或者 ECS 雲盤上，自建服務可以直接讀取源檔案處理，而不需要将它們再遷移到 OSS 上。
如果您的視訊處理系統有上述需求，或者您期望實作一個 彈性、高可用、低成本、免運維、靈活支援任意處理邏輯 的視訊處理系統，那麼本文則是您期待的最佳實踐方案。
Serverless 自定義音視訊處理
在介紹具體方案之前， 先介紹兩款産品：
- 函數計算 ：阿裡雲函數計算是事件驅動的全托管計算服務。通過函數計算，您無需管理伺服器等基礎設施，隻需編寫代碼并上傳。函數計算會為您準備好計算資源，以彈性、可靠的方式運作您的代碼，并提供日志查詢、性能監控、報警等功能。
- 函數工作流 ：函數工作流（Function Flow，以下簡稱 FnF）是一個用來協調多個分布式任務執行的全托管雲服務。您可以用順序，分支，并行等方式來編排分布式任務，FnF 會按照設定好的步驟可靠地協調任務執行，跟蹤每個任務的狀态轉換，并在必要時執行使用者定義的重試邏輯，以確定工作流順利完成。
，按量付費，函數計算有很大的免費額度。
免費開通函數工作流，按量付費，函數工作流有很大的免費額度。
函數計算可靠的執行任意邏輯， 邏輯可以是利用 FFmpeg 對視訊任何處理操作， 也可以更新視訊 meta 資料到資料庫等。
函數工作流對相應的函數進行編排, 比如第一步的函數是轉碼， 第二步的函數是轉碼成功後，将相應 meta 資料庫寫入資料庫等。
至此，您應該初步了解了函數計算的自定義處理能力 + 函數工作流編排能力幾乎滿足您任何自定義處理的需求，接下來，本文以一個具體的示例展示基于函數計算和函數工作流打造的一個彈性高可用的 Serverless 視訊處理系統，并與傳統方案進行性能、成本和工程效率的對比。
Simple 視訊處理系統
假設您是對視訊進行單純的處理， 架構方案圖如下：
如上圖所示， 使用者上傳一個視訊到 OSS, OSS 觸發器自動觸發函數執行， 函數調用 FFmpeg 進行視訊轉碼， 并且将轉碼後的視訊儲存回 OSS。
OSS 事件觸發器 , 阿裡雲對象存儲和函數計算無縫內建。您可以為各種類型的事件設定處理函數，當 OSS 系統捕獲到指定類型的事件後，會自動調用函數處理。例如，您可以設定函數來處理 PutObject 事件，當您調用 OSS PutObject API 上傳視訊到 OSS 後，相關聯的函數會自動觸發來處理該視訊。Simple 視訊處理系統示例工程位址
強大的監控系統：
您可以直接基于示例工程部署您的 Simple 音視訊處理系統服務， 但是當您想要處理超大視訊(比如
test_huge.mov) 或者對小視訊進行多種組合操作的時候， 您會發現函數會執行失敗，原因是函數計算的執行環境有最大執行時間為 10 分鐘的限制，如果最大的 10 分鐘不能滿足您的需求， 您可以選擇：
- 對視訊進行分片 -> 轉碼 -> 合成處理， 詳情參考： fc-fnf-video-processing ， 下文會詳細介紹；
- 聯系函數計算團隊(釘釘群号: 11721331) 或者提工單：
- 适當放寬執行時長限制；
- 使用性能型執行個體
為了突破函數計算執行環境的限制（或者說加快大視訊的轉碼速度）, 進行各種複雜的組合操作， 此時引入函數工作流 FnF 去編排函數實作一個功能強大的視訊處理工作流系統是一個很好的方案。
視訊處理工作流系統
如上圖所示， 假設使用者上傳一個 mov 格式的視訊到 OSS，OSS 觸發器自動觸發函數執行， 函數調用 FnF，會同時進行 1 種或者多種格式的轉碼(由您觸發的函數環境變量DST_FORMATS 參數控制)。 是以您可以實作如下需求：
- 一個視訊檔案可以同時被轉碼成各種格式以及其他各種自定義處理，比如增加水印處理或者在 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 | 417.8% | |
| 5s | 35s | 537.1% |
性能加速百分比 = T / FC轉碼耗時
從上表可以看出，設定的視訊切片時間越短， 視訊轉碼時間越短， 函數計算可以自動瞬時排程出更多的計算資源來一起完成這個視訊的轉碼, 轉碼性能優異。
更低的成本
- 具有明顯波峰波谷的視訊處理場景(比如隻有部分時間段有視訊處理請求，其他時間很少甚至沒有視訊處理請求)，選擇按需付費，隻需為實際使用的計算資源付費。
- 沒有明顯波峰波谷的視訊處理場景，可以使用預付費（包年包月），成本仍然極具競争力。
函數計算成本優化最佳實踐文檔 。
假設有一個基于 ECS 搭建的視訊轉碼服務，由于是 CPU 密集型計算， 是以在這裡将平均 CPU 使用率作為核心參考名額對評估成本，以一個月為周期，10 台 C5 ECS 的總計算力為例， 總的計算量約為 30% 場景下, 兩個解決方案 CPU 資源使用率使用情況示意圖大緻如下:由上圖預估出如下計費模型： 輕松建構基于 Serverless 架構的彈性高可用音視訊處理系統前言Serverless 自定義音視訊處理操作部署總結 - 函數計算預付費 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，詳情檢視 計費 ）
在這個模型預估裡面，可以看出 FC 方案具有很強的成本競争力，在實際場景中, 基于 ECS 自建的視訊轉碼服務 CPU 利用甚至很難達到 20%， 理由如下:ITEM 平均CPU使用率 計算費用 總計 函數計算組合付費 >=80% 998（246.27×3+259.2） <= 998 按峰值預留ECS <=30% 2190（10*219） >=2190 - 可能隻有部分時間段有視訊轉碼請求
- 為了使用者體驗，視訊轉碼速度有一定的要求，可能一個視訊轉碼就需要 10 台 ECS 并行處理來轉碼， 是以隻能預備很多 ECS
-
即使和雲廠商視訊轉碼服務單價 PK, 該方案仍有很強的成本競争力
我們這邊選用點播視訊中最常用的兩個格式(mp4、flv)之間進行互相轉換，經實驗驗證， 函數記憶體設定為3G，基于該方案從 mp4 轉碼為 flv 的費用概覽表:
實驗視訊為是 89s 的 mp4 和 flv 格式的檔案視訊， 測試視訊位址： 480P.mp4 720P.mp4 1080P.mp4 4K.mp4 480P.flv 720P.flv 1080P.flv 4K.flv 測試指令:
mp4 轉 flv：ffmpeg -i test.flv test.mp4
ffmpeg -i test.flv test.mp4
flv 轉 mp4：分辨率 bitrate 幀率 FC 轉碼耗費時間 FC 轉碼費用 騰訊雲視訊處理費用 成本下降百分比 标清 640*480 889 kb/s 24 11.2s 0.003732288 0.032 88.3% 高清 1280*720 1963 kb/s 20.5s 0.00683142 0.065 89.5% 超清 1920*1080 3689 kb/s 40s 0.0133296 0.126 89.4% 4K 3840*2160 11185 kb/s 142s 0.04732008 0.556 91.5% 712 kb/s 34.5s 0.01149678 64.1% 1806 kb/s 100.3s 0.033424 48.6% 3911 kb/s 226.4s 0.0754455 40.1% 15109 kb/s 912s 0.30391488 45.3% 成本下降百分比 = （騰訊雲視訊處理費用 - FC 轉碼費用）/ 騰訊雲視訊處理費用 騰訊雲視訊處理 ，計費使用普通轉碼，轉碼時長不足一分鐘，按照一分鐘計算，這裡計費采用的是 2 min，即使采用 1.5 min 計算， 成本下降百分比基本在10%以内浮動
從上表可以看出， 基于函數計算 + 函數工作流的方案在計算資源成本上對于計算複雜度較高的flv 轉 mp4
mp4 轉 flv
- 測試視訊的碼率較高， 實際上很多場景絕大部分都是标清或者流暢視訊的轉碼場景， 碼率也比測試視訊低，這個時候計算量變小， FC 執行時間短， 費用會降低， 但是通用的雲轉碼服務計費是不變的.
- 很多視訊分辨率在通用的雲轉碼服務是很吃虧的， 比如轉碼的視訊是
856*480
1368*768
856*480
1280*720
1368*768
1920*1080
- 比如一些轉碼需求就是單純轉封裝(不涉及音視訊的編解碼)， 或者隻轉音頻， 這個計算量基本下降95%以上.
操作部署
免費開通檔案存儲服務NAS， 按量付費
詳情見各自示例工程的 README
總結
基于函數計算 FC 和函數工作流 FnF 的彈性高可用視訊處理系統天然繼承了這兩個産品的優點:
- 無需采購和管理伺服器等基礎設施，隻需專注視訊處理業務邏輯的開發，大幅縮短項目傳遞時間和人力成本
- 提供日志查詢、性能監控、報警等功能快速排查故障
- 以事件驅動的方式觸發響應使用者請求
- 免運維，毫秒級别彈性伸縮，快速實作底層擴容以應對峰值壓力，性能優異
- 成本極具競争力
1. 相比于通用的轉碼處理服務:
- 超強自定義，對使用者透明， 基于 FFmpeg 或者其他音視訊處理工具指令快速開發相應的音視訊處理邏輯
- 原有基于 FFmpeg 自建的音視訊處理服務可以一鍵遷移
- 彈性更強， 可以保證有充足的計算資源為轉碼服務，比如每周五定期産生幾百個 4G 以上的 1080P 大視訊， 但是希望當天幾個小時後全部處理完
- 各種格式的音頻轉換或者各種采樣率自定義、音頻降噪等功能， 比如專業音頻處理工具 aacgain 和 mp3gain
- 可以和 serverless 工作流完成更加複雜、自定義的任務編排，比如視訊轉碼完成後，記錄轉碼詳情到資料庫，同時自動将熱度很高的視訊預熱到 CDN 上， 進而緩解源站壓力
- 更多的方式的事件驅動， 比如可以選擇 OSS 自動觸發(豐富的觸發規則)， 也可以根據業務選擇 MNS 消息(支援 tag 過濾)觸發
- 在大部分場景下具有很強的成本競争力
2. 相比于其他自建服務:
- 毫秒級彈性伸縮，彈性能力超強，支援大規模資源調用，可彈性支援幾萬核.小時的計算力，比如 1 萬節課半個小時完成轉碼
- 隻需要專注業務邏輯代碼即可，原生自帶事件驅動模式，簡化開發程式設計模型，同時可以達到消息(即音視訊任務)處理的優先級，可大大提高開發運維效率
- 函數計算采用 3AZ 部署， 安全性高，計算資源也是多 AZ 擷取， 能保證每個使用者需要的算力峰值
- 開箱即用的監控系統， 如上面 gif 動圖所示，可以多元度監控函數的執行情況，根據監控快速定位問題，同時給使用者提供分析能力， 比如視訊的格式分布， size 分布等
- 在大部分場景下具有很強的成本競争力， 因為在函數計算是真正的按量付費(計費粒度在百毫秒)， 可以了解為 CPU 的使用率為 100%
最後一一回答一下之前列出的問題：
Q1: 您已經在虛拟機/容器平台上基于 FFmpeg 部署了一套視訊處理服務，能否在此基礎上讓它更彈性，更高的可用性？
A: 如工程示例所示，在虛拟機/容器平台上基于 FFmpeg 的服務可以輕松切換到函數計算， FFmpeg 相關指令可以直接移值到函數計算，改造成本較低， 同時天然繼承了函數計算彈性高可用性特性。
Q2：您的需求隻是簡單的轉碼需求，或是一些極其輕量的需求，比如擷取 OSS 上視訊前幾幀的 GIF 等。 自己搭建成本更低。
A: 函數計算天生就是解決這些自定義問題， 你的代碼你做主, 代碼中快速執行幾個 FFmpeg 的指令即可完成需求。
典型示例:
fc-oss-ffmpegQ3: 您有更進階的自定義處理需求，比如視訊轉碼完成後， 需要記錄轉碼詳情到資料庫， 或者在轉碼完成後， 自動将熱度很高的視訊預熱到 CDN 上， 進而緩解源站壓力。
A: 詳情見視訊處理工作流系統(函數計算 + 函數工作流方案)，after-process 中可以做一些自定義的操作， 您還可以基于此流程再做一些額外處理等， 比如：
- 再增加後續流程
- 最開始增加 pre-process
Q4: 您有并發同時處理大量視訊的需求。
A: 詳情見視訊處理工作流系統(函數計算 + 函數工作流方案), 當有多個檔案同時上傳到 OSS, 函數計算會自動伸縮， 并行處理多個檔案。詳情可以參考
Q5：您有很多超大的視訊需要批量快速處理完， 比如每周五定期産生幾百個 4G 以上的 1080P 大視訊， 但是希望當天幾個小時後全部處理完。
A: 詳情可以參考
, 可以通過控制分片的大小， 可以使得每個大視訊都有足夠多的計算資源參與轉碼計算， 大大提高轉碼速度。
Q6: 自定義視訊處理流程中可能會有多種操作組合， 比如轉碼、加水印和生成視訊首頁 GIF，後續為視訊處理系統增加新需求，比如調整轉碼參數，希望新功能釋出上線對線上服務無影響。
A: 詳情見視訊處理工作流系統(函數計算 + 函數工作流方案), FnF 隻負責編排調用函數， 是以隻需要更新相應的處理函數即可，同時函數有 version 和 alias 功能， 更好地控制灰階上線，
函數計算版本管理Q7: 您的視訊源檔案存放在 NAS 或者 ECS 雲盤上，自建服務可以直接讀取源檔案處理，而不需要将他們再遷移到 OSS 上。
A:
函數計算可以挂載 NAS, 直接對 NAS 中的檔案進行處