快手智能視頻圖像編碼處理服務架構


正文字數:9639  閱讀時長:14分鐘

本文來自於快手視頻算法工程師團隊負責人聞興在LiveVideoStackCon2020北京站上的精彩分享。憑藉本主題演講,聞興老師榮獲此次大會評選的優秀講師稱號。


文 / 聞興
文章整理 / LiveVideoStack


在視頻服務飛速發展的今天,視頻平臺如何在兼顧機器帶寬成本的同時,讓用戶獲得更加極致的觀看體驗,是每一個視頻技術團隊都會面臨的問題。


複雜的技術從計劃、研發、調試直到最終全量上線需要大量的線上測試及用戶反饋,這一過程耗時長久,甚至可以說永無止境。很多時候,一些技術開發出來後,因爲複雜度過高或者與實際場景差別過大,最終無法上線爲用戶提供更好的體驗。所以在技術的開發及落地中,唯一的衡量標準——是能否在真實場景中以更低的成本爲用戶帶來更好的體驗


本文中所援引皆爲已經在線上穩定運行的算法及服務,所有展示的數據均是線上實際業務中所產生的真實結果。希望本文分享的信息能夠給更多開發者帶來價值,也希望我們完成的這些工作能夠對大家未來的技術研發工作有所啓發。


本文將分爲四個部分展開:首先,我們簡單回顧短視頻行業的發展歷程並簡要介紹快手;其次,重點介紹快手用於分析/處理/推理/轉碼的多媒體算法引擎——Atlas;再次,深入介紹Atlas的基礎能力之一視頻圖像編解碼能力,這也是快手首次對外公開介紹短視頻轉碼系統和技術;最後,我們通過兩個實際的應用項目,即基於視頻內容的處理及分析(CAPE)以及視頻的AI智能增強,來進一步介紹Atlas的落地和使用場景。



1
短視頻行業及快手公司介紹



在過去幾年中,隨着移動互聯網覆蓋逐步飽和,我國互聯網的用戶整體規模增幅一直呈下降趨勢,但毋庸置疑短視頻行業已逐漸發展成爲當下最火爆的市場之一。從2019年的數據可以看到,中國短視頻用戶月活達8.2億,今年受疫情等因素影響,月活已接近9億。另外,短視頻應用使用時長的增長在行業內也佔據首位。


快手作爲一個國民短視頻社區,擁有海量的用戶和短視頻內容,日活用戶規模超過3億,日播放量達到百億級。每日產出UGC內容1500萬,原創短視頻庫達到260億。海量短視頻下多媒體內容處理的成本與體驗之間的平衡,不斷爲我們帶來了新的挑戰和新的驚喜。


2
多媒體算法服務架構平臺:Atlas

以下將詳細介紹快手的多媒體算法服務架構平臺Atlas。


2.1 爲什麼要做Atlas?


在進行多媒體算法開發的時候,業務方的需求一般主要集中於三個方面:場景、體驗和成本



場景需求角度來說,在實際應用中存在大量且需求迥異的業務場景,比如短視頻場景對清晰度和流暢度都有很高的要求,長視頻場景則更在乎內容的清晰度和沉浸感,而直播場景相對而言對流暢度的要求會更高一點,並且需要保證實時性,對延遲比較敏感。多樣化的場景會提出多種截然不同的優化目標。


體驗需求而言,難點在於部分業務方對體驗的要求及預期無法量化,主觀、感性表述往往較多,不能直接指導算法優化方向,因此專業的算法方案,需要同時兼顧客戶的理解力和使用門檻。另一部分業務方的需求則更加具體及專業,有的業務方既需要傳統算法,又希望能夠利用神經網絡推理能力;有的業務方既要做到儘量可控,又希望能有部分傻瓜模式以降低使用難度。


成本需求主要包含兩方面,一是機器成本,業務方永遠希望用最少的成本達到最優的體驗;二是部署及維護成本,希望算法和工程的迭代及優化效率足夠高,既要滿足層出不窮的新需求又要儘量不新增更多的人力投入。


如何能更高效地滿足這些需求?我們開始思考這個問題的解法,這就是快手建立多媒體算法服務端引擎Atlas的初衷。



