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

語言: CN / TW / HK

時間 2023-03-02 12:02:11 百度Geek説

主題: wechat ace temporal cadence next 人工智能 conductor

作者 | 百度人工智能創作團隊

導讀

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

全文6451字，預計閲讀時間17分鐘。

01 背景

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

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

02 採編式視頻生產

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

文本處理：由於整個視頻是用圖文做腳本來完成的，所以，視頻主體抽取（這個視頻講述的是什麼內容）、視頻調性確認（陽春白雪還是下里巴人）、視頻字幕/旁白生成等，都需要基於充分的內容理解，再進行精準的文章主體識別、文章風格識別、口播逐字稿改寫、字幕拆分等工作的進行；
素材處理：採編式視頻生產的核心，是要將碎片化的素材基於圖文腳本進行合理的編排，故而進行視頻和圖片素材的在線檢索、剪裁、清洗等必不可少；
語音處理：語音播報作為視頻的關鍵元素，在視頻生產中是必不可少的一環，需要基於圖文進行合理的語音合成與添加；
其他視頻元素添加：視頻標註、水印、動效、背景音樂、背景視頻、前置氛圍渲染等元素的添加，能夠更好地豐富視頻效果；
視頻合成：將採編好的腳本文件，利用視頻合成技術進行視頻渲染輸出。

△圖1 採編式視頻生產

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

03 服務編排常見方案

3.1『狀態機』流程調度

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

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

3.2 服務編排引擎

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

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

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

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，同時確保『低第六位』為0，具體在進行位置計算時實現
            "slot_num_fail":32,                          // 2^(2*slot_index+1) 失敗時，要將『低第六位』置為1，同時確保『低第五位』為0
            "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 任務調度流程圖

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

05 總結

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

——END——

參考資料：

[1]http://cadenceworkflow.io/docs/get-started/

[2]http://docs.temporal.io/temporal/

[3]http://conductor.netflix.com/architecture/overview.html

[4]http://netflixtechblog.com/netflix-conductor-a-microservices-orchestrator-2e8d4771bf40

推薦閲讀：

百度工程師漫談視頻理解

百度工程師帶你瞭解Module Federation

巧用Golang泛型，簡化代碼編寫

Go語言DDD實戰初級篇

Diffie-Hellman密鑰協商算法探究