本文從業(yè)務(wù)出發(fā)，系統(tǒng)介紹了采編式 TTV的實現(xiàn)邏輯和實現(xiàn)路徑。結(jié)合業(yè)務(wù)拆解，實現(xiàn)了一個輕量級服務(wù)編排引擎，有效實現(xiàn)業(yè)務(wù)訴求、高效支持業(yè)務(wù)擴(kuò)展。

GEEK TALK

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)方面深耕多年，如能利用百度強(qiáng)大的 AI 能力，以當(dāng)前百家號圖文內(nèi)容為腳本，實現(xiàn)視頻智能化自動、半自動生產(chǎn)，將會進(jìn)一步降低視頻創(chuàng)作者的創(chuàng)作成本，帶來視頻創(chuàng)作的進(jìn)一步發(fā)展。

自 AIGC 項目啟動之后，我們對視頻自動生產(chǎn)方案進(jìn)行了一系列摸索試驗，最終沉淀出一套完整的解決方案——采編式視頻自動生產(chǎn)。該方案基于一系列微服務(wù)的配合執(zhí)行，如何高效、穩(wěn)定地完成整個流程的組織與調(diào)度是其中一個重要的課題。另外，在早期，整個項目的迭代非常迅速，業(yè)務(wù)發(fā)展變化比較大，如何較好地支持系統(tǒng)擴(kuò)展與升級，也是我們關(guān)注的重點。本文將系統(tǒng)介紹采編式 AIGC 視頻生產(chǎn)流程的實現(xiàn)方案。

GEEK TALK

02

采編式視頻生產(chǎn)

所謂的采編式視頻生產(chǎn)，顧名思義，即基于圖文，進(jìn)行相關(guān)視頻和圖片素材的補(bǔ)充和添加。由圖文到視頻的過程，看似簡單，但作為完全不同的兩種內(nèi)容形態(tài)，這其中還有許多工作要做，按照一般處理方法，主要有以下內(nèi)容：

文本處理：由于整個視頻是用圖文做腳本來完成的，所以，視頻主體抽取（這個視頻講述的是什么內(nèi)容）、視頻調(diào)性確認(rèn)（陽春白雪還是下里巴人）、視頻字幕/旁白生成等，都需要基于充分的內(nèi)容理解，再進(jìn)行精準(zhǔn)的文章主體識別、文章風(fēng)格識別、口播逐字稿改寫、字幕拆分等工作的進(jìn)行；

素材處理：采編式視頻生產(chǎn)的核心，是要將碎片化的素材基于圖文腳本進(jìn)行合理的編排，故而進(jìn)行視頻和圖片素材的在線檢索、剪裁、清洗等必不可少；

語音處理：語音播報作為視頻的關(guān)鍵元素，在視頻生產(chǎn)中是必不可少的一環(huán)，需要基于圖文進(jìn)行合理的語音合成與添加；

其他視頻元素添加：視頻標(biāo)注、水印、動效、背景音樂、背景視頻、前置氛圍渲染等元素的添加，能夠更好地豐富視頻效果；

視頻合成：將采編好的腳本文件，利用視頻合成技術(shù)進(jìn)行視頻渲染輸出。

△圖1 采編式視頻生產(chǎn)

如圖1，不同于一般的業(yè)務(wù)流程，采編式視頻生產(chǎn)需要基于大量的媒體數(shù)據(jù)處理，整個處理過程是無人工干預(yù)的全自動化過程，如何將這些服務(wù)進(jìn)行有效地編排與調(diào)度，是整個視頻生產(chǎn)的關(guān)鍵問題。

GEEK TALK

03

服務(wù)編排常見方案

3.1『狀態(tài)機(jī)』流程調(diào)度

常見的服務(wù)編排，一般都采取利用定時任務(wù)、消息隊列、持久化存儲等工具進(jìn)行微服務(wù)的拼接串聯(lián)。這個方案需要在流程中定義關(guān)鍵的狀態(tài)節(jié)點，來標(biāo)記每個微服務(wù)的執(zhí)行狀態(tài)，并將狀態(tài)記錄到 MySQL 等 持久化存儲中，再通過定時任務(wù)或者消息隊列來驅(qū)動整個流程的流轉(zhuǎn)。

△圖2 狀態(tài)機(jī)流程調(diào)度

