下載客戶端

登錄

AI時代的視頻云轉(zhuǎn)碼移動端化——更快、更好，更低，更廣

2022-09-06 15:19

來源：澎湃新聞·澎湃號·湃客

編者按： AI技術(shù)的落地是漸漸地從服務(wù)器端、云端落地，逐步到移動端及邊緣設(shè)備上。這些年隨著AI技術(shù)的進步，輕量級算法模型開始在移動端實時跑起來，并且移動端算法也在不斷進行迭代和完善，而對于實時直播場景，也有越來越多的AI算法落地。ZEGO即構(gòu)科技提出了一套極輕量級AI算法模型，結(jié)合移動端硬件特性，差異化優(yōu)化前饋推理庫，讓算法模型、推理庫、硬件成為一體，使得視頻云轉(zhuǎn)碼移動端化成為可能。LiveVideoStackCon 2022音視頻技術(shù)大會上海站邀請到了即構(gòu)科技的李凱老師，為我們分享產(chǎn)品架構(gòu)、移動端視頻轉(zhuǎn)碼、移動端智能視頻處理、四位一體網(wǎng)絡(luò)模型設(shè)計以及具體實施Demo。

文/李凱

整理/LiveVideoStack

這是我第二次在LiveVideoStackCon分享，第一次時本人肚子還沒有這么大，疫情三年肚子長大了，但我們的模型會變得越來越小、越來越快、效果越來越好，這就是“更快、更好、更低、更廣”。

快 —— 速度越來越快，好 —— 效果越來越好，低 —— 耗費很低的碼率，廣 —— 盡可能覆蓋更多的機型。曾經(jīng)在云端轉(zhuǎn)碼遇到大批量的任務(wù)，本次探討在移動端如何處理，分享內(nèi)容更側(cè)重在移動端如何把任務(wù)快速跑起來，把服務(wù)器端的事情放在手機端做，對 ToB 廠商的用戶來說是非常開心的。

本次分享按以下方向逐一展開：一是 ZEGO 產(chǎn)品概貌；二是要在移動端去做的理由，這是幫助解決客戶提出的需求問題；三是在移動端可以做到哪種程度，能不能面對用戶提出的苛刻需求，解決客戶問題；四是如何解決行業(yè)內(nèi)難題，這是任何一個做音視頻廠商、做視頻前后處理都孜孜不倦追求的問題；五是簡單實驗結(jié)果分享。

1、產(chǎn)品架構(gòu)

產(chǎn)品應(yīng)用方面，會議端的小藝幫主要針對考試類的應(yīng)用；直播類有游戲直播，KTV唱歌等；方案有社交娛樂、泛娛樂、以及這幾年很火的在線教育。目前也會給小藝幫考試類的做應(yīng)用，不限于在線教育的方案。我們同時會提供基礎(chǔ)技術(shù)服務(wù)，比如視頻轉(zhuǎn)碼、畫質(zhì)增強、美顏特效、Avatar 元宇宙底層技術(shù)、背景分割等。

1.1視頻處理

本次分享的重點是視頻處理。上圖是我們很直觀的數(shù)據(jù)。

在 iPhoneXR 這樣的中端機型上，超分辨率 640*480 兩倍率做 AI 超分到 1280*960，21ms 可以搞定。同時也測試了安卓機型，大概可以覆蓋 2500 款，1000 元以上機型基本能夠覆蓋。如果機型好一點，超分到 1080p 沒有問題，但國家政策鼓勵出海去東南亞、印度、非洲。這些國家市場非常大，但最大的現(xiàn)狀為使用者大多為千元機以下，這就面臨一個很大的難題，千元機難做超分。

去編碼速度比超分速度快很多，超分天然的數(shù)據(jù)量很大，不能把圖片縮小，將圖片原始分辨率不做改動的情況下放大。去編碼效應(yīng)的優(yōu)勢在原始分辨率上做，處理速度比超分快很多，基本可覆蓋千元機。而在印度、東南亞、非洲這些帶寬很低的地方，這時做去編碼效應(yīng)比超分，更具實際價值。

最難的點是視頻插幀，兩幀插一幀，基礎(chǔ)數(shù)據(jù)是在 IPhoneXR 上 960*540，32ms，這一部分依然面臨難覆蓋千元機，也是我們一直去追求的點，后續(xù)可以演示插幀在移動端上手機具體效果。

