來自Revvel的團隊的Greg Femec在re:Invent 2017大會上分享了他在構(gòu)建視頻轉(zhuǎn)碼服務(wù)中遇到的挑戰(zhàn)，以及構(gòu)建基于Serverless架構(gòu)的視頻轉(zhuǎn)碼平臺的經(jīng)驗。Revvel團隊將視頻轉(zhuǎn)碼服務(wù)從AWS EC2遷移到AWS Lambda和S3上，實現(xiàn)了整個轉(zhuǎn)碼的Serverless化，節(jié)省了大量費用和運維成本，并且將時長2小時的視頻轉(zhuǎn)碼從4-6小時縮短到不到10分鐘，從而將更多的時間投入到核心服務(wù)的開發(fā)和優(yōu)化當中。LiveVideoStack對其進行了摘譯整理，點擊『閱讀原文』觀看Greg的分享視頻。

?

作者：Greg Femec，Revvel資深軟件開發(fā)主管(Principle Development Lead)

聽譯：王鴻蒙

責編：Ant

Serverless系統(tǒng)架構(gòu)具有自動擴容、按需付費、無需服務(wù)器部署和運維以及高可用性和容錯性的特點。AWS Lambda是著名的Serverless云服務(wù)提供商，在AWS Lambda上的一個典型Serverless應(yīng)用往往通過事件驅(qū)動的方式去觸發(fā)對預(yù)定義函數(shù)的調(diào)用。事件源可以有很多種，主要分為3類：

• 數(shù)據(jù)狀態(tài)變化，例如S3對象的新增、刪除。

• API請求，即通過特定的HTTP請求來觸發(fā)函數(shù)的執(zhí)行。

• 資源狀態(tài)變化，如AWS云組件的相關(guān)配置發(fā)生變化。

AWS Lambda典型的應(yīng)用包括：

• 網(wǎng)站: 靜態(tài)網(wǎng)站，復(fù)雜網(wǎng)站應(yīng)用，Flask和Express網(wǎng)站架構(gòu)

• 后臺：應(yīng)用和服務(wù)，移動App，物聯(lián)網(wǎng)（IoT）

• 數(shù)據(jù)處理：實時數(shù)據(jù)處理，MapReduce，批處理

• 聊天機器人：聊天邏輯

• Amazon Alexa： 語音驅(qū)動的應(yīng)用， Alexa 技能工具包

• IT自動化： 策略引擎， 擴展服務(wù)， 架構(gòu)管理

在視頻編碼處理中，并行編碼算法有多種，根據(jù)并行級別可以分為GoP 級、幀級、Slice 級和宏塊行級。視頻編碼的這種特點使得它可以很好的利用AWS Lamda的并行處理的特性。Revvel團隊在之前構(gòu)建視頻轉(zhuǎn)碼服務(wù)平臺過程中遇到過許多挑戰(zhàn)，主要體現(xiàn)在以下幾個方面：

?

• 大量的待轉(zhuǎn)碼視頻

• 無法提前預(yù)測轉(zhuǎn)碼業(yè)務(wù)所需的時間及工作量

• 視頻源來自于不同的合作伙伴，不同的拍攝設(shè)備，導(dǎo)致其長短，分辨率、碼率多種多樣

• 不同的輸入格式

• 輸出格式多樣， 多種封裝格式

• 典型的無交錯（逐行掃描）MP4

• HLS（TS塊）

• DASH（片段化MP4）

• 各種DRM協(xié)議

?

在早期Revvel團隊使用了SaaS方案。但是由于視頻的來源不同，我們很難在這個方案中獲得對于視頻轉(zhuǎn)碼更高的控制權(quán)。同時成本效益并不高，尤其是新增轉(zhuǎn)碼格式的邊際成本并未隨著用量增大而顯著降低。

我們也在AWS EC2上嘗試建立自己的視頻轉(zhuǎn)碼服務(wù)，成本得到了一定的控制，視頻的控制權(quán)也增大，但隨之而來的是運維方面的挑戰(zhàn)。這些挑戰(zhàn)表現(xiàn)在：

?

可擴展性。用戶希望能夠快速上傳并分享視頻，因此我們希望避免任何任務(wù)排隊，以快速響應(yīng)用戶請求。但是這里涉及到冷啟動問題。從購買計算資源直至計算資源可用，要花費大量的時間啟動實例，下載軟件，安裝更新，下載所需文件。

