利用Lambda當作影音轉換器的研究筆記(檔案超過512MB時)
 | |
|
什麼是Lambda ?
/*
引用: AWS官網 https://aws.amazon.com/tw/lambda/features/
AWS Lambda 是一種無伺服器運算服務，可執行程式碼以回應事件，並且自動為您管理基礎運算資源。您可以使用 AWS Lambda 透過自訂邏輯來擴展其他 AWS 服務，或者自己建立以 AWS 的擴展性、效能和安全性執行的後端服務.
*/
研究動機 :
央喜早期用Cloud Server開發了一套 "客戶簡報(pdf)+法說會錄音檔(mp3)的自動合併成影音(mp4)"的程式 , 並可隨簡報切換時間與聲音檔同步撥放 , 主要是客戶為了配合證交所新規定 , 要提供給證交所影音平台"交差"用 ( 合併成果展示 ) ; 由於一直想利用 serverless 來改善這套流程 , 並希望可以利用serverless 達到多工與平行處理 , 於是趁最近有空檔加緊再研究了一下Amazon Lambda ... 才發現Lambda 近年有許多改版與方便的地方 , 包括Timeout最大已可延長至15分鐘 , 還多了好像2018年才新增的 "Layer層級" ! (玩一玩發現Layer真不錯用)
Lambda優點就是便宜 , 需要時才執行 , 不需要像EC2般一直開機 ($$一直流走) , 缺點就是它有較多的限制 (參考 : AWS Lambda 限制 ) , 它只提供了 512MB 的/tmp 暫存 , 對於較大點的檔案若要當轉檔暫存可真是個麻煩的地方 , 於是開始著手來研究 ... (當然對於較大影音檔案也可以用 Elastic Transcoder 來達成 , 啊就是習慣幫公司省$$嘛 XD )
參考 :
RUNNING FFMPEG ON AWS LAMBDA FOR 1.9% THE COST OF AWS ELASTIC TRANSCODER
第一步 : 先研究如何突破 512MB空間上的限制
網路上看到很多案例都是將video小檔案輸出成縮圖之類 , 或是resize後再丟回S3 , 似乎都是在Lambda 中繼處理 (原本直接測人家的code , 還想說怎麼每次 ffmpeg 轉檔到一半就conversion fail = = 才想到應該是空間爆了 XD ) , 於是想出底下解法 , 這就來野人獻曝一下 :
這邊假設上述code已經寫好的情況 , 分別有主檔案 index.js 與目錄 bin/ node_modules/
(其實code沒幾行也很簡單 , 只是 bucket 設定有個坑要注意 , 不要像央喜掉到坑裡 XD)
第一步 : 先研究如何突破 512MB空間上的限制
網路上看到很多案例都是將video小檔案輸出成縮圖之類 , 或是resize後再丟回S3 , 似乎都是在Lambda 中繼處理 (原本直接測人家的code , 還想說怎麼每次 ffmpeg 轉檔到一半就conversion fail = = 才想到應該是空間爆了 XD ) , 於是想出底下解法 , 這就來野人獻曝一下 :
 |
| 利用Lambda當作"流轉換器" (Read from HTTP stream then PIPE stream to S3) |
這邊假設上述code已經寫好的情況 , 分別有主檔案 index.js 與目錄 bin/ node_modules/
(其實code沒幾行也很簡單 , 只是 bucket 設定有個坑要注意 , 不要像央喜掉到坑裡 XD)
 |
| 將ffmpeg binary source放bin目錄下 , 並包成 layer.zip (因為ffmpeg壓縮後還是很大 分開) |
 |
| AWS Lambda左方"層級" 點選"新建層級" |
 |
| 輸入並自訂層級名稱(Ex: ffmpegLayer) , 將layer.zip 傳上去這裡 (相容執行時間 選跟執行語言一樣的 到時才能選) |
 |
| 到主函式畫面 點選圖示 "Layers" 然後 "新增層級" |
 |
| "從清單中選擇相容執行時間的層級" , 相容Layer 選擇剛自訂的Layer名稱與版本 (如果有傳很多版的話) |
 |
| 主函式畫面就可以看到 ffmpegLayer 出現在Layer資訊這裡 ( Layer目錄在/opt 下 , 央喜這邊就可以使用 /opt/bin/ffmpeg 囉) |
 |
