一. 背景與目標

1.1 視頻審核背景

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

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

?

1.2 設計目標

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

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

?每階段內并行處理，提高審核時效。

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

?

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

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

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

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

?

二. 拆幀技術方案選型

2.1 ffmpeg簡要介紹

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

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

?

2.2 API vs 命令行

?基于API

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

采集、解封裝、解碼、處理&轉換、編碼、封裝、傳輸?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等選項，其內部基于http range seek特性，完成并行多段處理。

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

?

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

?

三．框架描述

3.1 流式處理框架

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

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

?

3.1.1 拆幀引擎

拆幀引擎：圖片拆幀邏輯圖、音頻拆幀邏輯圖，目標均是流式生產數(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文件，生產音頻段信息，用于后續(xù)推理讀取。

?

3.1.2 審核業(yè)務模塊

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

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

?

3.1.3 任務調度器

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

?

?

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

下載、拆幀、推理三階段，每階段內并行加速。

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

?

3.1.4 多業(yè)務場景

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

?

3.1.5 同步&異步處理流程

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

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

?

3.2 結果服務

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

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

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

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

?

四. 策略配置

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

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

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

?

?不同模式部署

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

?

五. 測試驗證

經測試驗證，在16C容器下達成設計目標：

?1分鐘、100MB內視頻，2秒內可完成審核。

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

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

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

?審核編輯 黃宇