資源浪費。假設(shè)我們有一個可以同時運行多個任務(wù)的高性能實例，但目前卻只有一個比較耗時的任務(wù)在運行，比如高清(HD)視頻轉(zhuǎn)碼，這在我們當前的配置下通常會花費好幾個小時。我們無法利用該實例上多余的計算能力，也無法中止轉(zhuǎn)碼，把任務(wù)移交到另外一臺機器來回收多余的計算資源。另外，在我們構(gòu)建轉(zhuǎn)碼服務(wù)的時候，EC2按小時計費，如果我們啟動多個實例處理視頻，每個實例運行了20分鐘，每個實例仍然需要支付一小時的費用。（從2017年9月份開始，EC2可以按秒計費。）

我們?yōu)槭裁词褂肧erverless？

?

Serverless的好處明顯：沒有冷啟動問題，可以快速擴容縮容，沒有資源浪費，運維問題更少，并發(fā)量更大（AWS Lambda默認并發(fā)執(zhí)行上限為1000，我們調(diào)整為2000，但這并不是硬性限制），以及靈活的資源配置（可以快速重新對資源進行分配）。

?

Serverless下轉(zhuǎn)碼的挑戰(zhàn)

?

輸入的視頻文件往往較大（有些有數(shù)百GB），我們不希望等文件下載完成才開始處理，并且我們在Lambda中的容器也沒有這么大的存儲空間。另外，視頻轉(zhuǎn)碼工具一般假定輸入輸出為完整的視頻文件，無法進行塊級的處理。同時，如我們之前提到的，HD視頻轉(zhuǎn)碼往往耗時好幾個小時，而且轉(zhuǎn)碼一旦開始，很難暫停和重啟。

?

我們的解決方案

我們的高效視頻轉(zhuǎn)碼解決方案使用類似于MapReduce的分治法，把視頻切成5秒（時間可以調(diào)整）的小塊，在map中進行轉(zhuǎn)碼，在reduce中進行合并，輸出我們需要的格式， 比如無交錯視頻（Progressive MP4）和MPEG-DASH。對于HLS，某些情況下我們可以直接使用map的結(jié)果作為TS塊，有時也做一些后期處理，尤其是需要加入DRM時。同時需要避免在本地磁盤上緩存完整的視頻大文件。

?

我們使用的工具包括AWS Lambda（實時縮放、并行處理的能力）、S3（支持分段上傳，按范圍請求數(shù)據(jù)）、FFmpeg（轉(zhuǎn)碼領(lǐng)域的瑞士軍刀）以及Python（AWS Lambda對Python有很好的支持，Revvel團隊熟悉并大量使用該語言，并可以對C代碼進行很好的整合）。下面對Serverless轉(zhuǎn)碼的架構(gòu)圖進行簡要說明：

??

圖：轉(zhuǎn)碼架構(gòu)圖

我們的輸入和輸出處理基于S3存儲。首先，我們從不同的存儲位置獲取視頻源文件，統(tǒng)一存儲在S3上，執(zhí)行map（圖中所示Chunk Lambda Function）開始進行處理。嚴格來講，在這里我們可以并行運行任意數(shù)量的map，視頻文件中的每組5秒數(shù)據(jù)塊可以被分別獲取，這些5秒數(shù)據(jù)塊的計算相互獨立，每一個的處理都不依賴于其他的5秒數(shù)據(jù)塊，數(shù)據(jù)塊的分發(fā)和執(zhí)行只取決于我們現(xiàn)有的CPU總核數(shù)，以及并發(fā)的Lambda function執(zhí)行數(shù)量。所以，這就允許我們一次運行多組程序來處理ts塊，而這步處理的結(jié)果將被存儲于另外的S3存儲桶中。下一步，我們繼續(xù)在這些文件塊上進行reduce。通過對文件塊進行相對簡單的reduce操作，并將他們合并，可以生成MP4文件；如果要生成DRM文件則要更加復(fù)雜的過程，圖中所示即是生成DRM后的HLS文件的例子，而DASH文件的生成過程與之類似。

?

下面我們講解塊函數(shù)（Chunk Function）操作中的細節(jié)。

?

塊函數(shù)（Chunk Function）工作說明

之所以叫塊函數(shù)，是因為我們要通過這個函數(shù)生成ts文件塊。如果我們想生成一個文件塊，首先就需要解碼輸入視頻中的一小部分，然后將其轉(zhuǎn)碼到想要得到的分辨率/碼率，最后，將生成的TS文件塊上傳到S3中。這里面臨如下兩個主要的挑戰(zhàn)。

圖：塊函數(shù)（Chunk Funtion）工作流程圖

?

• ?解碼的挑戰(zhàn)與解決方案

?