(Atlas --- 阿特拉斯本是希臘神話舊神系中代表耐力、力量和天文的泰坦神,他被宙斯降罪放逐在大地之西,用雙肩擎起整個天空(Uranus或指宇宙);而在歐洲古典主義的建築風格中通常會用這類男性形象放在立柱的位置,這種結構也被稱爲Atlas。因此,我們爲這個核心引擎取名Atlas,也寓意着快手希望在用戶和開發者之間、需求和算法之間、算法和硬件結構之間能夠搭起一座座橋樑,起到連接支撐的結構性作用。)


2.2 Atlas 能力簡介


Atlas作爲多媒體處理算法引擎,已經在快手的各種線上服務全面落地,包括快手主站及海外的視頻/圖像分析、視頻/圖像處理、視頻轉碼等。與此同時,它也支撐了視頻剪輯和視頻製作工具“快影”企業級視頻智能生產雲平臺“OnVideo”,以及其它新業務的大量視頻分析、處理和製作需求。

Atlas現有的能力主要包括如下四個方向:視頻圖像壓縮畫質增強音頻處理,以及智能生產



在快手每天會新增千萬級的視頻內容,這些視頻的服務端轉碼任務都是通過Atlas來完成的。在視頻圖像壓縮方面,我們一直在追求這一基本能力做到精益求精,從而達到爲客戶節約成本,爲用戶提供最優體驗的目的。通過自研的K系列編碼器 (K264/K265/KVC),Atlas展現了對於視頻及圖像的極致壓縮能力。我們會在本文中後面的部分詳細介紹快手的短視頻編解碼架構,作爲其中核心的K系列編碼器,以及上線後的具體收益。除了基本的編解碼處理能力,Atlas也提供基於內容的智能處理與編碼 (CAPE,Content Aware Processing & Encoding),在後面的部分我們也會給出一個視頻CAPE的應用實例,來詳細說明如何搭建對應服務並取得線上業務的收益。


音頻處理方面,Atlas包含音頻美學,響度均衡,智能降噪,智能音效等功能。快手平臺通過應用響度均衡處理技術和標準,能夠有效規範平臺的音頻響度和動態範圍平衡,避免切換不同視頻時,聲音響度忽大忽小。而智能降噪技術已經應用在快手直播,視頻會議及快手K歌等多個業務場景。Atlas除了提供上述對音頻的處理能力,也支持智能化的音頻壓縮算法,例如內容自適應音頻編碼 (CAE)等 。


除此之外,Atlas也具備很多非常成熟的圖像算法處理能力, 例如在畫質增強方面的失真去除 (De-Art) 、超分辨率 (SR)、視頻插幀(FRUC)、色彩一鍵增強以及暗光增強等。這些算法及功能已經長期穩定地服務於快手平臺及海外各App,服務範圍涵蓋了移動端的編輯和上傳流程,以及服務端轉碼相關的處理和增強等重要任務。


智能生產方面,Atlas中具有很多獨特的功能,比如精彩片段挑選、智能封面挑選和裁剪等。快手智能影集就是基於Atlas這些獨家能力進行開發並持續迭代的。智能影集功能是通過對用戶作品集的內容進行理解及分析,精選出用戶公開作品中的優質片段,並以一定的故事線(時間或地點)邏輯裁剪梳理出視頻集錦片段,最終結合特效片段合成出影集作品。


通過上述Atlas獨具特色的能力,不同的用戶可以根據自身業務及產品的需求,快速提升用戶體驗或搭建有趣的功能或玩法。


2.3 Atlas 架構簡介


作爲視頻行業最火爆的公司之一,快手的業務需求種類繁複,橫跨各種應用場景,但萬變不離其宗,絕大多數的的需求都可以拆解爲內容分析識別、處理增強、編碼壓縮以及硬件加速四個階段。通過Atlas完善的接口及架構設計,算法開發方能夠高效的跨越四個階段,從而對業務方的需求進行快速響應和迭代;而用戶也可以基於Atlas的架構低成本的搭建自己的服務,或將Atlas中的算法能力應用於產品中。接下來我們將對Atlas的整體架構及設計邏輯進行詳細介紹。


2.3.1 邏輯架構