可以看到，該方案是一個可控性較高的流程編排與調(diào)度的方案，整個系統(tǒng)的復(fù)雜度、穩(wěn)定性與業(yè)務(wù)復(fù)雜度、系統(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ù)編排引擎會進(jìn)行基礎(chǔ)的流程、任務(wù)、節(jié)點等基礎(chǔ)元素的定義，提供流程啟動、任務(wù)調(diào)度、狀態(tài)監(jiān)控等基礎(chǔ)能力，具備對于編排完成的服務(wù)或者流程在運行時進(jìn)行動態(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)地，成熟的框架都有一定的接入門檻和運維成本，比較適合大型項目。

GEEK TALK

04

采編式AIGC 視頻生產(chǎn)流程編排實踐

由于 AIGC 視頻生產(chǎn)業(yè)務(wù)發(fā)展迅速，迭代速度非常快，對成熟流程調(diào)度框架的調(diào)研中，遇到了系統(tǒng)利用率低、問題追查成本高的問題，為了快速支持業(yè)務(wù)、保障系統(tǒng)的穩(wěn)定性與可用性，我們謹(jǐn)慎地選擇了基于狀態(tài)的流程調(diào)度方案，并在此基礎(chǔ)上參考流程編排框架的思想，建設(shè)一套底層中央編排器，驅(qū)動上層微服務(wù)的執(zhí)行。整體思想可以概括為：

從上而下地，基于功能對整個流程進(jìn)行模塊拆分、基于實現(xiàn)對模塊進(jìn)行組件拆分，對模塊進(jìn)行狀態(tài)管理、對組件進(jìn)行位值管理

利用消息隊列實現(xiàn)流程串聯(lián)，通過對狀態(tài)與位值的判斷實現(xiàn)流程調(diào)度

通過對模塊與組件的組合配置實現(xiàn)流程組織

4.1模塊與組件的拆分與管理

首先基于對需求的理解，對整個編排流程進(jìn)行了模塊拆分，并對每一個模塊進(jìn)行相關(guān)的狀態(tài)賦值，拆分的模塊有：

圖文接入模塊：接入上層業(yè)務(wù)或者外部業(yè)務(wù)的文本內(nèi)容輸入，進(jìn)行基礎(chǔ)的數(shù)據(jù)解析、校驗、打平與過濾功能；

腳本編排模塊：實現(xiàn)從圖文到視頻腳本的生成功能，該模塊的輸入為圖文，輸出為編排好的視頻腳本，包含三條時間軸：①素材軸②文本與語音軸③掛件軸，定義了視頻任意一個時間點對應(yīng)的文本、素材與相關(guān)掛件。視頻腳本不僅可以用于視頻渲染，還可輸出給用戶作為視頻編輯的草稿；

視頻合成模塊：實現(xiàn)從視頻腳本到視頻文件的生成，該模塊執(zhí)行完成之后就已經(jīng)產(chǎn)生了可播放的視頻文件，標(biāo)志著視頻生成完成；

視頻輸出模塊：將視頻文件按照業(yè)務(wù)需求輸出，包括但不限于發(fā)布到百家號、回傳業(yè)務(wù)方等。

在整個生產(chǎn)流程中，完成一個視頻的生產(chǎn)，所需要的功能模塊是固定的，但是實現(xiàn)的方式與方法可能會持續(xù)地擴(kuò)展與迭代，為了便于后續(xù)狀態(tài)的管理與功能的擴(kuò)展，采取了大的功能模塊包含小的功能組件的方式，這種方式的優(yōu)點有二：

方便數(shù)據(jù)輸出：在腳本編排模塊完成之后進(jìn)行視頻腳本的輸出并提供給多個業(yè)務(wù)方使用，無論模塊內(nèi)部如何擴(kuò)展，腳本輸出的時機(jī)是固定的，視頻文件的輸出同理；

方便功能擴(kuò)展：隨著業(yè)務(wù)的發(fā)展，功能實現(xiàn)的方案升級甚至替換是不可避免的，模塊內(nèi)部提供原子化功能組件，可以方便地進(jìn)行單功能的升級迭代或者添加，而不影響整體其他組件

為了方便微服務(wù)的調(diào)用狀態(tài)管理，我們又為每個微服務(wù)賦予了位值，所謂位值是當(dāng)前組件在一個64位整數(shù)所處的二進(jìn)制位次，每個組件占據(jù)兩位，枚舉標(biāo)記成功和失敗狀態(tài)，我們只需要校驗對應(yīng)位次的值，即可判斷當(dāng)前組件的調(diào)用狀態(tài)與返回狀態(tài)。