| 個人覺得用Layer最大好處在這兒 !! 仍然可以編輯與直接修改測試! (不然上傳zip超過5mb就不給線上編輯 XD 小修改要一直打包上傳 超麻煩) |
底下有幾個較需注意的地方 :
1.轉檔效能與Memory設定有關 (參考)
/*
The CPU share dedicated to a function is based off of the fraction of its allocated memory, per each of the two cores. For example, an instance with ~ 3 GB memory available for lambda functions where each function can have up to 1 GB memory means at most you can utilize ~ 1/3 * 2 cores = 2/3 of the CPU. The details may be revisited in the future, but that is the fractional nature of our usage model.
*/
2. Bucket要去設定Allow Lambda的 policy
3. 注意 : 此方式利用PIPE stream 寫入S3 , 但MP4特性關係 , 需要在開頭寫"moov atom"才能直接用來做HTTP streaming (參考 ), 所以若是要直接拿來做線上撥放的VOD可能不適合(還得加工又多一道工) , 因為主要是Partner都是將MP4下載提供客戶 , 證交所影音平台那邊上傳都還會做一次轉檔 ( 讓他們自己去解決吧 XD )
4. 注意 : Lambda 目前 timeout 最大可至15分鐘 , 所以若source Video太大就直接放棄此方式吧!
(希望Lambda日後 timeout 時間再加大些 ...)
[Test Result]
目前測試Source video 800MB左右沒問題 (約耗時10分鐘) , 後續再來找1G左右的測測看 ...
解決了一個小問題而已 , 後續還有PDF與MP3合併要把它搞到Lambda來 ~ 累了 XD
Ref:
AWS官網 : https://aws.amazon.com/tw/lambda/features/
AWS Lambda 限制
https://docs.aws.amazon.com/zh_cn/lambda/latest/dg/limits.html
Serverless Watermark using AWS Lambda Layers & FFmpeg
https://devopstar.com/2019/01/28/serverless-watermark-using-aws-lambda-layers-ffmpeg/
證交所影音平台PDF+MP3合併後的影音檔DEMO
Elastic Transcoder
https://aws.amazon.com/tw/elastictranscoder/
RUNNING FFMPEG ON AWS LAMBDA FOR 1.9% THE COST OF AWS ELASTIC TRANSCODER
/*
The CPU share dedicated to a function is based off of the fraction of its allocated memory, per each of the two cores. For example, an instance with ~ 3 GB memory available for lambda functions where each function can have up to 1 GB memory means at most you can utilize ~ 1/3 * 2 cores = 2/3 of the CPU. The details may be revisited in the future, but that is the fractional nature of our usage model.
*/
 |
| 轉檔速度火力全開 ( Lambda CPU cores 與設定的 Memory 有關) 就先開最大吧 3008MB |
2. Bucket要去設定Allow Lambda的 policy
 |
| 這就是央喜一開始一直踩到的坑 XD 記得要去bucket設定allow lambda角色 |
3. 注意 : 此方式利用PIPE stream 寫入S3 , 但MP4特性關係 , 需要在開頭寫"moov atom"才能直接用來做HTTP streaming (參考 ), 所以若是要直接拿來做線上撥放的VOD可能不適合(還得加工又多一道工) , 因為主要是Partner都是將MP4下載提供客戶 , 證交所影音平台那邊上傳都還會做一次轉檔 ( 讓他們自己去解決吧 XD )
4. 注意 : Lambda 目前 timeout 最大可至15分鐘 , 所以若source Video太大就直接放棄此方式吧!
(希望Lambda日後 timeout 時間再加大些 ...)
[Test Result]
目前測試Source video 800MB左右沒問題 (約耗時10分鐘) , 後續再來找1G左右的測測看 ...
解決了一個小問題而已 , 後續還有PDF與MP3合併要把它搞到Lambda來 ~ 累了 XD
Ref:
AWS官網 : https://aws.amazon.com/tw/lambda/features/
AWS Lambda 限制
https://docs.aws.amazon.com/zh_cn/lambda/latest/dg/limits.html
Serverless Watermark using AWS Lambda Layers & FFmpeg
https://devopstar.com/2019/01/28/serverless-watermark-using-aws-lambda-layers-ffmpeg/
證交所影音平台PDF+MP3合併後的影音檔DEMO
Elastic Transcoder
https://aws.amazon.com/tw/elastictranscoder/
RUNNING FFMPEG ON AWS LAMBDA FOR 1.9% THE COST OF AWS ELASTIC TRANSCODER
留言
張貼留言