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