△圖4 模塊與組件拆分

至此，我們通過『狀態(tài)』實現(xiàn)了對整個生產(chǎn)流程模塊的管理，又通過『調(diào)用位』、『返回位』實現(xiàn)了對具體組件的管理。其中，狀態(tài)管理較好理解，主要是通過持久化存儲一個狀態(tài)字段，來標(biāo)記當(dāng)前流程所處模塊，如圖3所示，當(dāng)某一條視頻生成任務(wù)狀態(tài)值為INIT時即可知當(dāng)前任務(wù)處于視頻腳本編排模塊，但是具體在執(zhí)行哪個或者哪些微服務(wù)呢？如上文所言是通過位值來確認(rèn)的，對于位值的應(yīng)用相對較為復(fù)雜，下面我們就詳細(xì)闡述一下位值的應(yīng)用。

△圖5槽位值原理示意圖

如圖5所示，『調(diào)用位』、『返回位』都是一個 UINT64整數(shù)，每兩位組合可以有4個狀態(tài)，我們?nèi)∏叭齻€狀態(tài)進(jìn)行調(diào)用或返回狀態(tài)的表示。每一個組件在注冊進(jìn)入系統(tǒng)時，都會先分配一個位次（如圖3所示，1即表示占據(jù)槽位值的低兩位），如此一來，某個組件狀態(tài)發(fā)生變更時通過二進(jìn)制操作修改對應(yīng)二進(jìn)制位的值即可。

該方案的優(yōu)點是能夠通過一個整形值管理32個組件的請求或返回狀態(tài)，且每個組件的狀態(tài)修改互不影響。當(dāng)然這也帶來一個問題，即該方案最多只能管理32個組件，更多組件需要管理時就要擴(kuò)展字段或者采取其他方案，同時雖然變更某個組件槽位值不影響其他組件，但當(dāng)出現(xiàn)服務(wù)并行需要將修改后的槽位值更新存儲時，需要確保更新的事務(wù)性，這個問題的解決我們會在后面的流程調(diào)度中完成。

4.2流程配置

在完成了組件與模塊的拆分與確定之后，即可根據(jù)業(yè)務(wù)邏輯，基于組件之間的相互依賴關(guān)系進(jìn)行流程編排配置。流程搭建采取配置化、插拔式方案，將業(yè)務(wù)所需組件放進(jìn)對應(yīng)模塊，編排出所需的視頻生產(chǎn)流程，如圖5所示為當(dāng)前采編式 AIGC 視頻生產(chǎn)流程的流程圖，在當(dāng)前業(yè)務(wù)狀態(tài)下，存在相互依賴關(guān)系的組件如圖文理解、插件選擇、文本處理在整個流程中串行執(zhí)行，有相同前置依賴但彼此不依賴的組件如素材生成、素材檢索、語音合成則應(yīng)該并行執(zhí)行：

△圖6 采編式 AIGC 視頻生產(chǎn)流程

如要實現(xiàn)一個任務(wù)流程，按照上述流程圖執(zhí)行，那么首先需要有這樣一個流程描述文件，該文件按照一定的規(guī)則組織，包含一個流程完成所需的所有組件，并能夠準(zhǔn)確描述這些組件的執(zhí)行順序與相互依賴關(guān)系，在此基礎(chǔ)上，如能描述當(dāng)前組件所處模塊、狀態(tài)，那么對于流程理解以及后續(xù)流程執(zhí)行都有很大助益。基于以上考慮，我們采取以組件為最小單位，組合生成配置文件：

