本文從業務出發，系統介紹了采編式 TTV的實現邏輯和實現路徑。結合業務拆解，實現了一個輕量級服務編排引擎，有效實現業務訴求、高效支持業務擴展。

GEEK TALK

01

背景

近年來，內容視頻化趨勢仍在持續，短視頻的市場規模持續增長，2022年8月CNNIC發布的數據顯示，截至2022年6月，我國網民規模為10.51億，占網民整體的91.5%。隨著大量短視頻內容充斥網絡，提高視頻生產效率和效果的半智能化、輔助創作工具如視頻剪輯、視頻美化等如雨后春筍般涌現，視頻生產形態不斷升級。百家號作為百度為內容創作者打造的內容生產平臺，在內容生產方面深耕多年，如能利用百度強大的 AI 能力，以當前百家號圖文內容為腳本，實現視頻智能化自動、半自動生產，將會進一步降低視頻創作者的創作成本，帶來視頻創作的進一步發展。

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

GEEK TALK

02

采編式視頻生產

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

文本處理：由于整個視頻是用圖文做腳本來完成的，所以，視頻主體抽?。ㄟ@個視頻講述的是什么內容）、視頻調性確認（陽春白雪還是下里巴人）、視頻字幕/旁白生成等，都需要基于充分的內容理解，再進行精準的文章主體識別、文章風格識別、口播逐字稿改寫、字幕拆分等工作的進行；

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

語音處理：語音播報作為視頻的關鍵元素，在視頻生產中是必不可少的一環，需要基于圖文進行合理的語音合成與添加；

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

視頻合成：將采編好的腳本文件，利用視頻合成技術進行視頻渲染輸出。

△圖1 采編式視頻生產

如圖1，不同于一般的業務流程，采編式視頻生產需要基于大量的媒體數據處理，整個處理過程是無人工干預的全自動化過程，如何將這些服務進行有效地編排與調度，是整個視頻生產的關鍵問題。

GEEK TALK

03

服務編排常見方案

3.1『狀態機』流程調度

常見的服務編排，一般都采取利用定時任務、消息隊列、持久化存儲等工具進行微服務的拼接串聯。這個方案需要在流程中定義關鍵的狀態節點，來標記每個微服務的執行狀態，并將狀態記錄到 MySQL 等 持久化存儲中，再通過定時任務或者消息隊列來驅動整個流程的流轉。

△圖2 狀態機流程調度

可以看到，該方案是一個可控性較高的流程編排與調度的方案，整個系統的復雜度、穩定性與業務復雜度、系統設計合理性息息相關，更適合一些變動較大、相對輕量級的業務。

3.2服務編排引擎

隨著互聯網技術的不斷發展、微服務的普及，服務編排的解決方案也日益成熟，涌現出一批成熟優秀的服務編排引擎。業內比較成熟的服務編排引擎有 Cadence、Temporal、Conductor等。

服務編排引擎會進行基礎的流程、任務、節點等基礎元素的定義，提供流程啟動、任務調度、狀態監控等基礎能力，具備對于編排完成的服務或者流程在運行時進行動態、端到端可視化監控的能力。以 Cadence 編程模型為例說明一般編排引擎的編程模型：

△圖3. Cadence編程模型

服務編排引擎一般都有一個中央調度系統，同時提供一些外部可調 api，開發人員只需要通過對框架能力的調用來實現業務邏輯而不需要關注系統的調度運行，甚至包括系統的超時處理、失敗重試、異常兜底，框架都會代為處理，提升業務研發的效率。相應地，成熟的框架都有一定的接入門檻和運維成本，比較適合大型項目。

GEEK TALK

04

采編式AIGC 視頻生產流程編排實踐

由于 AIGC 視頻生產業務發展迅速，迭代速度非?？?，對成熟流程調度框架的調研中，遇到了系統利用率低、問題追查成本高的問題，為了快速支持業務、保障系統的穩定性與可用性，我們謹慎地選擇了基于狀態的流程調度方案，并在此基礎上參考流程編排框架的思想，建設一套底層中央編排器，驅動上層微服務的執行。整體思想可以概括為：

從上而下地，基于功能對整個流程進行模塊拆分、基于實現對模塊進行組件拆分，對模塊進行狀態管理、對組件進行位值管理

利用消息隊列實現流程串聯，通過對狀態與位值的判斷實現流程調度

通過對模塊與組件的組合配置實現流程組織

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

首先基于對需求的理解，對整個編排流程進行了模塊拆分，并對每一個模塊進行相關的狀態賦值，拆分的模塊有：

圖文接入模塊：接入上層業務或者外部業務的文本內容輸入，進行基礎的數據解析、校驗、打平與過濾功能；

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

視頻合成模塊：實現從視頻腳本到視頻文件的生成，該模塊執行完成之后就已經產生了可播放的視頻文件，標志著視頻生成完成；

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

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

方便數據輸出：在腳本編排模塊完成之后進行視頻腳本的輸出并提供給多個業務方使用，無論模塊內部如何擴展，腳本輸出的時機是固定的，視頻文件的輸出同理；

方便功能擴展：隨著業務的發展，功能實現的方案升級甚至替換是不可避免的，模塊內部提供原子化功能組件，可以方便地進行單功能的升級迭代或者添加，而不影響整體其他組件

