一. 背景與目標

1.1 視頻審核背景

現(xiàn)有視頻審核系統(tǒng)由于歷史原因，針對不同的業(yè)務調(diào)用方和業(yè)務場景提供了多套視頻審核技術方案和服務，且在審核時效、支持的協(xié)議完整性等方面存在一定的不足；同時，多套系統(tǒng)并存一直存在較高的運維成本的情況。

由此，需要設計一套統(tǒng)一的視頻審核系統(tǒng)架構，將多套服務合并為一套服務，提供統(tǒng)一標準視頻審核服務，大幅降低運維成本的同時，提供完整的接口協(xié)議支持和更高的審核時效。

?

1.2 設計目標

?審核時效優(yōu)化：

?流式完成下載、拆幀、推理、通知四階段處理；使得整個審核過程為：邊下邊拆邊推邊響應。

?每階段內(nèi)并行處理，提高審核時效。

最終目標：審核時長 = MAX(并行下載、并行拆幀、并行推理)。

?

?完整的接口協(xié)議，應對未來不同需求場景：

?短視頻同步：提供時長1~2分內(nèi)、100MB內(nèi)的視頻，達成3秒內(nèi)審核完成的目標；且以同步阻塞接口提供服務，簡化業(yè)務方調(diào)用、交互過程。

?長視頻異步：支持10小時甚至更長視頻的異步審核能力，按調(diào)用方需求提供實時響應開關。

?實時直播視頻流：針對實時直播流，提供邊拉流、邊審核、邊響應的實時流式響應能力。

?

二. 拆幀技術方案選型

2.1 ffmpeg簡要介紹

針對不同的編碼器、封裝協(xié)議、傳輸協(xié)議，提供統(tǒng)一的音視頻處理接口。

跨平臺，兼容200多種編碼、180多種封裝格式、20多種傳輸協(xié)議。世界上90%以上的音視頻開發(fā)基于FFmpeg。

?

2.2 API vs 命令行

?基于API

FFmpeg提供了一整套的音視頻處理庫，以統(tǒng)一的API分別完成音視頻處理過程中的主要階段，包括：

采集、解封裝、解碼、處理&轉(zhuǎn)換、編碼、封裝、傳輸?shù)取?/p>

其中，各個庫提供的API粒度較細，非常適合對音頻、圖片幀做業(yè)務細粒度的自定義加工的場景。

?

?基于命令行

基于上述庫，F(xiàn)Fmpeg提供了可執(zhí)行命令行工具：FFmpeg。

FFmpeg命令行以組合大量選項、參數(shù)的方式完成常規(guī)的音視頻處理工作，且其本身以c語音實現(xiàn)，為常規(guī)音視頻處理需求，提供了簡單、穩(wěn)定、高效的支撐；通過高級命令行參數(shù)可達成設計目標 ：

流式下載：支持Http/flv流等傳輸協(xié)議作為輸入，實現(xiàn)邊下載邊解碼。

分段并行：利用ss、to等選項，其內(nèi)部基于http range seek特性，完成并行多段處理。

自定義音視頻參數(shù)：利用codec/afilter/vfilter等編解碼、濾鏡參數(shù)可完成輸出圖片自定義幀率、音頻采樣、聲道等目標。

?

綜合考慮視頻審核業(yè)務特點，對音視頻處理過程本身并不復雜，單純、核心的目標就是將音頻、圖片幀從視頻中拆分出來，并不存在過多的針對音視頻幀的加工處理過程，因此，視頻審核架構采用FFmpeg命令行工具完成基礎的視頻拆幀工作。

?

三．框架描述

3.1 流式處理框架

任務處理器是視頻審核服務的核心組件，一個任務處理器實例包括三個子組件：拆幀引擎、任務驅(qū)動器、審核業(yè)務對象。通過任務驅(qū)動器的調(diào)度過程，協(xié)調(diào)拆幀引擎和審核業(yè)務對象兩個對象實例完成一個視頻任務的下載、拆幀、推理、響應四階段流式、并行處理過程。

一個視頻審核服務內(nèi)根據(jù)容器cpu資源、配置情況，允許多個處理器實例并行完成多個視頻處理任務。

?

3.1.1 拆幀引擎

拆幀引擎：圖片拆幀邏輯圖、音頻拆幀邏輯圖，目標均是流式生產(chǎn)數(shù)據(jù)。

?

圖片拆幀

單一視頻任務中，為了完成流式、并行處理目標，圖片拆幀模塊由兩個主任務并行完成：

一是根據(jù)視頻時間、業(yè)務策略，啟動多個ffmpeg進程，利用ffmepg的seek機制將視頻拆分為多段完成并行下載、拆幀。

二是收集任務，根據(jù)拆分出的圖片幀時間戳信息生成圖片幀信息，供后續(xù)推理讀取。

?

音頻拆幀

針對音頻拆幀存在兩種目標：

針對視頻文件：采用單一命令完成整個音頻文件的拆分，供后續(xù)asr、音頻審核使用。