Atlas的整體架構從邏輯上劃分,可分爲四層:



服務接口層:Atlas的接口層是直接暴露給用戶的,用戶通過接口層進行任務的詳細配置,例如需要使用的分析及處理算法組合,編碼器及參數設置,硬件(GPU)加速方式等。此外,Atlas也提供命令行驅動、API集成等多種調用方式,用戶可以根據自身需求靈活地搭建服務。


分析及邏輯決策層:Capella是Atlas的分析及邏輯決策層。這一層主要有兩個功能,一是進行內容的特徵分析及質量評估;二是根據分析結果 ,配置後續操作的“菜譜”(Recipe)。這裏的“菜譜”包括後續算法服務層會使用哪些算法,以及這些算法的順序和配置:比如用H.264/AVC還是用H.265/HEVC編碼,採用怎樣的編碼配置;如何做前處理,包括做哪些處理及處理的順序和參數,是先做去噪還是先做色彩增強,強度如何?


算法服務層:這是最核心的一層,主要分爲三大模塊,其一是音頻、視頻及圖像編解碼器(Codec)模塊;其二是圖像算法引擎VisionEngine,是包含各種自研圖像算法的工具集;其三是EVA(Elastic Video AI Inference),它是一個AI網絡推理庫,主要包含一些針對視頻和圖像的自研深度學習網絡。


硬件層:作爲最底層,包含了CPU鏈路、GPU鏈路及混合鏈路。


2.3.2 視頻處理編碼鏈路



我們通過線上常見的一個轉碼任務流程爲例,來進一步說明Atlas的架構。在一般轉碼任務中,我們會首先對視頻進行前處理,然後再做編碼。用戶在搭建類似服務時,可以直接通過Atlas內的Codec管理器和Filter管理器選擇希望使用什麼類型的編碼器和前處理算法。在配置前處理算法時,如果選擇傳統算法,就會調用圖像引擎VisionEngine中的相應算法能力;如果需要深度學習算法,就會通過EVA引擎獲得網絡推理能力,爲減少讀取網絡造成的延遲,EVA將作爲一個Daemon啓動,通過進程間通信傳輸推理數據。


在GPU硬件加速方面,Atlas全鏈路支持NVIDIA平臺的編解碼、處理、推理能力,包括NVENC/NVDEC、CUDA、TensorRT等原生API和框架,同時也會提供CUDA版本的PyTorch和Tensorflow給用戶做驗證和測試。在Intel平臺上,也可以通過MediaSDK、OpenVINO等框架獲得Intel GPU的計算能力。


Atlas支持全GPU鏈路全CPU鏈路,及混合鏈路三種任務執行方式。全GPU鏈路,即從解碼到轉換、推理,再到前處理以及編碼的全流程都部署在GPU上,提供最高的吞吐率。這樣的鏈路比較適合一些對壓縮比追求沒有那麼高的工作,比如預覽或存儲。而混合鏈路則可以提供極致的壓縮及處理效果。一方面,爲追求極致的壓縮率,Atlas會使用CPU運行軟件編碼器;另一方面,當需要網絡推理的算法時,用戶可以在GPU上進行推理的加速。這樣做的優點在於既可以利用深度學習網絡取得更好的視頻處理結果,也可以得到極致的壓縮比。而混合鏈路的缺點是其整體的I/O開銷會比較高,需要把數據在GPU和CPU之間互傳。簡言之,無論是GPU鏈路、CPU鏈路還是混合鏈路,用戶可以根據具體工作進行選取,選擇需要使用到的具體鏈路。


2.3.3 交付、集成及部署


在最終交付時我們會將底層的算法庫、第三方庫,打包Atlas整體鏡像。當業務方獲得Atlas鏡像後,就可以在上面直接構建自身服務的鏡像。此方法的優點在於集中度高、性能可控性高,升級的耦合度比較低。同時我們的技術團隊正在致力於把底層再拆解成單獨的小鏡像來做微服務,提高部署的靈活性。



3
Atlas核心能力——視頻編解碼