從上面可以看到，我們不再需要下載整個文件，而只是對其中一小部分進行操作即可。因此，我們的挑戰(zhàn)主要來自于如何在這種情況下實現(xiàn)解碼。通常，我們使用FFmpeg幫助我們完成大部分解碼操作。FFmpeg支持有大小范圍請求的HTTP請求，FFmpeg常常讀若干字節(jié)后前后跳轉(zhuǎn)，產(chǎn)生大量的HTTP請求來對相同文件塊反復(fù)讀取，造成巨大的性能消耗。為此，我們在Lambda function中對S3進行了緩存，做法是在Lambda里啟動一個HTTP服務(wù)，代理所有FFmpeg對S3的讀取請求。我們要做的是從S3中得到比FFmpeg請求更大的文件塊，并將其緩存到內(nèi)存中，避免反復(fù)對相同文件塊的反復(fù)造成的開銷。另外，由于視頻處理整體是從前往后的，所以在FFmpeg處理一個塊時，我們也會主動預(yù)取下一個數(shù)據(jù)塊，以免出現(xiàn)CPU等待IO造成的性能損失。

?

• FFmpeg的挑戰(zhàn)

首先， 動態(tài)鏈接的FFmepg在lambda中運行不是很穩(wěn)定，所以我們目前基本都是使用的靜態(tài)鏈接。雖然文件尺寸更大，但仍在Lambda的限制之內(nèi)。

另外，創(chuàng)建進程也可能出現(xiàn)問題。在Lambda里使用fork創(chuàng)建進程時，子進程會繼承父進程的所有屬性，這里面也包括了運行著我們代碼的lambda沙箱，因此在子進程里常常會意外發(fā)現(xiàn)一些自己并未創(chuàng)建過的東西。在我們的實踐中，在Python代碼里fork的FFmpeg進程繼承了沙箱中的某些文件描述符，特別是標準輸入，這偶爾會造成一些bug，我們可以將文件描述符關(guān)閉來解決這些問題。另外，如果前后執(zhí)行多個Lambda function，容器可能會被重用，這意味著之前創(chuàng)建的進程會一直保持到后續(xù)的執(zhí)行過程。因此，lambda function即使在執(zhí)行錯誤的情況下也要正確清理現(xiàn)場。

合并函數(shù)（Merge Function）

圖：精簡合并函數(shù)(Merge Function)工作流程圖

當我們的文件經(jīng)過map步驟處理后，形成小的ts文件塊進入到精簡合并操作步驟。其中，比較常用的就是生成MP4文件。在這個過程中，合并函數(shù)讀入.ts的文件塊，合并為MP4文件，然后上傳到S3中。這里遇到的問題主要集中在文件輸出上。

?

輸出文件的挑戰(zhàn)

?

相對于輸入文件，輸出的視頻文件往往很大，lambda沒有足夠的臨時空間存儲。FFmpeg雖然支持FTP輸出，但在輸出MP4時，它輸出大部分數(shù)據(jù)之后，還會跳轉(zhuǎn)到文件頭插入一些信息。這個時候我們就要引入S3的文件分段上傳功能。我們在Lambda function中啟動一個定制的FTP服務(wù)，類似適配器，將FTP輸入適配到S3的文件分段上傳功能中。由于S3不需要按順序上傳，每段大小也不需要相同，因此我們可以從第二段開始上傳，最后再上傳包含文件頭的第一段。 ?

?

連接函數(shù)（Concat Function）

圖：連接函數(shù)（Concat Function）工作流程圖

如上圖所示，我們看一個輸出DRM后的HLS格式文件的例子。圖中，我們讀入.ts的文件塊，在reduce過程中進行加密，并將加密文件上傳到S3中。我們將其合并以提高緩存效率，因為CDN中為列表中每個HLS只創(chuàng)建1個對象。這里的問題主要集中在執(zhí)行方面。

?

執(zhí)行的挑戰(zhàn)

?

我們面臨處理時間方面的挑戰(zhàn)。舉例說明，當我們的AES加密樣本需要重新打包ts流，由于視頻較長，無法在lambda限制的5分鐘內(nèi)完成。我們的解決方案是將lambda function進行菊鏈連接，這樣如果前一個lambda function沒有處理完，就把當前上傳狀態(tài)序列化給下一個lambda function繼續(xù)處理。這里要注意的是，上傳和下載速度不一定是對稱的，當上傳速度成為瓶頸時，需要限制下載速度。我們曾經(jīng)遇到過下載數(shù)據(jù)過多而來不及上傳導(dǎo)致的內(nèi)存不足，所以當你進行類似的流式數(shù)據(jù)處理時，要加上一些背壓(backpressure)。

下面我們講一下部署的問題。

?

部署和CI/CD流水線

圖：部署和CI/CD流水線