{ …… { // 腳本編排模塊 "module_name":"ScriptAssign", "status":"init", "next_status":"generating", "components":[ …… { "component_name" : "TextProcessor", // 組件名稱，文本處理組件 "slot_index":2, // 組件位次，第三位（index從0開始），表示低第五六兩個二進(jìn)制位 "slot_num_success": 16, // 2^(2*slot_index) 成功時，要將『低第五位』置為1，同時確保『低第六位』為0，具體在進(jìn)行位置計算時實現(xiàn) "slot_num_fail":32, // 2^(2*slot_index+1) 失敗時，要將『低第六位』置為1，同時確保『低第五位』為0 "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":[""] // 在當(dāng)前模塊內(nèi)，沒有前置依賴 } ] } …… }

流程描述文件的組織邏輯為：

基本描述單元為組件，說明組件在流程中所在位次與對應(yīng)的槽位值、組件執(zhí)行的前置依賴組件

每個組件只關(guān)注自身執(zhí)行所需關(guān)鍵信息，不關(guān)注其他組件的執(zhí)行邏輯

在同一個模塊內(nèi)的組件，組合成為模塊單元，模塊單元關(guān)注當(dāng)前模塊狀態(tài)，以及當(dāng)前模塊執(zhí)行完畢之后的下一個狀態(tài)

所有模塊按照執(zhí)行順序（因為模塊是絕對串行的）組織成完整流程描述文件

后續(xù)的整體流程調(diào)度，將以該文件為藍(lán)本執(zhí)行。同時，可以看到，一個描述文件即規(guī)定了一個流程，如果我們有不同的業(yè)務(wù)場景需要不同的執(zhí)行流程，那么只需要再編排一個流程調(diào)度文件即可，事實上，我們的AIGC 業(yè)務(wù)也確實存在多條流程，整體編排邏輯同理，不多贅述。

4.3流程調(diào)度

服務(wù)編排框架的核心，是流程調(diào)度部分，該部分負(fù)責(zé)維持與推動數(shù)據(jù)流的運轉(zhuǎn)。如上文所述，每個組件的狀態(tài)都通過相對應(yīng)的位值來維護(hù)，流程調(diào)度的關(guān)鍵就在于對位值的管理。整體流程如圖4所示，整個流程調(diào)度通過消息隊列串聯(lián)，主要操作步驟如下：

①任務(wù)創(chuàng)建：該步驟在一個任務(wù)執(zhí)行全流程中只執(zhí)行一次，主要在前置的參數(shù)檢查校驗工作完成之后，進(jìn)行數(shù)據(jù)的入庫操作，并將任務(wù)下發(fā)流程調(diào)度消息隊列，觸發(fā)整體流程。

②查找可執(zhí)行組件并執(zhí)行：該步驟在一個任務(wù)執(zhí)行全流程中會執(zhí)行多次，在正常情況下，與組件個數(shù)等同。該步驟主要負(fù)責(zé)從消息隊列中拉取數(shù)據(jù)，遍歷流程描述文件，通過計算當(dāng)前任務(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í)行的前置依賴，那么當(dāng)一個組件執(zhí)行完成之后所有依賴這個組件的后置組件都可以開始執(zhí)行。那么，這時候會出現(xiàn)另外一個問題，我們?nèi)绾伪ＷC并行執(zhí)行完成之后的槽位值更新不彼此覆蓋？如果兩個組件同時執(zhí)行完成，但每個組件只會計算并修改自身槽位值，如何保證后更新的槽位值不覆蓋前一個組件的槽位值？這個問題的解決我們是通過利用消息隊列的重試做后置更新結(jié)合更新鎖來完成的：在每個組件執(zhí)行完成之后只會更新自身涉及的業(yè)務(wù)字段，而不更新狀態(tài)及槽位值，狀態(tài)管理的三個值是在步驟二中前置執(zhí)行的，每次從消息隊列中拉取一個任務(wù)后會先進(jìn)性狀態(tài)的檢查和槽位值的更新，更新前會先加唯一鎖，若加鎖失敗則可能其他組件正在做狀態(tài)更新，則退出執(zhí)行，該任務(wù)依然在消息隊列里未消費，待下一次繼續(xù)執(zhí)行。

GEEK TALK

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)組件的功能及代碼量都在日益膨脹，我們成功地在當(dāng)前框架下進(jìn)行組件的拆分與擴(kuò)展，在不觸動底層調(diào)度框架基礎(chǔ)上，安全高效地完成了組件的擴(kuò)展。雖然當(dāng)前框架對目前的業(yè)務(wù)支持良好，但是整個流程的優(yōu)化和迭代還在繼續(xù)，對成熟服務(wù)編排引擎的調(diào)研也在繼續(xù)，希望后續(xù)在借鑒成熟框架的基礎(chǔ)上，能夠沉淀出更為穩(wěn)定高效的視頻生產(chǎn)流程。

審核編輯 ：李倩