以上是Atlas的整體架構介紹,接下來將着重介紹Atlas的核心能力之一,視頻圖像壓縮中的視頻編解碼能力。在進入正題前,希望先和讀者分享一些我們從客戶價值出發而產生的思考,比如在日常編解碼開發過程中遇到的各種難點和問題,我們是如何解決這些困難的,如何更高效的將研究中的算法落地,如何更好的理解和服務用戶,以及應當如何體現編解碼開發者的價值。


3.1 編解碼開發與用戶體驗之間的鴻溝


在編解碼開發到最終全量上線改善用戶體驗的過程中,一般會經歷如下三個階段:離線開發階段實際測試階段真實上線階段,而三個階段之中又有着多個複雜的鴻溝。



離線開發階段一般代表算法或工具的開發初期,或標準建立過程中的早期階段,在這個階段主要關注的是“信號保真度” (PSNR/MSE) 和“碼率” (Bitrate) 之前的權衡,一般會通過少量測試序列,計算BD-Bitrate及BD-PSNR等客觀指標。但這些指標是很難反映工具或算法在真實場景的有效性的。


而在實際測試階段,主要關注的是視頻“主觀質量”與“真實文件大小”之前的平衡。而這一階段與離線開發階段之間,其實已經存在一個巨大的鴻溝 (GAP1):


GAP1-1信號保真度本身無法反映主觀質量爲了能夠評估算法或工具帶來的主觀質量的變化,業界一般是通過例如SSIM、VMAF等客觀指標來嘗試逼近主觀質量,但這種方法得到的結果和真實主觀質量的相關性有限;更極端的方案,就是對於每個工具及算法都進行主觀質量評估,根據所得的MOS/DMOS評分獲得真正的主觀質量變化,但是這個方案對人力和時間的需求都很大。


GAP1-2碼率與真實文件大小的區別可能很大真實的文件大小會受到音頻編碼、視頻內容、目標質量的檔位、文件格式的冗餘等因素的影響,會和簡單估計視頻碼率產生很大的差異。同時在一般離線測試的時候,爲了保證算法迭代效率,測試集最多幾十個,最多到百級,是無法代表千變萬化的視頻內容的,尤其是對於UGC短視頻內容,場景更是紛繁複雜,大千世界無奇不有。在快手,我們的實際測試階段一般每天要進行數萬至十萬級別視頻的線上環境測試,測試一般進行一週左右才能看到線上真實文件大小的變化。而根據我們技術團隊的實際經驗,實際測試階段的文件大小變化和離線測試的碼率變化的差距甚至可能達到50%~100%。


是否跨越這個階段就萬事大吉了呢?當然不是。從第二階段到第三階段,即真實上線階段之間,鴻溝依然巨大:


GAP2-1主觀質量和用戶行爲之間的關係依然是一個迷團即使在測試階段對主觀質量有了一定的評估,主觀質量的變化首先需要被用戶感知或感受之後,纔會對用戶的行爲產生影響,這種影響對單個用戶或單次行爲可能是非常微小的,比如多看了一個視頻或者某個視頻多看了幾秒。但現階段學術界對人類視覺系統(HVS)的運作規律依然知之甚少,所以我們目前只能通過平臺的億級用戶的百億級播放量,來進行大規模A/B實驗和觀察用戶的QoE/QoS指標,從側面反映及理解用戶的真實行爲。


GAP2-2真實文件大小和最終線上帶寬節省的差距不容忽視很多人認爲真實文件的大小的變化就是最後線上帶寬成本的變化,這是一個常見的錯誤認知。問題在於每個作品有其不同的熱度,播放量少則十幾次,多則百萬次甚至千萬次。每個視頻的碼率的節省或者增加需要乘以每個作品的播放次數,才能計算出最終帶寬的變化結果。同時還要考慮設備的限制,線上的下發邏輯等,而這些條件都會影響線上不同檔位及不同標準的用戶端覆蓋率,全部考慮在內後才能推測出真實線上帶寬的變化。


因此只有跨越了這些鴻溝,最終到達第三階段即真實上線階段,才能夠體現算法、工具和標準是否對用戶有影響,是否對用戶體驗有貢獻,才能夠體現編解碼開發者的真正價值借用某部電影中的一句臺詞來總結這三個階段,就是九個字,第一個階段“見自己”,第二個階段“見天地”,第三個階段“見衆生”。


