作者 | 百度人工智能創(chuàng)作團隊
導讀
本文從業(yè)務(wù)出發(fā)，系統(tǒng)介紹了采編式 TTV的實現(xiàn)邏輯和實現(xiàn)路徑。結(jié)合業(yè)務(wù)拆解，實現(xiàn)了一個輕量級服務(wù)編排引擎，有效實現(xiàn)業(yè)務(wù)訴求、高效支持業(yè)務(wù)擴展。
全文6451字，預(yù)計閱讀時間17分鐘。
01 背景
近年來，內(nèi)容視頻化趨勢仍在持續(xù)，短視頻的市場規(guī)模持續(xù)增長，2022年8月CNNIC發(fā)布的數(shù)據(jù)顯示，截至2022年6月，我國網(wǎng)民規(guī)模為10.51億，占網(wǎng)民整體的91.5%。隨著大量短視頻內(nèi)容充斥網(wǎng)絡(luò)，提高視頻生產(chǎn)效率和效果的半智能化、輔助創(chuàng)作工具如視頻剪輯、視頻美化等如雨后春筍般涌現(xiàn)，視頻生產(chǎn)形態(tài)不斷升級。百家號作為百度為內(nèi)容創(chuàng)作者打造的內(nèi)容生產(chǎn)平臺，在內(nèi)容生產(chǎn)方面深耕多年，如能利用百度強大的 AI 能力，以當前百家號圖文內(nèi)容為腳本，實現(xiàn)視頻智能化自動、半自動生產(chǎn)，將會進一步降低視頻創(chuàng)作者的創(chuàng)作成本，帶來視頻創(chuàng)作的進一步發(fā)展。
自 AIGC 項目啟動之后，我們對視頻自動生產(chǎn)方案進行了一系列摸索試驗，最終沉淀出一套完整的解決方案——采編式視頻自動生產(chǎn)。該方案基于一系列微服務(wù)的配合執(zhí)行，如何高效、穩(wěn)定地完成整個流程的組織與調(diào)度是其中一個重要的課題。另外，在早期，整個項目的迭代非常迅速，業(yè)務(wù)發(fā)展變化比較大，如何較好地支持系統(tǒng)擴展與升級，也是我們關(guān)注的重點。本文將系統(tǒng)介紹采編式 AIGC 視頻生產(chǎn)流程的實現(xiàn)方案。
02 采編式視頻生產(chǎn)
所謂的采編式視頻生產(chǎn)，顧名思義，即基于圖文，進行相關(guān)視頻和圖片素材的補充和添加。由圖文到視頻的過程，看似簡單，但作為完全不同的兩種內(nèi)容形態(tài)，這其中還有許多工作要做，按照一般處理方法，主要有以下內(nèi)容：
-
文本處理：由于整個視頻是用圖文做腳本來完成的，所以，視頻主體抽取（這個視頻講述的是什么內(nèi)容）、視頻調(diào)性確認（陽春白雪還是下里巴人）、視頻字幕/旁白生成等，都需要基于充分的內(nèi)容理解，再進行精準的文章主體識別、文章風格識別、口播逐字稿改寫、字幕拆分等工作的進行；
-
素材處理：采編式視頻生產(chǎn)的核心，是要將碎片化的素材基于圖文腳本進行合理的編排，故而進行視頻和圖片素材的在線檢索、剪裁、清洗等必不可少；
-
語音處理：語音播報作為視頻的關(guān)鍵元素，在視頻生產(chǎn)中是必不可少的一環(huán)，需要基于圖文進行合理的語音合成與添加；
-
其他視頻元素添加：視頻標注、水印、動效、背景音樂、背景視頻、前置氛圍渲染等元素的添加，能夠更好地豐富視頻效果；
-
視頻合成：將采編好的腳本文件，利用視頻合成技術(shù)進行視頻渲染輸出。
△圖1 采編式視頻生產(chǎn)
如圖1，不同于一般的業(yè)務(wù)流程，采編式視頻生產(chǎn)需要基于大量的媒體數(shù)據(jù)處理，整個處理過程是無人工干預(yù)的全自動化過程，如何將這些服務(wù)進行有效地編排與調(diào)度，是整個視頻生產(chǎn)的關(guān)鍵問題。
03 服務(wù)編排常見方案
3.1『狀態(tài)機』流程調(diào)度
常見的服務(wù)編排，一般都采取利用定時任務(wù)、消息隊列、持久化存儲等工具進行微服務(wù)的拼接串聯(lián)。這個方案需要在流程中定義關(guān)鍵的狀態(tài)節(jié)點，來標記每個微服務(wù)的執(zhí)行狀態(tài)，并將狀態(tài)記錄到 MySQL 等 持久化存儲中，再通過定時任務(wù)或者消息隊列來驅(qū)動整個流程的流轉(zhuǎn)。
△圖2 狀態(tài)機流程調(diào)度
可以看到，該方案是一個可控性較高的流程編排與調(diào)度的方案，整個系統(tǒng)的復雜度、穩(wěn)定性與業(yè)務(wù)復雜度、系統(tǒng)設(shè)計合理性息息相關(guān)，更適合一些變動較大、相對輕量級的業(yè)務(wù)。
3.2 服務(wù)編排引擎
隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展、微服務(wù)的普及，服務(wù)編排的解決方案也日益成熟，涌現(xiàn)出一批成熟優(yōu)秀的服務(wù)編排引擎。業(yè)內(nèi)比較成熟的服務(wù)編排引擎有 Cadence、Temporal、Conductor等。
服務(wù)編排引擎會進行基礎(chǔ)的流程、任務(wù)、節(jié)點等基礎(chǔ)元素的定義，提供流程啟動、任務(wù)調(diào)度、狀態(tài)監(jiān)控等基礎(chǔ)能力，具備對于編排完成的服務(wù)或者流程在運行時進行動態(tài)、端到端可視化監(jiān)控的能力。以 Cadence 編程模型為例說明一般編排引擎的編程模型：
△圖3. Cadence編程模型
服務(wù)編排引擎一般都有一個中央調(diào)度系統(tǒng)，同時提供一些外部可調(diào) api，開發(fā)人員只需要通過對框架能力的調(diào)用來實現(xiàn)業(yè)務(wù)邏輯而不需要關(guān)注系統(tǒng)的調(diào)度運行，甚至包括系統(tǒng)的超時處理、失敗重試、異常兜底，框架都會代為處理，提升業(yè)務(wù)研發(fā)的效率。相應(yīng)地，成熟的框架都有一定的接入門檻和運維成本，比較適合大型項目。
04 采編式AIGC 視頻生產(chǎn)流程編排實踐
由于 AIGC 視頻生產(chǎn)業(yè)務(wù)發(fā)展迅速，迭代速度非常快，對成熟流程調(diào)度框架的調(diào)研中，遇到了系統(tǒng)利用率低、問題追查成本高的問題，為了快速支持業(yè)務(wù)、保障系統(tǒng)的穩(wěn)定性與可用性，我們謹慎地選擇了基于狀態(tài)的流程調(diào)度方案，并在此基礎(chǔ)上參考流程編排框架的思想，建設(shè)一套底層中央編排器，驅(qū)動上層微服務(wù)的執(zhí)行。整體思想可以概括為：
-
從上而下地，基于功能對整個流程進行模塊拆分、基于實現(xiàn)對模塊進行組件拆分，對模塊進行狀態(tài)管理、對組件進行位值管理
-
利用消息隊列實現(xiàn)流程串聯(lián)，通過對狀態(tài)與位值的判斷實現(xiàn)流程調(diào)度
-
通過對模塊與組件的組合配置實現(xiàn)流程組織
4.1 模塊與組件的拆分與管理
首先基于對需求的理解，對整個編排流程進行了模塊拆分，并對每一個模塊進行相關(guān)的狀態(tài)賦值，拆分的模塊有：
-
圖文接入模塊：接入上層業(yè)務(wù)或者外部業(yè)務(wù)的文本內(nèi)容輸入，進行基礎(chǔ)的數(shù)據(jù)解析、校驗、打平與過濾功能；
-
腳本編排模塊：實現(xiàn)從圖文到視頻腳本的生成功能，該模塊的輸入為圖文，輸出為編排好的視頻腳本，包含三條時間軸：①素材軸②文本與語音軸③掛件軸，定義了視頻任意一個時間點對應(yīng)的文本、素材與相關(guān)掛件。視頻腳本不僅可以用于視頻渲染，還可輸出給用戶作為視頻編輯的草稿；
-
視頻合成模塊：實現(xiàn)從視頻腳本到視頻文件的生成，該模塊執(zhí)行完成之后就已經(jīng)產(chǎn)生了可播放的視頻文件，標志著視頻生成完成；
-
視頻輸出模塊：將視頻文件按照業(yè)務(wù)需求輸出，包括但不限于發(fā)布到百家號、回傳業(yè)務(wù)方等。
在整個生產(chǎn)流程中，完成一個視頻的生產(chǎn)，所需要的功能模塊是固定的，但是實現(xiàn)的方式與方法可能會持續(xù)地擴展與迭代，為了便于后續(xù)狀態(tài)的管理與功能的擴展，采取了大的功能模塊包含小的功能組件的方式，這種方式的優(yōu)點有二：
-
方便數(shù)據(jù)輸出：在腳本編排模塊完成之后進行視頻腳本的輸出并提供給多個業(yè)務(wù)方使用，無論模塊內(nèi)部如何擴展，腳本輸出的時機是固定的，視頻文件的輸出同理；
-
方便功能擴展：隨著業(yè)務(wù)的發(fā)展，功能實現(xiàn)的方案升級甚至替換是不可避免的，模塊內(nèi)部提供原子化功能組件，可以方便地進行單功能的升級迭代或者添加，而不影響整體其他組件
為了方便微服務(wù)的調(diào)用狀態(tài)管理，我們又為每個微服務(wù)賦予了位值，所謂位值是當前組件在一個64位整數(shù)所處的二進制位次，每個組件占據(jù)兩位，枚舉標記成功和失敗狀態(tài)，我們只需要校驗對應(yīng)位次的值，即可判斷當前組件的調(diào)用狀態(tài)與返回狀態(tài)。
△圖4 模塊與組件拆分
至此，我們通過『狀態(tài)』實現(xiàn)了對整個生產(chǎn)流程模塊的管理，又通過『調(diào)用位』、『返回位』實現(xiàn)了對具體組件的管理。其中，狀態(tài)管理較好理解，主要是通過持久化存儲一個狀態(tài)字段，來標記當前流程所處模塊，如圖3所示，當某一條視頻生成任務(wù)狀態(tài)值為INIT時即可知當前任務(wù)處于視頻腳本編排模塊，但是具體在執(zhí)行哪個或者哪些微服務(wù)呢？如上文所言是通過位值來確認的，對于位值的應(yīng)用相對較為復雜，下面我們就詳細闡述一下位值的應(yīng)用。
△圖5槽位值原理示意圖
如圖5所示，『調(diào)用位』、『返回位』都是一個 UINT64整數(shù)，每兩位組合可以有4個狀態(tài)，我們?nèi)∏叭齻€狀態(tài)進行調(diào)用或返回狀態(tài)的表示。每一個組件在注冊進入系統(tǒng)時，都會先分配一個位次（如圖3所示，1即表示占據(jù)槽位值的低兩位），如此一來，某個組件狀態(tài)發(fā)生變更時通過二進制操作修改對應(yīng)二進制位的值即可。
該方案的優(yōu)點是能夠通過一個整形值管理32個組件的請求或返回狀態(tài)，且每個組件的狀態(tài)修改互不影響。當然這也帶來一個問題，即該方案最多只能管理32個組件，更多組件需要管理時就要擴展字段或者采取其他方案，同時雖然變更某個組件槽位值不影響其他組件，但當出現(xiàn)服務(wù)并行需要將修改后的槽位值更新存儲時，需要確保更新的事務(wù)性，這個問題的解決我們會在后面的流程調(diào)度中完成。
4.2 流程配置
在完成了組件與模塊的拆分與確定之后，即可根據(jù)業(yè)務(wù)邏輯，基于組件之間的相互依賴關(guān)系進行流程編排配置。流程搭建采取配置化、插拔式方案，將業(yè)務(wù)所需組件放進對應(yīng)模塊，編排出所需的視頻生產(chǎn)流程，如圖5所示為當前采編式 AIGC 視頻生產(chǎn)流程的流程圖，在當前業(yè)務(wù)狀態(tài)下，存在相互依賴關(guān)系的組件如圖文理解、插件選擇、文本處理在整個流程中串行執(zhí)行，有相同前置依賴但彼此不依賴的組件如素材生成、素材檢索、語音合成則應(yīng)該并行執(zhí)行：
△圖6 采編式 AIGC 視頻生產(chǎn)流程
如要實現(xiàn)一個任務(wù)流程，按照上述流程圖執(zhí)行，那么首先需要有這樣一個流程描述文件，該文件按照一定的規(guī)則組織，包含一個流程完成所需的所有組件，并能夠準確描述這些組件的執(zhí)行順序與相互依賴關(guān)系，在此基礎(chǔ)上，如能描述當前組件所處模塊、狀態(tài)，那么對于流程理解以及后續(xù)流程執(zhí)行都有很大助益?；谝陨峡紤]，我們采取以組件為最小單位，組合生成配置文件：
{
……
{ // 腳本編排模塊
"module_name":"ScriptAssign",
"status":"init",
"next_status":"generating",
"components":[
……
{
"component_name" : "TextProcessor", // 組件名稱，文本處理組件
"slot_index":2, // 組件位次，第三位（index從0開始），表示低第五六兩個二進制位
"slot_num_success": 16, // 2^(2*slot_index) 成功時，要將『低第五位』置為1，同時確?！旱偷诹弧粸?，具體在進行位置計算時實現(xiàn)
"slot_num_fail":32, // 2^(2*slot_index+1) 失敗時，要將『低第六位』置為1，同時確?！旱偷谖逦弧粸?
"depends":["TextUnderstanding","WidgetInit"] // 文本處理組件執(zhí)行，依賴文本理解與插件選擇組件執(zhí)行完成
}，
……
{
"component_name" : "FootageGenerator", // 素材生成組件
"slot_index":3,
"slot_num_success":64,
"slot_num_fail":128,
"depends":["TextUnderstanding","WidgetInit","TextProcessor"] // 依賴前面三個組件
}，
{
"component_name" : "MaterialSearch", // 素材檢索組件
"slot_index":4,
"slot_num_success":256,
"slot_num_fail":512,
"depends":["TextUnderstanding","WidgetInit","TextProcessor"] // 也只依賴前面三個組件
}，
……
]
},
{ // 視頻生成模塊
"module_name":"VideoGenerator",
"status":"generating",
"next_status":"draft",
"components":[
{
"component_name" : "VideoRender",
"slot_index":7,
"slot_num_success": "2^14",// 2的14次方
"slot_num_fail":"2^15",// 2的15次方
"depends":[""] // 在當前模塊內(nèi)，沒有前置依賴
}
]
}
……
}
流程描述文件的組織邏輯為：
-
基本描述單元為組件，說明組件在流程中所在位次與對應(yīng)的槽位值、組件執(zhí)行的前置依賴組件
-
每個組件只關(guān)注自身執(zhí)行所需關(guān)鍵信息，不關(guān)注其他組件的執(zhí)行邏輯
-
在同一個模塊內(nèi)的組件，組合成為模塊單元，模塊單元關(guān)注當前模塊狀態(tài)，以及當前模塊執(zhí)行完畢之后的下一個狀態(tài)
-
所有模塊按照執(zhí)行順序（因為模塊是絕對串行的）組織成完整流程描述文件
后續(xù)的整體流程調(diào)度，將以該文件為藍本執(zhí)行。同時，可以看到，一個描述文件即規(guī)定了一個流程，如果我們有不同的業(yè)務(wù)場景需要不同的執(zhí)行流程，那么只需要再編排一個流程調(diào)度文件即可，事實上，我們的AIGC 業(yè)務(wù)也確實存在多條流程，整體編排邏輯同理，不多贅述。
4.3 流程調(diào)度
服務(wù)編排框架的核心，是流程調(diào)度部分，該部分負責維持與推動數(shù)據(jù)流的運轉(zhuǎn)。如上文所述，每個組件的狀態(tài)都通過相對應(yīng)的位值來維護，流程調(diào)度的關(guān)鍵就在于對位值的管理。整體流程如圖4所示，整個流程調(diào)度通過消息隊列串聯(lián)，主要操作步驟如下：
①任務(wù)創(chuàng)建：該步驟在一個任務(wù)執(zhí)行全流程中只執(zhí)行一次，主要在前置的參數(shù)檢查校驗工作完成之后，進行數(shù)據(jù)的入庫操作，并將任務(wù)下發(fā)流程調(diào)度消息隊列，觸發(fā)整體流程。
②查找可執(zhí)行組件并執(zhí)行：該步驟在一個任務(wù)執(zhí)行全流程中會執(zhí)行多次，在正常情況下，與組件個數(shù)等同。該步驟主要負責從消息隊列中拉取數(shù)據(jù)，遍歷流程描述文件，通過計算當前任務(wù)的調(diào)用/返回槽位值，推算出各個組件執(zhí)行狀態(tài)，若某個組件未執(zhí)行、且其依賴的前置組件已執(zhí)行完畢，則將該組件加入執(zhí)行隊列；若未找到可執(zhí)行組件，則本次不執(zhí)行。在這一步中，若組件內(nèi)部存在異步微服務(wù)，則僅作微服務(wù)觸發(fā)，若為同步組件，則會在執(zhí)行完畢之后，將任務(wù)再次加入流程調(diào)度消息隊列。
③異步回調(diào)：我們大部分組件都是異步微服務(wù)，故而在第二步中觸發(fā)微服務(wù)調(diào)用之后，這一環(huán)節(jié)主要功能是接收微服務(wù)回調(diào)，并做相關(guān)后置業(yè)務(wù)處理，處理完成之后，再將任務(wù)再次加入流程調(diào)度消息隊列。
△圖7 任務(wù)調(diào)度流程圖
在這個流程里我們通過消息隊列的調(diào)度解耦了組件之間的相互依賴，僅通過槽位值查詢與校驗來實現(xiàn)流程的流轉(zhuǎn)與執(zhí)行，這使得系統(tǒng)具備了組件的并發(fā)性，只要定義好每個組件執(zhí)行的前置依賴，那么當一個組件執(zhí)行完成之后所有依賴這個組件的后置組件都可以開始執(zhí)行。那么，這時候會出現(xiàn)另外一個問題，我們?nèi)绾伪ＷC并行執(zhí)行完成之后的槽位值更新不彼此覆蓋？如果兩個組件同時執(zhí)行完成，但每個組件只會計算并修改自身槽位值，如何保證后更新的槽位值不覆蓋前一個組件的槽位值？這個問題的解決我們是通過利用消息隊列的重試做后置更新結(jié)合更新鎖來完成的：在每個組件執(zhí)行完成之后只會更新自身涉及的業(yè)務(wù)字段，而不更新狀態(tài)及槽位值，狀態(tài)管理的三個值是在步驟二中前置執(zhí)行的，每次從消息隊列中拉取一個任務(wù)后會先進性狀態(tài)的檢查和槽位值的更新，更新前會先加唯一鎖，若加鎖失敗則可能其他組件正在做狀態(tài)更新，則退出執(zhí)行，該任務(wù)依然在消息隊列里未消費，待下一次繼續(xù)執(zhí)行。
05 總結(jié)
采編式 AIGC 視頻生產(chǎn)流程2022年5月上線以來，已經(jīng)根據(jù)不同的業(yè)務(wù)場景，通過對基礎(chǔ)模塊和組件的組合配置建設(shè)起5條不同的生產(chǎn)流程，很好地支持萬級日產(chǎn)的業(yè)務(wù)發(fā)展。隨著業(yè)務(wù)的迭代深入，相關(guān)組件的功能及代碼量都在日益膨脹，我們成功地在當前框架下進行組件的拆分與擴展，在不觸動底層調(diào)度框架基礎(chǔ)上，安全高效地完成了組件的擴展。雖然當前框架對目前的業(yè)務(wù)支持良好，但是整個流程的優(yōu)化和迭代還在繼續(xù)，對成熟服務(wù)編排引擎的調(diào)研也在繼續(xù)，希望后續(xù)在借鑒成熟框架的基礎(chǔ)上，能夠沉淀出更為穩(wěn)定高效的視頻生產(chǎn)流程。
——END——
參考資料：
[1]https://cadenceworkflow.io/docs/get-started/
[2]https://docs.temporal.io/temporal/
[3]https://conductor.netflix.com/architecture/overview.html
[4]https://netflixtechblog.com/netflix-conductor-a-microservices-orchestrator-2e8d4771bf40
推薦閱讀：
百度工程師漫談視頻理解
百度工程師帶你了解Module Federation
巧用Golang泛型，簡化代碼編寫
Go語言DDD實戰(zhàn)初級篇
Diffie-Hellman密鑰協(xié)商算法探究文章來源：http://www.zghlxwxcb.cn/news/detail-648556.html
貼吧低代碼高性能規(guī)則引擎設(shè)計文章來源地址http://www.zghlxwxcb.cn/news/detail-648556.html
到了這里，關(guān)于采編式AIGC視頻生產(chǎn)流程編排實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