為了方便微服務的調用狀態管理，我們又為每個微服務賦予了位值，所謂位值是當前組件在一個64位整數所處的二進制位次，每個組件占據兩位，枚舉標記成功和失敗狀態，我們只需要校驗對應位次的值，即可判斷當前組件的調用狀態與返回狀態。

△圖4 模塊與組件拆分

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

△圖5槽位值原理示意圖

如圖5所示，『調用位』、『返回位』都是一個 UINT64整數，每兩位組合可以有4個狀態，我們取前三個狀態進行調用或返回狀態的表示。每一個組件在注冊進入系統時，都會先分配一個位次（如圖3所示，1即表示占據槽位值的低兩位），如此一來，某個組件狀態發生變更時通過二進制操作修改對應二進制位的值即可。

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

4.2流程配置

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

△圖6 采編式 AIGC 視頻生產流程

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

{ …… { // 腳本編排模塊 "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，同時確?！旱偷诹弧粸?，具體在進行位置計算時實現 "slot_num_fail":32, // 2^(2*slot_index+1) 失敗時，要將『低第六位』置為1，同時確?！旱偷谖逦弧粸? "depends":["TextUnderstanding","WidgetInit"] // 文本處理組件執行，依賴文本理解與插件選擇組件執行完成 }， …… { "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":[""] // 在當前模塊內，沒有前置依賴 } ] } …… }

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

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

每個組件只關注自身執行所需關鍵信息，不關注其他組件的執行邏輯

在同一個模塊內的組件，組合成為模塊單元，模塊單元關注當前模塊狀態，以及當前模塊執行完畢之后的下一個狀態

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

后續的整體流程調度，將以該文件為藍本執行。同時，可以看到，一個描述文件即規定了一個流程，如果我們有不同的業務場景需要不同的執行流程，那么只需要再編排一個流程調度文件即可，事實上，我們的AIGC 業務也確實存在多條流程，整體編排邏輯同理，不多贅述。

4.3流程調度

服務編排框架的核心，是流程調度部分，該部分負責維持與推動數據流的運轉。如上文所述，每個組件的狀態都通過相對應的位值來維護，流程調度的關鍵就在于對位值的管理。整體流程如圖4所示，整個流程調度通過消息隊列串聯，主要操作步驟如下：

①任務創建：該步驟在一個任務執行全流程中只執行一次，主要在前置的參數檢查校驗工作完成之后，進行數據的入庫操作，并將任務下發流程調度消息隊列，觸發整體流程。

②查找可執行組件并執行：該步驟在一個任務執行全流程中會執行多次，在正常情況下，與組件個數等同。該步驟主要負責從消息隊列中拉取數據，遍歷流程描述文件，通過計算當前任務的調用/返回槽位值，推算出各個組件執行狀態，若某個組件未執行、且其依賴的前置組件已執行完畢，則將該組件加入執行隊列；若未找到可執行組件，則本次不執行。在這一步中，若組件內部存在異步微服務，則僅作微服務觸發，若為同步組件，則會在執行完畢之后，將任務再次加入流程調度消息隊列。

③異步回調：我們大部分組件都是異步微服務，故而在第二步中觸發微服務調用之后，這一環節主要功能是接收微服務回調，并做相關后置業務處理，處理完成之后，再將任務再次加入流程調度消息隊列。

△圖7 任務調度流程圖

在這個流程里我們通過消息隊列的調度解耦了組件之間的相互依賴，僅通過槽位值查詢與校驗來實現流程的流轉與執行，這使得系統具備了組件的并發性，只要定義好每個組件執行的前置依賴，那么當一個組件執行完成之后所有依賴這個組件的后置組件都可以開始執行。那么，這時候會出現另外一個問題，我們如何保證并行執行完成之后的槽位值更新不彼此覆蓋？如果兩個組件同時執行完成，但每個組件只會計算并修改自身槽位值，如何保證后更新的槽位值不覆蓋前一個組件的槽位值？這個問題的解決我們是通過利用消息隊列的重試做后置更新結合更新鎖來完成的：在每個組件執行完成之后只會更新自身涉及的業務字段，而不更新狀態及槽位值，狀態管理的三個值是在步驟二中前置執行的，每次從消息隊列中拉取一個任務后會先進性狀態的檢查和槽位值的更新，更新前會先加唯一鎖，若加鎖失敗則可能其他組件正在做狀態更新，則退出執行，該任務依然在消息隊列里未消費，待下一次繼續執行。

GEEK TALK

05

總結

采編式 AIGC 視頻生產流程2022年5月上線以來，已經根據不同的業務場景，通過對基礎模塊和組件的組合配置建設起5條不同的生產流程，很好地支持萬級日產的業務發展。隨著業務的迭代深入，相關組件的功能及代碼量都在日益膨脹，我們成功地在當前框架下進行組件的拆分與擴展，在不觸動底層調度框架基礎上，安全高效地完成了組件的擴展。雖然當前框架對目前的業務支持良好，但是整個流程的優化和迭代還在繼續，對成熟服務編排引擎的調研也在繼續，希望后續在借鑒成熟框架的基礎上，能夠沉淀出更為穩定高效的視頻生產流程。

審核編輯 ：李倩