3.2 我們的做法


接下來將詳細介紹我們團隊日常是如何來進行開發,跨越多個鴻溝突破這三個階段,提高用戶最終體驗的。


3.2.1主觀質量盲測標註平臺


我們依照VQEG標準規定的方式,構建了快手的主觀質量盲測及標註平臺以及一系列的測試標準,在內部已推廣至多個部門及團隊。同時我們聯合QA團隊,培養了一批“黃金眼”。通過組織“Gold Eye敏感性測試”,篩選出一批觀察入微,對質量變化敏感度高的同學作爲“黃金眼”的備選團隊。


而對於我們開發的每一個算法及工具,在上線之前,我們都會聯合QA團隊和“黃金眼”團隊的成員一起來進行主觀評測,取得MOS/DMOS分數。同時仔細分析每個視頻質量的優劣。經過多維度的對比評價,通過主觀質量盲測的算法和工具才能進行到下一個A/B測試的階段。



3.2.2 音視頻相關主要指標-評估收益


A/B 測試是針對一個變量的兩個版本,來觀察用戶的不同反應,從而測試哪個版本更有效的一種方法。例如:將視頻按照不同的算法壓縮兩個版本,下發至千萬級的實驗用戶組和對照用戶組,然後觀察這兩個用戶組的行爲。通常來說,觀察的指標爲兩大類:QoS和QoE。



QoS指標包括首屏時長、卡頓率、丟幀率等等,和用戶體驗息息相關。而且我們團隊自三年前就持續關注用戶播放時的CPU、Memory和功耗情況,而這些指標對用戶體驗也影響深遠。


QoE指標包括播放量、人均播放時長、播放完成率等等,是用來衡量最終優化效果的指標,QoE纔是反映用戶在平臺的停留時長、反映用戶對平臺是否喜愛的因素。一般對算法A/B實驗的原則是必須要將QoE全部指標優化至正向或持平的狀態才能上線,而QoE負向的話是不可能上線的。很多算法在離線測試階段,甚至是實際測試階段都有着不錯表現,但往往上線A/B測試後才發現QoE指標不理想。所以只有通過在真實上線階段,才能反映算法和工具對用戶體驗是否真的有正面影響。同時我們也會分多個維度來分析QoE和QoS的指標,包括客戶端、手機系統、版本、機型、粉絲數、地域、同時在線人數等等。快手內部有一個完善的流媒體大數據平臺,部門內也有專門的數據分析師和算法的開發同學一起結合自動化工具來分析這些指標。


3.3 快手短視頻編碼能力發展歷程


這是我們首次對外披露快手的短視頻轉碼能力,也是我們部門多個團隊合作的一個階段性總結。由於線上帶寬數據涉及公司機密,所以這裏只能以“實際文件大小”數據來間接描述整體的能力。



3.3.1 時間線


“K系列編碼器”是快手自研的一系列視頻及圖像編碼器的統稱,包括K264,K265以及KVC。涵蓋了四種不同的編解碼標準,其中包括由ITU-T與ISO/IEC聯合發佈的國際標準H264/AVC和H.265/HEVC;由快手自研的視頻編碼標準KVC以及自研圖像編解碼標準KPG。


如圖中所示,快手的線上短視頻轉碼共經歷了兩次重大的技術迭代。自2018年7月起,我們開始進行自研編解碼器的研發和上線。2018年底我們自研的K265全面上線,快手由H.264/AVC時代進入到H.265/HEVC的時代,而整個H.265/HEVC時代線上的文件大小下降了56%。


自2018年底開始,我們開始了自研編解碼標準KVC項目以及對應編解碼器的開發。在經歷了艱苦卓絕的算法研發以及大量的A/B實驗後,KVC於2020年初全量上線,這也標誌着快手提前進入了編解碼的“次時代”,進入了快手自研編解碼標準--KVC的時代。對比H.265/HEVC當時壓縮比最高的檔位Unicorn,線上的文件大小下降了27%。


而上述這些數據,是快手線上每天千萬級新增視頻,每天百億次用戶播放的真實數據,是經過多次實際A/B實驗後,分析優化跨越鴻溝後的成果,是兩年來多個部門團隊通力合作,持續迭代的心血。