考慮到可重現(xiàn)性，我們通常選擇在Docker容器中創(chuàng)建我們的lambda function。創(chuàng)建lambda function所用的git sha和腳本哈希值會成為zip文件名的一部分，這是我們對于不可變基礎(chǔ)架構(gòu)理念的一種探索。但我們生成的新zip文件實際上不會立即替代現(xiàn)有的lambda function，而會生成一個新版本。我們可以對新版本進行測試，確保它可正常工作。當我們足夠自信代碼沒有問題的時候，我們會更新產(chǎn)品環(huán)境中的lambda function的別名，使它指向新版本，這是新代碼才開始在產(chǎn)品環(huán)境中運行。雖然是老生常談，我們感覺，Serverless中很棒的一點就是，它強制你把代碼分拆成API定義良好的小片段，這也基本保證了你的代碼一開始就是可測試的。

下面，我們對Lambda在使用中給一些建議：

• 注意容器復(fù)用的問題。除了注意清理多余的進程以外，一般還要及時清理磁盤的臨時空間或內(nèi)存空間。我們還用到了S3高速緩存和FTP適配器，這些最終會綁定到一個端口上，如果你使用的靜態(tài)端口，程序結(jié)束時要及時釋放，或者像我們一樣使用隨機端口。

• 日志問題。如果多進程出現(xiàn)問題，lambda沙盒提供了很多l(xiāng)inux的實用工具可用來調(diào)試，比如spawn、ps、top，在你的函數(shù)里調(diào)用他們，日志會出現(xiàn)在CloudWatch里，就像一個虛擬機一樣。

• 運行時間可能變化。準備好重試超時的函數(shù)，尤其是網(wǎng)絡(luò)受限的函數(shù)，這些函數(shù)可能只是恰巧超時而已。

?

成果展示

?

• 使用情況統(tǒng)計數(shù)據(jù)。我們現(xiàn)在已處理15萬小時的已轉(zhuǎn)碼視頻，并擁有4億次Lambda Function調(diào)用。

• 成本顯著降低。過去6個月，我們每個月平均支付6000美元的Lambda使用費，而在按需分配的EC2上擁有類似能力（2000計算核心、C4系列等）需要每月花費6萬美元。

• 速度大幅度提升。此前2小時的視頻在EC2上轉(zhuǎn)碼需要4-6個小時，而在Lambda上則不超過10分鐘。

?

幾點思考

• 局限性。一是lambda function有5分鐘的運行時間限制，想生成比如4k 60fps的視頻就很難完成。二是在解碼視頻文件中部的5秒文件塊時，由于我們沒有讀取之前的幀，所以我們需要視頻源格式支持高效的跳轉(zhuǎn)，我們有大量的視頻提供方以及工作室，還沒有遇到過不能高效跳轉(zhuǎn)的情況，但從理論上說，有可能存在這樣的視頻格式。三是Lambda上的CPU每小時的價格要高于EC2。四是解碼開銷。其實解碼工作中很多步驟是重復(fù)的。比如，很多步驟都要解碼2個音頻流、1個視頻流，讀取文件頭里的元數(shù)據(jù)等。

• 未來計劃。一是支持更多種輸出格式。我們也很期待iOS和Android早日統(tǒng)一標準，這樣我們提供一個視頻源即可。二是提升對較小視頻文件處理的效率。

Revvel團隊簡介

Revvel團隊的前身是前Hulu CEO Jason Kilar和CTO Richard Tom創(chuàng)立的短視頻創(chuàng)業(yè)團隊Vessel。Verizon在2016年11月收購了Vessel團隊來服務(wù)與它在數(shù)字媒體業(yè)務(wù)方面的戰(zhàn)略。Revvel團隊主要專注在下一代互聯(lián)網(wǎng)電視產(chǎn)品和服務(wù)。它和雅虎和收購的AOL一起隸屬于Verizon旗下新成立的名為“Oath”的新公司。Revvel總部位于舊金山，其在北京的研發(fā)團隊位于清華科技園附近，專注在大數(shù)據(jù)平臺，搜索和個性化推薦技術(shù)，移動和網(wǎng)頁開發(fā)，以及多媒體編碼技術(shù)等領(lǐng)域。

LiveVideoStack招募全職技術(shù)編輯和社區(qū)編輯

LiveVideoStack是專注在音視頻、多媒體開發(fā)的技術(shù)社區(qū)，通過傳播最新技術(shù)探索與應(yīng)用實踐，幫助技術(shù)人員成長，解決企業(yè)應(yīng)用場景中的技術(shù)難題。如果你有意為音視頻、多媒體開發(fā)領(lǐng)域發(fā)展做出貢獻，歡迎成為LiveVideoStack社區(qū)編輯的一員。你可以翻譯、投稿、采訪、提供內(nèi)容線索等。

通過contribute@livevideostack.com聯(lián)系，或在LiveVideoStack公眾號回復(fù)『技術(shù)編輯』或『社區(qū)編輯』了解詳情。

總結(jié)

以上是生活随笔為你收集整理的Revvel如何将视频转码速度提升几十倍？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。