智能成片性能優化探索與實踐
一. 前言
各類剪輯類工具中都有一鍵成片的能力,解決創作者在視頻創作中剪輯特效包裝難的問題,行業主流做法一般是對用戶上傳的視頻素材識別提取高光,加上后期的模板特效包裝,最后出片。以上處理均會對視頻進行裁剪處理以適應模板填充坑位的時長。
B站從2022年7月開始做智能成片功能,第一版僅支持「圖片轉視頻」功能,核心是對用戶選擇的圖片素材添加簡單的音樂包裝,轉化成視頻,基本流程如下:
圖片
2022年10月開始做第二版的智能成片,支持添加視頻元素,同時擴充了特效包裝的維度,除了業界通用的模板特效,還結合了智能配樂,以及對用戶音頻信息的識別自動轉化成字幕。新的智能成片業務流程:
圖片
以上第一版和第二版總體上完整了智能成片結構化的特效包裝,即模板,配樂,ASR字幕 基礎智能三要素。歷史原因,在業務滾動迭代快的情況下,智能成片僅完成了快速上線的要求,也就是0到1的建設。在成片的性能上沒有定義出核心可觀測的指標。比如內部用戶反饋的效果問題,成片耗時長等基礎體驗問題較多:
圖片
本文主要從效率和效果 兩個層面來探討B站智能成片上的性能優化與實踐。
二. 可觀測性數據建設
基于智能成片整體的業務流,梳理核心的三條鏈路以及三條主鏈路下的子鏈路。首先定義出智能成片關鍵性的兩個可用指標。
合成耗時:用戶選擇完素材之后,開始智能成片和完成智能成片的整體耗時。這里我們取P90的指標來做參考
合成效果的定義提取較為復雜,有三個維度的鏈路可以去優化:
●素材應用成功率:提升智能成片子鏈路(基礎的模板,配樂,ASR字幕)的素材應用成功率,每一個子鏈路應用成功,即代表最終還原的效果越豐富。
這一維度的定義偏理想化,但子鏈路素材應用成功率的指標業務上是可量化的。
●模板還原原子能力的豐富度:特效包裝集模板本身的原子能力補齊,模板具備更豐富的子元素。
這一維度為業務手段補基礎能力提模板效果,不做講解
●素材推薦的精準度:智能推薦的模板,音樂等包裝特效能和用戶選擇的素材內容相匹配,精準度高。
模板和音樂的推薦依賴于 AI模型的畫面標簽識別率,畫面標簽識別率主要是人工評測,識別率在41%(P0畫面標簽識別率 68%),這部分的優化依賴畫面識別模型本身的能力升級,本文不做詳解。
以上我們最終選取「素材應用成功率」作為合成效果的主要量化指標。本文主要圍繞這一維度的優化展開。
有了基礎的指標定義,我們從智能成片全局角度整理輸出需要補全的觀測數據:
圖片
三. 性能優化
初始數據顯示,智能成片的P90耗時為 20s (基本超時),素材應用成功率:46%。整體可用性較差。
在基礎數據量化的基礎上,我們從三條核心鏈路切入,摸排可優化的點定項優化。整體的摸排點如下:
圖片
3.1 模版鏈路優化
初始模板的下載成功率只有91%,模板從抽幀推薦到下載完成P90耗時 在19s
模板推薦從素材頁到智能成片合成頁整體業務鏈路如下:
圖片
我們從以下幾個關鍵點進行優化
3.1.1 資源重復下載問題
主要是兩類資源重復下載問題:
- 一類 智能成片業務流程中有單獨的音樂下載。模板本身也攜帶音樂子元素但業務流并不會采用(模板攜帶的音樂和素材本身不匹配)。這里我們采用的方案是模板下載業務層支持素材子元素按需下載(剔除了不需要的素材)。
- 二類 歷史原因嗶哩嗶哩粉版字幕和必剪字體字幕版本不一致,而UGC模板都是必剪生產。智能成片下載完模板資源之后,因字體字幕資源的不匹配而需要重新索引下載相匹配的字幕字體資源。解決方案類似,按需處理不下載模板攜帶的字體字幕,直接跳過下載單次智能成片需要的字體字幕。
圖片
以上是兩類典型的資源重復下載問題,通過縮減不必要資源從而節省下載耗時。最終P90耗時縮減 2s
3.1.2 特殊資源轉碼問題
我們對智能成片超時(業務配置20s即為超時)鏈路進行收集,分析80+ bad case,逐一查看超時原因。發現兩個超時較多的場景:
圖片
1) iOS 端字幕下載經常超時 120s,經過反復嘗試摸排,我們發現業務下載器存在bug,下載多字幕字體時下載鏈路會卡住,直至下載任務超時120s之后返回結果。
2) 模板素材中子元素包含GIF素材時,容易超時。分析發現業務使用的三方剪輯SDK存在私有素材格式的定義,GIF素材在模板消費端會被轉碼成三方剪輯SDK自定義的CAF格式素材,這個轉碼過程耗時較長,容易超時。
- 問題一:修復業務下載處理流程即可
- 問題二:有兩個方向,第一個方向是素材效果還原時支持直接渲染GIF(由于美攝自定義格式問題,未開放類似API),第二個方向是模板素材生產端生產素材時直接將GIF素材轉化成CAF格式,消費端可直接讀取CAF素材渲染從而縮減鏈路轉化的耗時。
圖片
基于第二個方向優化,又衍生出一系列鏈路需要處理:
- 對于存量的包含GIF素材的模板,需要清洗轉化成CAF格式。對于增量的模板,含GIF素材的生產端默認直轉CAF格式,需要對模板生產端進行改造。同時下發新的生產包給到內部或外部模板生產商。
- 內部有自研剪輯SDK蒙太奇,支持GIF素材渲染。在前置優化已轉成CAF格式的前提下。處理這類不同SDK對素材兼容問題,也有兩個方案:
- 美攝支持CAF素材格式反向轉化成GIF格式。在最終自研SDK替換上線時,對素材在進行一次清洗CAF轉GIF。通過與美攝技術對接,訴求API可以提供
- 自研剪輯SDK支持美攝私有CAF格式,需要對CAF格式素材進行逆向分析,然后解碼支持CAF格式渲染。通過與內部自研SDK技術團隊溝通,該方案也能走通。
以上兩個方案在考慮業務迭代和上游模板生產維護成本的角度,優選是「自研剪輯SDK支持CAF格式」。從素材格式標準化的角度,優選「美攝支持CAF素材反向轉成GIF格式」。最終我們選擇「自研剪輯SDK支持CAF格式」低成本的解決這個問題。
素材格式轉換處理和多字幕問題修復之后,P90耗時大幅下降至12s。
圖片
3.1.3 模板資源大小生產標準化 & 版本兼容
智能成片的模版素材一般是由內部設計師生產。早期素材中臺素材入庫時沒有對素材體積做標準化壓縮處理,模版生產時也未對模版做大小限制,部分生產的模版體積超大,下載耗時長。這里我們從兩個方向進行優化:
圖片
- 定義模板體積基線標準(20M)。模板生產提交時,實時計算模板總體積,超出標準體積的,展示模版元素體積信息,針對大體積子元素做替換處理
圖片
- 推動素材中臺對素材做標準化壓縮處理,增量素材接入轉碼服務,存量素材做清洗。同時根據不同業務場景下發不同質量素材。
圖片
模版版本兼容
圖片
模板是一個特效包裝集,它是由多個基礎原子能力組成,比如字幕,字體,轉場特效,濾鏡,畫中畫..., 在加上標準還原協議。模板的原子能力隨著版本迭代逐步增加。如何設計版本兼容方案?
簡單的做法是針對不同模版支持的原子能力做版本控制。這里的問題在于:
- 模板運營同學需要知道該模板支持的原子能力與支持的App版本,理解難度高。
- 在素材中臺純手工配置模板支持的版本號,效率低。
更合理的做法,App端維護一份支持還原的原子能力信息,云端根據App端支持的模板原子能力和模板本身支持的原子能力,篩選出相匹配的模版列表,在下發到App端。以上解決了模板分發的問題。但仍有部分情況需要做版本兼容處理:
- 比如某個原子能力升級之后對應素材沒辦法向下兼容,需要做版本隔離,新版本對應新素材,舊版本對應舊素材。
- 比如做了某個性能優化,生產端素材格式發生了變化(如前所述GIF轉CAF優化),需要對新素材做版本隔離。
版本隔離的問題在于,純手工配置容易出錯,在歷史版本迭代中,也有少許因版本上線間隔時間長,模板生產端人員變動長下文信息不全導致的版本隔離信息配置出錯,最終導致模版子元素拉取失敗,進而影響模板下載成功率。
以上問題我們通過模板下載報錯信息,索引到對應模板子元素,逐一校準模板版本信息,該問題解決之后,模版下載成功率提升至96%
圖片
3.1.4 模板資源增加預加載&兜底處理
業界基操,采用預加載和增加兜底來提升素材下載應用的成功率。我們從三個方面做了預加載的邏輯
- 對下載推薦模板失敗 或者 下載超時的模板 增加預下載兜底模板,保證基礎的包裝特效
- 對高熱的智能成片轉化率高的模板增加預下載,提高高熱模板的緩存命中率,縮減耗時
- 縮減模板服務鏈路,模板核心zip資源及其索引子元素支持并發下載
圖片
同時也做了模板下載器本身的優化,歷史模板業務下載器僅支持串行下載。業務上接入基架新的下載組件,解決無法并發下載的問題。
3.2 ASR鏈路優化
智能成片的第二條智能鏈路,核心依賴ASR服務,ASR服務主要是對音頻數據分析,輸出音頻分類信息:有音樂,混音,有人聲,沒有聲音四個類別。每個類別的標識看各類信息的占比:
圖片
其業務鏈路如下:
ASR鏈路中可以優化的點
問題1:ASR服務耗時較長,單線統計ASR鏈路耗時,發現P90基本超20s,處于不可用狀態。
問題2:ASR鏈路前置流程包含音頻文件提取和音頻上傳鏈路。音頻上傳鏈路中會出現耗時較長的場景。主要點是歷史原因:音頻文件上傳鏈路中間有一個業務服務和文件存儲服務做轉發,耗時有損。
圖片
問題1:協同AI服務端查找極端case排查,最終是發現ASR服務接口被刷的情況,服務QPS過高,導致業務ASR處理排隊等待耗時長。處理方案是將刷量的task任務加入黑名單。處理完之后,ASR鏈路P90耗時縮減50%
圖片
圖片
問題2:去除上傳業務服務中間層即可,客戶端直接調用基礎文件存儲BFS服務接口再返回存儲地址給到AI服務側,縮減鏈路。
圖片
3.3 智能音樂鏈路
智能成片的第三條鏈路,音樂推薦。其基本流程如下。
圖片
AI側處理響應音樂推薦主要有三個維度的指標:用戶特征,音樂特征,畫面特征:
- 用戶特征依賴基礎的人群分層。
- 音樂特征是用戶往期匹配的音樂特征記錄,每天更新一次。
- 畫面特征即用戶本次智能成片識別素材的畫面標簽。
基于以上三個特征按權重推薦音樂,且畫面特征維度更匹配當次智能成片的效果。
在某次上傳組件升級替換過程中,業務側傳遞了錯誤的抽幀地址給到AI服務側導致無法輸出畫面標簽。AI側基于用戶特征和音樂特征返回了策略降級的音樂推薦(音樂和畫面匹配度低,同質化問題),業務側無感知。
問題的發現主要是AI團隊有基于畫面打標成功率監控告警,一段時間內,打標成功率大幅低于預期值。
圖片
問題的修復:
- 客戶端回滾線上編輯器幀上傳功能配置至老組件,線上用戶止損。
- 客戶端新版本修復幀地址給錯問題。基于新的業務配置灰度放量
問題的預警:業務測試和研發人員在交付驗收階段如何判斷返回的推薦音樂是否降級。以及上線之后業務側能否更快感知。
AI服務端返回無畫面特征的錯誤信息,端上基于此錯誤做兩個處理:
- 客戶端log日志打印音樂推薦錯誤信息(含新的是否包含畫面特征的錯誤),驗收階段方便篩查。
- 客戶端增加實時埋點上報,統計有畫面特征音樂推薦成功率,根據實際情況確定推薦成功率閾值,做實時告警監控。
通過以上系列優化,智能成片P90耗時在 10s左右,素材合成成功率 90%+
圖片
四. 指標防裂化
前面主要講解了智能成片性能優化過程,這一部分主要是對已達成的指標做客戶端監控告警,防止數據劣化。我們主要從以下幾個緯度來建立監控告警整體流程
圖片
- 定指標:這部分主要定義智能成片三條核心鏈路子鏈路的關鍵節點指標來做告警。
圖片
- 設閾值:對每個選定的指標項設置合理的閾值,統計時間范圍,觸發條件 etc
圖片
- 配置告警:在Fawkes平臺配置每個關鍵節點指標的告警信息
- 備注:Fawkes是一款企業移動Sass平臺產品,提供了全面的移動應用程序開發和部署解決方案,可以大大提高開發效率和應用程序質量,降低開發成本和風險。
圖片
- 告警響應處理:告警觸發之后,值班人員對告警進行響應處理。我們定義了基礎5-10-20原則,即5分鐘發現,10分鐘響應,20分鐘定位問題。
這里有兩個問題,告警觸發后如何快速通知值班人員?以及如何讓值班人員快速查找error信息
圖片
我們通過Fawkes告警平臺,配置自定義的Webhook信息。告警觸發后,通過解析標準Webhook配置,篩選告警關鍵日志信息,在通過自定義Webhook封裝關鍵日志信息和當日的值班人員信息推送到告警處理群。
圖片
- 告警復盤:每條告警信息都有當日值班人員記錄,我們會定期對告警值班信息進行復盤,不斷校準告警顆粒度和閾值信息。
以上通過實時告警監控SOP建設,對智能成片三條主鏈路數據做日常巡檢。定期收集,分析,調整告警信息,告警更加精準,提升日常值班效率。
五.總結和展望
5.1 總結
我們首先定義出智能成片核心可用性指標,基于核心指標細化關鍵鏈路節點可觀測數據。同時基于數據圍繞模板,ASR字幕,配樂三條鏈路做耗時和成功率的調優。最后我們對智能成片核心鏈路建立實時監控告警值班機制,防止數據劣化。未來數據,調優,告警三部分還會持續演進。
數據部分:更加精細化,數據口徑校準
調優部分:智能模板生產端素材大小監控,模板素材入庫標準化,畫面識別準召率提升
監控告警部分:策略類告警補齊(智能配樂策略),智能成片耗時告警補齊,告警顆粒度細化,雙端告警差異項對齊。
5.2 未來方向
智能成片1.0 主要是 模板,ASR字幕,配樂基礎三要素特效包裝,并沒有對用戶素材本身做處理(Before)。
智能成片2.0 是對標行業競品,基于畫面識別的能力做智能提取高光,智能剪輯(ing...)。
智能成片3.0 基于AIGV大模型,通過AI生成視頻內容,一鍵成稿(Future)。
本期作者
徐惠雨嗶哩嗶哩資深開發工程師