能夠在線上實際應用場景取得如此的收益,其實也得益於我們的技術團隊深度參與多個國際視頻標準的制定,在視頻技術的最前沿有着深厚的積累和貢獻。在新一代視頻壓縮國際標準H.266/VVC的制定中,快手提交了過百件技術提案,並有數十件技術提案獲採納進入H.266/VVC標準。而在AVS3標準的制定中,快手從2020年3月開始參與,已有12件技術提案獲採納進入AVS標準。



3.3.2 指標收益


這裏我們給出K265以及KVC上線後,線上真實的指標收益。文件大小的收益其實與我們離線測試的結果有着很大的不同,這也是我們在之前文中提到的兩個階段的鴻溝之一。另一方面,QoE及QoS的結果在沒有進行線上A/B實驗,僅憑離線測試階段的測試是完全無法預測和衡量的。



K265-Romeo上線後,除了明顯的帶寬成本收益外,QoE在人均觀看時長和人均播放次數上也獲得了一定增益。而QoE上的收益我們猜測是因爲QoS的大幅提升,從而影響到了用戶行爲。


KVC-1.0上線時,成本收益顯而易見,卡頓率也明顯下降,但QoE收益基本保持不變。我們推斷可能是因爲之前下降的幅度也比較大,用戶已進入QoS的舒適區,感受就沒有那麼明顯。



3.4 編碼端優化算法:CAQ + CARDO


在K系列編碼器中,我們有着大量的自研工具及算法優化,而大部分的算法及工具都是經過了多次上線實驗的反饋迭代而成。CAQ就是其中的一個很典型的例子。


CAQ這個工具比較有趣,因爲其上線後的收益比實際測試階段的收益要高出50%,在同等文件大小下主觀質量提升明顯,但同時部分客觀指標會下降,所以並不適合離線測試評估或進行“打榜”,但對於真實用戶體驗有明顯提升。下面簡要介紹一下CAQ的算法。



其算法的主要思想如下:CAQ算法中的第一部分類似x265中AQ的操作,在獲取視頻幀後對其進行內容分析,獲得JND Factor從而計算出QP偏移。JND Factor包含三個部分:一是圖像塊的平均亮度值;二是紋理強度(紋理強度指的是首先做一個邊緣檢測,得到塊級邊緣強度和梯度方向);三是紋理特點,例如是平滑、邊緣、規則紋理(例如網格)、不規則紋理(例如草地或噪聲)等。根據這三個特徵,再結合內容的運動特性,從而得到塊級的QP偏移。但是,直接使用這些QP偏移可能會造成幀或序列級別的碼率波動較大,爲了控制這種波動,我們使用一個模型來預測CAQ可能產生的碼率變化,從而再次修正QP偏移。同時結合視頻內容特徵,在CAQ和自適應CUtree這兩個工具所產生的QP偏移值之間進行合理選擇,讓那些主觀質量提升不明顯的序列能夠最大化客觀性能收益。


CAQ算法中的第二個部分CARDO主要包括兩個算法:第一,感知量化(perceptual quantization),即在量化過程中保留主觀失真敏感度高的區域的部分量化係數;第二,融合邊緣梯度失真(edge-based gradient difference)的率失真優化,即在率失真代價函數中的失真部分加入邊緣梯度失真(edge-based gradient difference),同時對λ的選擇進行調整。


下圖是整體方案應用後的一個例子。我們將藍色部分的碼率重新分配給黃色和綠色的部分。如圖可見,原來衣服上珠花的部分其實分配了大量的比特,但人眼對複雜的不規則紋理並不敏感。當我們將這部分碼率拿出來重新分配給睫毛、人臉等一些細節部分時,整體主觀質量的提升就會非常明顯。



4
Atlas實際應用


下面將介紹兩個Atlas實際應用的例子,分別是CAPE(基於內容的處理與編碼)和視頻AI智能增強。


4.1 Atlas-CAPE