隨后也會與大家分享如何實現(xiàn)低照度增強，大家也可以跟著這個思路復(fù)現(xiàn)低照度增強，速度可以覆蓋到 2ms，很低端的機型例如 2015 年的機型小米2S，2ms 可以實現(xiàn)。道理很簡單，就是 3D或 2D 查找表，非?？?，效果在最后一部分演示。但低照度會有個問題，這也是業(yè)界難題，在極度暗的情況下出現(xiàn)噪點放大。那我們?yōu)槭裁醋叩驼斩仍鰪姡?/p>

給大家講個小故事，我們有一個東南亞客戶之前提出需求，“需要 1280*720 的分辨率，要求 30 幀率不能下降、燈全關(guān)掉、手機屏幕亮度調(diào)到最低，但對方可以清晰看到我的臉”。在與客戶溝通時，問能不能把屏幕亮度調(diào)亮一點點，對方不樂意，他就需要這個效果，但我們努力幫助其解決問題他還是很開心的，雖然不能否認(rèn)會給他帶來噪點問題，但亮度調(diào)高一點點，噪點問題將被適度放大。如果使用長曝光 1280*720，幀率很低，長曝光只能 10 幀，用戶做很多動作想要 30 幀，也會不開心。

1.2其他AI技術(shù)產(chǎn)品

技術(shù)人員要經(jīng)常與銷售打交道，面對一線用戶，技術(shù)人員就能了解是否要解決此問題，知道需求在哪兒，做的技術(shù)有無價值。當(dāng)然我們也會做其他的應(yīng)用。一是摳圖，其中有隱私反向打碼，例如小米攝像頭監(jiān)控功能，老人在家監(jiān)控但不放心，就可以把老人反向打碼，將老人虛化而背景不虛化，或只虛化老人身體的一部分，反向摳圖，關(guān)鍵看你怎么去做去用。二是小目標(biāo)檢測，曾經(jīng)有用戶給一個條件：小分辨率在 640*360，只有 10 像素的手機，考場監(jiān)控場景下，看拿手機作弊的小動作能否被檢測出。這樣的難題是實際中碰到過的很多基礎(chǔ)應(yīng)用。

2、移動端視頻轉(zhuǎn)碼

第二部分是移動端視頻轉(zhuǎn)碼。

2.1 移動端轉(zhuǎn)碼

關(guān)于移動端視頻轉(zhuǎn)碼，也有一個來自于真實用戶提出的需求：為什么要將視頻上傳至云服務(wù)，云服務(wù)下載后又要轉(zhuǎn)一遍，用戶自己拍的視頻或是轉(zhuǎn)的視頻不愿意上傳至服務(wù)器，那么移動端是否能將視頻修復(fù)呢？

視頻修復(fù)需要做很多任務(wù)，首先要從云轉(zhuǎn)碼角度分析是什么場景下的視頻，游戲、體育或是日常生活，質(zhì)量如何、塊的效應(yīng)如何、編碼狀態(tài)如何。一個視頻塊很多，但也許是錄屏的，初步分析后考慮是否要做超分、做編碼塊效應(yīng)、做降噪，那這一整套能不能在手機端做到？用戶提出此問題后，如果可以解決用戶就愿意付費，但用戶不想放在云端，ToB 公司不樂意放在云端為單個服務(wù)器付費，在用戶的手機將事情落地對于 ToB 公司來說是樂意付費的。所以我們很多的技術(shù)實現(xiàn)都是源自于具體生活。到底能不能實現(xiàn)，實現(xiàn)到什么程度，后面會分享具體一些數(shù)據(jù)，看能否支撐能否做到。

2.2 移動端 AI 技術(shù)性能一覽

在上圖的超分性能數(shù)據(jù)中可以看到，我們可以覆蓋 2500 款機型，業(yè)界能敢喊出這個數(shù)字的不多，這是公開的，能給到廠商實測。最難的是移動端實時視頻插幀，需要解決人物不扭曲、大運動不虛、字幕不花等場景，并且機型覆蓋程度仍在努力中，不會停下腳步。剛才提到的低照度增強，提升通道通透性指的是視頻進入編碼之后，會有朦朦一層，沒有深度參差，將其處理，使之縱深變強，立體感更強，而不是像有一層霧，當(dāng)然也可以用去霧通道處理此問題。在降噪方面，我們本身也在做各種優(yōu)化。摳圖和小目標(biāo)檢測在前文中也有提到，我們主要做安卓端，IOS 端有 MPU 和 ANE 會好做很多。