針對視頻流：相對于視頻文件，視頻流具有連續(xù)性，時間比為1：1，為了達成邊拆邊推理邊響應目標，需要在直播過程中動態(tài)切分音頻段，完成實時處理和實時響應。

視頻流中的音頻處理部分涉及幾個主要步驟：

拆段：利用segments機制，完成固定時間段的音頻切分。

VAD：基于webrtc VAD模塊，遍歷PCM文件采樣數(shù)據(jù)，完成有聲段音頻的拼接&切割。

編碼：將原始PCM音頻編碼為mp3，大幅降低文件尺寸便于傳輸。

收集：負責收集編碼后的mp3文件，生產(chǎn)音頻段信息，用于后續(xù)推理讀取。

?

3.1.2 審核業(yè)務模塊

審核業(yè)務對象與任務處理器、調(diào)用算法服務進行交互，完成流式、并行的幀（圖片、音頻）審核業(yè)務過程。

審核業(yè)務對象內(nèi)部由單線程驅(qū)動，循環(huán)檢測幀隊列、異步推理響應、異步上傳響應三個狀態(tài)，并根據(jù)推理、上傳結果，在業(yè)務策略開啟實時響應開關時，動態(tài)發(fā)送部分響應數(shù)據(jù)至實時結果隊列完成實時響應。

?

3.1.3 任務調(diào)度器

拆幀引擎和業(yè)務對象對外部提供了標準的非阻塞狀態(tài)查詢及命令處理接口，圍繞這些接口，任務調(diào)度器內(nèi)部由單線程驅(qū)動，與拆幀引擎和業(yè)務對象進行流式調(diào)用交互，這個過程中，拆幀引擎作為幀生產(chǎn)者、業(yè)務對象作為幀消費者，任務驅(qū)動器將兩者進行銜接，從任務處理的角度驅(qū)動兩者共同完成視頻審核過程。

?

?

至此，三者整體完成了核心目標：

下載、拆幀、推理三階段，每階段內(nèi)并行加速。

下載、拆幀、推理、實時通知四階段流式處理。

?

3.1.4 多業(yè)務場景

得益于核心組件間的標準接口交互，整個系統(tǒng)可以針對不同的業(yè)務場景、需求，將業(yè)務對象從主服務中剝離出去，由內(nèi)部函數(shù)調(diào)用改為遠程RPC調(diào)用，并進行分布式部署；使得所有業(yè)務在統(tǒng)一的流式、并行框架下，高效完成各種場景需求。

?

3.1.5 同步&異步處理流程

視頻拆幀過程屬cpu密集型業(yè)務，其任務處理的服務節(jié)點優(yōu)先從cpu負載角度出發(fā)，而不是接收請求的節(jié)點進行處理；因此，在接收請求后，會將其派發(fā)到MQ任務隊列中，由cpu閑置的節(jié)點通過手動pull方法完成任務獲取并處理。

同步與異步不同的點在于，異步任務處理完成后，直接將響應發(fā)送到結果隊列中，由調(diào)用發(fā)接收；而同步模式下，需要將結果通過回調(diào)的方式，將響應返回到請求接收節(jié)點，再由請求接收節(jié)點進行同步響應給調(diào)用方，內(nèi)部通過同步對象、超時等機制完成同步調(diào)用協(xié)議。

?

3.2 結果服務

結果服務與主服務配套，從MQ接收主服務處理過程中發(fā)送的各種事件并保存，主要完成幾個功能：

?請求處理審計：保留一個月的細節(jié)結果，供后臺查詢、分析視頻拆幀、審核過程的有效性、及時、快速、方便的審計問題。

?提供主動查詢接口：調(diào)用發(fā)發(fā)起異步請求后，對比mq接收結果，另一種常見的方式是通過主動調(diào)用查詢接口進行定時檢查的方式獲取響應，結果服務提供get接口供調(diào)用方主動進行結果查詢。

?全局重試：主服務所在宿主機、容器宕機時，結果服務內(nèi)部實現(xiàn)了定時檢查機制，當發(fā)現(xiàn)視頻任務開始處理后，且在一定時間內(nèi)未響應的情況下，會調(diào)用主服務完成任務的重試處理過程，確保視頻任務不丟失。

?

四. 策略配置

系統(tǒng)針對單一視頻的整個處理過程中，涉及不同的策略可以進行配置&設置，包括兩個方面：

一是框架處理過程，二是審核業(yè)務策略，根據(jù)不同業(yè)務需求，可以進行完成的處理過程配置；

業(yè)務方通過輸入業(yè)務token+策略ID進行服務調(diào)用，以完成業(yè)務方特定需求，具體可配置策略包含如下：

?

?不同模式部署

16c機器情況下，針對不同協(xié)議場景，完成集群配置：

?

五. 測試驗證

經(jīng)測試驗證，在16C容器下達成設計目標：

?1分鐘、100MB內(nèi)視頻，2秒內(nèi)可完成審核。

?長視頻異步模式下，對比舊版服務審核時效平均提升5倍。

?優(yōu)雅退出+全局重試保障任務不丟失。

?標準模塊接口為未來擴展為多場景通用分布式系統(tǒng)打下基礎。

?審核編輯 黃宇