Content Aware Processing & Encoding (CAPE) 指的是內容自適應的處理和編碼,主要可以分爲以下幾個維度:Per-Category、Per-Title、Per-Segment,再細化的話還有Per-Frame和Per-Block等。這個概念早已存在,如Netflix和YouTube在線上也有很多這個方向的應用,其最大的難點就在於如何衡量質量,及如何尋找到一個質量“足夠好”的工作區間。


目前快手線上CAPE的應用有多個種類,並大規模應用於短視頻上傳,轉碼以及直播等場景。



上圖是一個Atlas常用的CAPE框架。Capella就是之前在Atlas架構中提到的決策和分析層。在決策和分析層中會主要分析如下幾個方面:其一,視頻源的Metadata,即視頻的生產類型和上傳途徑等原始信息;其二,進行熱度分析,掌握其當前的觀看數、點贊數等;其三,視頻的基礎數據,比如寬、高、幀率和碼率;其四,進行視頻的時間和空間複雜度分析;其五,對內容進行基礎特徵分析,而基礎特徵中包含了模糊程度、噪聲估計、壓縮失真估計等等。其六,對視頻進行內容理解,基於場景分類做針對性編碼方案。通過算法決策模塊可以得出是否要做視頻增強,做哪些視頻增強,做多強的視頻增強,獲得對應的參數,同時告訴編碼器,應當使用哪些檔位編碼可能會比較好。



再舉個例子——直播推流中的CAPE應用。爲儘量避免算法變得很笨重,在直播應用中實際用到的分析步驟不多,同時我們會降低分析的頻率,約一秒鐘一次對視頻源進行時間、空間的複雜度進行分析,同時再附以一些基礎特徵的獲取。其中最大的難點是在做直播推流時,移動端有很大比例用的是硬件編碼器(如iOS平臺的VideoToolbox),可配置參數都比較基礎並且數量較少,此時我們會給出一個硬件建議編碼參數,來保證在場景切換或是在一些座談場景時,能夠儘量不要多浪費碼率。直播推流CAPE上線後,文件大小降低了約10%,QoE沒有明顯變化,QoS收益也接近10%。


4.2 Atlas-AI視頻增強


下面介紹Atlas在實際應用中的另一個例子:AI視頻增強。在Atlas-AI視頻增強算法觸發策略中,最重要的工作是在分析模塊Capella中完成的。



首先,根據視頻的分辨率以及導入邏輯,判斷它是不是從別的平臺導入,是否經歷過多次的壓縮,當前的視頻質量到底如何,進而根據不同的質量選擇不同的模型。另外根據分辨率,可能會用到不同種類的SR網絡或算法,有的是固定上採樣大小,有的是任意上採樣大小。同時每個視頻還會進行噪聲和色彩及亮度評估,看是否需要進行降噪處理或HDR優化。


目前,經由De-Art/SR處理過的視頻在線上播放端覆蓋率約爲10%,並未佔用過多機器資源。因爲我們技術團隊對模型複雜度做了大量的簡化,在算法精度顯著提升的情況下,速度提升到了最初版本的7倍左右。SR優化後實現了720p/30fps,De-Art優化後效果更顯著,從最早版本的7fps提升到50fps。


我們依然在持續觀察用戶對於具體效果的感知及行爲變化。按照10%的覆蓋率來評估的話,De-Art/SR上線後,在播放量和播放時長方面的收益非常明顯的,整體的投入產出比(ROI)非常高。


小結和未來展望


在快手海量且場景豐富的視頻業務背景下,Atlas經過了持續考驗和打磨,已經成長爲越來越標準化、通用化的技術架構,我們將繼續豐富和沉澱算法和平臺能力,把對客戶和用戶更具價值的技術方案和產品提供出來,以應對國內、海外,點播、直播、實時互動等多樣化的場景考驗。更長期來看,我們的團隊希望能夠面向5G+AI時代的要求,將雲端音視頻處理和生成能力向極致的高性能方向不斷深入優化,並且保持好奇心,持續探索各種技術和業務創新的可能性。


LiveVideoStackCon 2021 ShangHai
我們準備好全新的內容
在上海歡迎您的到來

LiveVideoStackCon 2021 上海站
北京時間:2021年4月16日-4月17日

點擊 【閱讀原文】瞭解大會詳情



本文分享自微信公衆號 - LiveVideoStack(livevideostack)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章