3、移動端智能視頻處理

第三部分是移動端智能視頻處理。

3.1 全鏈路自研可控

上圖中是我們公司大型團隊端到端做的事情。我所負(fù)責(zé)的是與視頻相關(guān)的業(yè)務(wù)，包括視頻前后處理部分、麥克風(fēng)采集、涉及端到端的網(wǎng)絡(luò)，以及部分編解碼。我相信這個流程每個做 RTC 的技術(shù)人員都能畫得出，搞技術(shù)的即使是做視頻前處理也要會畫，這是整個公司每個同事負(fù)責(zé)盯在哪一塊的概貌。

3.2 移動端視頻處理

上圖是本人整個職業(yè)生涯所要做的事情，當(dāng)然也不僅僅只有這些?，F(xiàn)在也做關(guān)于教育的東西，技術(shù)是相通的，整個數(shù)據(jù)流是這樣走的，核心重點還是在視頻后處理或視頻前處理上，包括前端推理庫的優(yōu)化，后續(xù)會講到前端推理庫的一部分優(yōu)化和網(wǎng)絡(luò)模型如何設(shè)計得更加小型化。

3.3 移動端超分辨率

再看一下移動端超分辨率具體技術(shù)細(xì)節(jié)。

超分辨率-性能PK

超分是我們?nèi)ツ晟习肽曜龅氖虑椋c行業(yè)內(nèi)進行 PK，在上圖數(shù)據(jù)上做測試，越向左模型越小越好，越往上效果越好，左下角都是一些小模型的效果。上圖中PAN 在2020年模型參數(shù)量最小，效果排第二。RFDN 在 2020 年效果第一，與之作初步對比，大模型的位置如圖，但實際覆蓋大概 2500 款機型使用不同的模型。

超分辨率網(wǎng)絡(luò)模型-設(shè)計

上圖是超分很簡單的網(wǎng)絡(luò)模型設(shè)計，期初花了很多心思精力閱讀大量文章加上自己的奇思妙想、胡思亂想，我們做了一些通道處的處理，包括通道注意力機制，但最終發(fā)現(xiàn)流程越多，模型加速可能性越低。后來回到初衷，原始設(shè)計出來的模型，最后還是這樣的，這樣做加速會非常容易。如果模型效果好但沒法加速也不行，結(jié)構(gòu)比較復(fù)雜。這一部分我們也發(fā)了一篇文章，影響因子5.9（https://doi.org/10.1016/j.neucom.2022.07.050）。模型怎么訓(xùn)練，其中就有一些彎彎繞繞，涉及到后續(xù)會統(tǒng)一提到的技術(shù)點。

3.4 移動端低照度

低照度設(shè)計

低照度方面，第一版是用 2D 查找表方式，發(fā)現(xiàn)其維度不夠，后改用 3D 查找表，用網(wǎng)絡(luò)模型訓(xùn)練得到查找表本身，而不是模型，后續(xù)將推理庫丟掉，只要進來數(shù)據(jù)，有三個維度分別是圖像輸入的原始像素點、當(dāng)前像素點周圍鄰域的均值、根據(jù)自己定義例如當(dāng)前像素點Y通道的亮度與周邊像素點亮度差異值，在 0-1 之間。將其變成 0-255，此表最大為 255*255*255，最終結(jié)果是幾毫秒。

網(wǎng)絡(luò)模型-設(shè)計指導(dǎo)方向

回到視頻超分辨率的問題，如何將視頻超分辨率模型變小，可以做知識蒸餾；重參數(shù)，這在最近幾年很火，我們用在很多領(lǐng)域，還會放在目標(biāo)檢測中，美團的 YOLOv6 就用了重參數(shù)、臺灣的YOLOv7 同樣使用重參數(shù)，重參數(shù)同樣變成了在 CV 基礎(chǔ)業(yè)務(wù)領(lǐng)域的骨干網(wǎng)絡(luò)，重參數(shù)的意思是訓(xùn)練中模型非常大，推理模型非常小，但訓(xùn)練模型和推理模型是等價的，最終效果一樣，推理速度更快，依據(jù)這個可以看更多的論文。

還有就是做量化 PQT 和 QAT，訓(xùn)練前和訓(xùn)練后量化會帶來不同效果，后續(xù)會提到一個模型的設(shè)計是否可以轉(zhuǎn)換成量化，是否適合，精度是否下降，模型本身與推理庫是否緊密耦合，模型在硬件上借助推理庫能否達(dá)到最佳，這是個考驗人的事情。對所有底層計算機視覺視頻增強任務(wù)大部分可以用查找表來做，例如銳化，二維三維都可以實現(xiàn)，對照度、對比度增強，甚至做得好可以做 8bit 到 10bit 轉(zhuǎn)換，速度性能非?？臁＿@里僅僅是給了大致的方向。

4、四位一體網(wǎng)絡(luò)模型設(shè)計

第四部分比較關(guān)鍵，四位一體網(wǎng)絡(luò)模型設(shè)計。

四位一體網(wǎng)絡(luò)模型設(shè)計，雖然是四個，但上圖中只有三個，大家可以猜一下還有哪一個。

第一維度是模型設(shè)計；第二維度是模型推理引擎，例如 TNN、NCNN、MNN 等很多，基于別人的推理引擎去改和優(yōu)化，推理引擎與網(wǎng)絡(luò)模型是否能很好結(jié)合，模型本身在不同的推理引擎上速度差別大，模型在 iPhone 上是跑在 CPU 還是 GPU 還是 NPU上，iPhone 的 Core ML 是個黑盒子，如果 OPS 不適合在 NPU上跑，數(shù)據(jù)就有可能一會兒在 GPU，一會兒在 NPU，模型效率低；第三維度是 Peak，意思是需要去度量模型，操作算子在指定硬件上，例如指定的硬件如高通、聯(lián)發(fā)科、華為芯片上，它的性能到底如何，一個模型在同一時代的機型上跑出的數(shù)據(jù)效率不同，最重要的是要將 roofline 模型圖畫出，反向指導(dǎo)我們設(shè)計模型。

還差一個維度是什么？我們做所有的事情所要實現(xiàn)的目標(biāo)就是快和效果，我認(rèn)為第四個維度是數(shù)據(jù)，我一直認(rèn)為基于業(yè)務(wù)做需求，數(shù)據(jù)占了功效的 60%。舉個例子，超分可以刷榜刷得很厲害，但到實際場景就效果不好，一定是要根據(jù)業(yè)務(wù)指定場景強相關(guān)。我們做了一個測試，所有東西從零開始，用自定義數(shù)據(jù)集，標(biāo)注好的 3 萬張圖片，將所有 YOLO 系列的模型參數(shù)全部設(shè)置在差不多的數(shù)量級，初始化一樣，訓(xùn)練結(jié)果發(fā)現(xiàn) YOLOv5 執(zhí)行度較高。但在 YOLOv7 文章中開門見山表示從零開始直接訓(xùn)練比多次訓(xùn)練效果好，這表明可能是在特定場景效果好，但在另外場景下是不一定的。

這里更細(xì)致地講一下在推理引擎端，模型設(shè)計盡可能運用到硬件算力本身，盡可能將其發(fā)揮出來。推理引擎、模型設(shè)計大家應(yīng)該不會忽略，相信大家做多了也知道如何并行、狀態(tài)信息化。上圖右下角絕對會被忽略，這是三個部門做的事情，看似毫不相干，但每個人做的應(yīng)該與其他兩個相關(guān)。早期 CL、Peak 和 RAMMER 做了硬件 CPU、GPU 在移動端 NPU 的性能度量，還有曠視的 MegPeak 也在 6 月剛好做了同一件事情，都在做說明這個方向是對的。

我認(rèn)為數(shù)據(jù)是最重要的，數(shù)據(jù)不穩(wěn)定，模型根本不用去想設(shè)計。數(shù)據(jù)要保證百分之百準(zhǔn)確，比如做目標(biāo)檢測的標(biāo)注，首先運用大模型預(yù)標(biāo)注，人工篩檢，再訓(xùn)練，再預(yù)標(biāo)注，反復(fù)幾次。標(biāo)注的時候只標(biāo)注一類，比如生成部署標(biāo)注十類，實際上做的時候一類一類標(biāo)注，這樣就保證每一類精度非常高，但沒人愿意標(biāo)注，覺得是粗活臟活，但這是把數(shù)值刷最高最有效直接快速的方法，丟給外包質(zhì)量不好，包括算法同事標(biāo)注質(zhì)量也差。所以要想出各種辦法通過算法本身將數(shù)據(jù)篩選出來做更多的事情，達(dá)到效率提升。