音視訊消費的新場景催生了越來越多新的技術需求，從當下的直播、點播、RTC，到未來的 XR 和元宇宙，音視訊技術對新場景的支撐越來越趨向於綜合性，近年來 AI 演算法發展迅猛，但是較好的演算法效果往往需要消耗很大的算力資源，這使演算法商業化落地面臨非常大的挑戰。我們應該如何充分發揮軟硬一體的能力？如何有效平衡演算法效果和效能？
在 LiveVideoStackCon2021 北京峰會，阿里雲智慧視訊雲高階演算法專家楊鳳海，從阿里雲視訊雲的最新場景探索出發，帶來了阿里雲視訊雲在虛擬背景、視訊超分等方向的最佳創新實踐經驗分享。
文 | 楊鳳海
整理 | LiveVideoStack
本次分享主要分為 5 部分，包括前言、演算法層面的創新和優化、軟硬體層面的深度優化、未來展望和 QA。
1. 前言
音視訊從業務形態上來說包括直播、點播、RTC、媒體生產和處理，以及雲遊戲、雲桌面等。從技術鏈路上來講包括採集、編碼、傳輸、雲端轉碼 / 處理 / 渲染、網路分發、接收端解碼和渲染，其中涉及到演算法的部分包括編碼前處理、解碼後處理、雲端視訊處理。
按照算力高低排序，服務端算力最強，端上相對較差，因此可以大致描述為一個正態分佈的形式。根據該正態分佈曲線，現在大部分演算法都部署在雲端，少部分會部署在端側。
從音視訊和演算法部署的現狀來看，整個軟硬體體系是異構的，基本上涵蓋了雲端伺服器和邊緣伺服器、各種終端裝置和 IOT 裝置。
從硬體層面來講，包括 CPU+GPU、CPU+FPGA、CPU+DSP 和 CPU+ASIC 晶片等。涉及到的晶片廠商也非常多，主流的包括 Intel、AMD、ARM、Nvidia、高通、蘋果等，作業系統覆蓋也比較全面。另外，軟體標準、開發編譯環境、深度學習的訓練和推理框架也千差萬別。
如此複雜的異構軟硬體環境對演算法落地提出了前所未有的挑戰，如何充分發揮軟硬一體的能力？如何有效平衡演算法效果和效能？這是兩個必須要解決的問題。
2. 演算法層面的創新和優化
下面我將通過虛擬背景和超分兩個演算法來介紹我們是如何從演算法層面做到效能和效果的平衡，從而為業務創造價值的。
虛擬背景
我們先來看下演算法的背景，相信大家從去年疫情到現在都體驗過線上視訊會議、陪娃上網課等，當然沒娃的朋友肯定也看過直播、短視訊、關注過線上相親等場景，這些場景大家其實非常希望能夠把自己置身到一個虛擬的環境中，一方面可以保護個人隱私，另一方面也能有效的增加趣味性和沉浸式的體驗。
瞭解了演算法背景，我們現在來看下如何在業務中落地？
首先是場景可能會非常複雜，光線、噪聲、場景（室內、室外、單人 / 多人、會議室、辦公區、場館、居家等）、前景背景邊界不清晰、手持物、服裝裝飾非常多樣化；
其次是可用來訓練學習的資料非常少，各開源資料集標註標準不同而且精度不滿足商用要求，人工標註費時費力；
最後是計算效能方面，雲端要求高併發低延時、終端要求低延時低功耗低資源佔用。
這就要求我們必須設計一個魯棒性非常好的演算法，並且能夠滿足不同部署端的效能要求。我們知道區分人像的畫素級演算法有分割和摳圖兩大類，當然還有一些細分的領域，例如語義分割、例項分割、視訊目標分割（VOS）、全景分割（Panoptic Segmentation）、藍綠幕摳圖、自然場景摳圖。
我們應該選擇哪一種來進行落地呢？首先要知道我們落地的場景目前主要是教育 / 會議 / 泛娛樂場景，經過效果和效能的綜合評估，我們認為針對人像的語義分割可以滿足業務訴求。
確定好演算法方向後，我們首先要做的就是要站在巨人的肩膀上進行創新，那就必須要了解過往多年該領域的演算法發展脈絡。
可以看到從最初的 FCN 到後來的 segnet、Unet 系列、DeepLab 系列、HRNet 等，從演算法設計和創新角度基本上遵循了 Encoder-Decoder 的結構，然後嘗試設計不同的 backbone 和 Block 來平衡演算法效果和效能，再就是多分枝設計、多解析度的融合、以及 Coarse2Fine 的結構和各種 Attention 等等。
從發論文的角度很多演算法模型會設計的更深（更多層）、更寬（更多並行分支、更多的 channel、更大的 featuremap）、更密集的連線、更大的感受野、獲取更多全域性資訊等，但是從業務落地的角度來講，這些複雜的演算法都很難在端側裝置上實時執行。
大道至簡，我們演算法天生是要以滿足不同異構平臺的部署為目標的，因此我們採用了 Unet 的框架，然後融合了各種輕量化 Block 的設計思路，參考了包括 SqueezeNet、MobileNet、ShuffleNet、EfficienNet、GhostNet 等。
另外充分利用空間維度和 channel 維度的 attention 結構，充分融合多解析度特徵，但同時又要保證計算不被拖慢，針對不同硬體平臺差異化的設計、最後就是結合業務場景設計特定結構和損失函式等，包括特定的邊緣 loss，線上難樣本挖掘等。
神經網路模型的提升離不開場景和資料，因此在設計演算法之前我們首先要定義好當前的業務場景，然後再構建資料集，並通過資料訓練迭代演算法，演算法反過來再通過線上業務實踐收集 badcase，重新清洗和擴充資料集，再次 fintune 演算法模型，最終場景、資料和演算法三者有機結合、迴圈迭代才能趨於完美。
由於資料集本身的分佈有限，因此資料增強是必不可少的。傳統人像貼圖色溫差異大，合成效果糟糕。如果拿這樣的資料加入訓練，對整體的收益不會很高，而且合成效果不好的話可能還會有副作用。因此我們採取動態白平衡和金字塔融合的策略，來保證前景和背景融合更真實。
由於人工資料採整合本較高，而且也很難覆蓋所有人像動作姿態、環境和服飾等，因此像左下角圖中所示，我們通過特定人像、動作、場景的 3D 動畫貼圖來進行資料擴充；右邊分別是對光照、噪聲和運動模糊的抗干擾能力的提升，我們對原始資料和增強後的資料經網路輸出的結果計算一致性 loss，以提升模型的魯棒性。
演算法設計的再好，實際業務場景中難免會出現一些 badcase。例如人坐在桌前，手臂和身體不是一個連通體，如果單純使用之前的模型，可能手臂會被誤認為背景，為此我們研發了多工聯合學習方法。同時結合人像分割、人體關鍵點，人體解析等對模型進行多工聯合訓練學習 。
最終推理時，其他任務不參與推理，只在訓練階段用於幫助分割模型提取和學習相關資訊。這樣做不僅可以提升模型效果，還不會增加模型的複雜度。
另外大家或多或少應該都體驗過虛擬背景的應用，可以看到不論哪家廠商，在邊緣的處理上都不是很好，因此我們針對邊緣還專門設計了特殊的 loss 約束，使得邊緣精度得到明顯改善。
在最終落地時需要對模型進行輕量化處理。常用的方法包括剪枝、壓縮、蒸餾、量化和 NAS，這裡以蒸餾為例來介紹下我們是如何進行模型輕量化的。
首先來看下知識蒸餾的發展歷程，2014 年 Hinton 釋出了開山之作 Distill the knowledge in a neural network，簡單來說就是分別訓練一個複雜的老師網路和輕量的學生網路，然後利用 KL 散度使學生的輸出和老師的輸出逼近，後來一些改進的文章中也有人討論了在分類網路中傳遞的 spatial attention 給學生網路的方法。
蒸餾在分類任務上表現相對較好，但在畫素級任務，無論是分割、matting，還是超分，蒸餾都非常難調節。這些年也有論文在論述該問題，比如微軟的文章：structured knowledge distillation for semantic segmentation 就提出利用特徵圖中任意兩個畫素之間的相似關係進行蒸餾，同時還利用了畫素分類的 KL 散度蒸餾、以及基於 GAN 的對抗式蒸餾等。
除此之外，還有論文利用 focal loss 的思想進行蒸餾。首先計算學生網路 loss，對 loss 大的位置賦予更大的權重，最後根據這些權重來計算蒸餾的 loss。
我們充分結合了畫素分類的 KL 散度蒸餾和基於 GAN 的蒸餾方法等來進行蒸餾。
這是實際的演算法效果，有單人換背景、虛擬課堂、虛擬會議室等，可以在保護隱私的同時為枯燥的會議和課堂等提供一些小小的樂趣。
視訊超解析度演算法
目前視訊超分演算法應用在端上功耗非常大，所以其主要應用在服務端視訊超高清場景中，包括 2K 超 4K、4K 超 8K 等。
如何在端上進行超分？我們現在落地場景主要為 RTC，RTC 無論是延時、包的大小、功耗還是資源佔用要求都很極致。基於 RTC 業務特性，阿里雲選擇端上弱網場景進行超分。
弱網時，通過 QOS 策略可以把解析度、位元速率、幀率降低來滿足網路流暢傳輸的要求。在播放端通過超分演算法對畫面進行高清重建。這樣不僅可以在弱網情況下保證傳輸質量，還可以使使用者獲得不錯的觀看體驗。
回顧近幾年超分模型發展歷程。主要分為傳統演算法和深度學習演算法兩大類。傳統演算法就是大家熟知的幾種插值演算法。從 2014 年的 SRCNN 開始到現在，不斷的有新的關於深度學習的論文出現，但是這些論文真正能夠在端上跑起來的很少。
通過這些網路結構可以總結提煉出一些設計思路，基本上就是採用殘差結構，或者遞迴結構，亦或者 Dense 結構，還有一種是基於 GAN 的，但是 GAN 在端上實現起來更為困難。為了提取視訊幀之間的相關性資訊，可以使用 3D 卷積、可變性卷積、光流和運動估計等方法，計算資源消耗同樣很大。
超分演算法本身要解決的是個病態問題，無論是從低解析度到高解析度，還是從高解析度到低解析度，不存在一個確定的對映函式，所以學習起來十分困難，而且在視訊中，要利用幀間的資訊進行對齊，難以滿足在端上的實時性和功耗要求。
在 RTC 的場景下，要在低功耗的前提下保證演算法效果，並且對包大小、CPU 佔用率、GPU 佔用率、功耗發熱等要求都十分苛刻。另外，即便覆蓋了中高階機型，如果仍然有很大一部分中低端機型無法覆蓋，從業務和商業化的角度來講會損失掉一部分客戶，因此我們的目標是要覆蓋所有的機型。
圖中大致描述了我們超分的網路結構。我們知道演算法離不開真實場景，只有場景化的演算法才會有更好的業務價值，在 RTC 場景中，首要考慮的就是編碼的壓縮以及下采樣導致的損失。
我們在設計模型時，就已經將編碼的壓縮以及下采樣的損失考慮進去，在模型前半部分新增了失真修復的模組。在模型的後半部分是對上取樣後的圖增強來逼近 GroundTruth。兩部分都採用了 Attention 的結構輔助特徵提取。
對人像和普通畫面進行超分相對容易，但是對存在文字、字幕的場景進行超分，文字高頻資訊不僅在下采樣過程中易丟失，同時在編碼過程中也極易被破壞，非常容易出現 badcase，我們針對該問題進行了一系列優化。
首先會對文字進行大量的資料增強，包括字型、顏色、角度等，另外，引入針對邊緣優化的 EdgeLoss，能夠有效地提升文字超分效果。
在落地時輕量化一直是需要考慮的問題。我們使用結構重引數化來設計網路，結構重引數化的本質就是通過並聯一些特徵提取分支進行訓練。
例如本身只存在一條 3x3 的連線提取特徵，可以並行幾條其他的卷積，最終推理時通過結構重引數化公式進行合併。雖然在訓練時會增加大量的計算量，但是在推理時完全沒有影響，而且可以提取更多的資訊和特徵。通過這種結構，我們很好的平衡了演算法效果和功耗。
輕量化不僅可以使用結構重引數化，還可以使用稀疏化剪枝。如果純粹對連線進行稀疏，稀疏完後在 CPU、GPU 的計算不一定會變快。對於 GPU 的計算來說，高度並行的資料相對來說更為友好，純粹對連線進行稀疏，看似將部分連線被掏空簡化引數和計算量，但實際計算時由於 channel 對齊或訪存不連續等不一定會減少計算延時。
因此，目前業界大多采用結構化的稀疏方式。左邊兩張圖某個卷積核相關的引數，在統計其引數絕對值的和隨時間變化的曲線後發現，如果逐漸趨向於 0，說明這個分支本身非常稀疏。對於其中一些數值非常小的連線，可以進行裁剪，但在裁剪時，也要考慮到前後 layer 的連線問題，從整體結構上進行裁剪。
這裡的兩張圖上表示了超分演算法的統計基線對比。通過左圖可以發現，超分演算法在不同的檔位效果都比傳統演算法好，很明顯不在一個檔次上。右圖，我們統計了超分演算法在不同的位元速率幀率下 PSNR 大致的分佈，有了這個分佈圖之後，就可以反過來指導 QoS 策略，在不同頻寬下合理的降位元速率和幀率。
這是直播場景的超分演算法效果。
這是文字場景的超分演算法效果。
3. 軟硬體層面的深度優化
在開頭我們已經提到異構硬體非常多，但是在實際業務場景中 CPU 和 GPU 優化會工作會佔據 90% 以上，所以這部分我們主要以 CPU 和 GPU 為例來介紹優化策略。對比來看 CPU 更適合做控制邏輯比較複雜、序列的工作，而 GPU 因為有大量 ALU 單元，更適合做並行的計算。
該圖簡單介紹了 CPU 的軟硬體架構。從整體的設計來看，CPU 的架構分為複雜指令集和精簡指令集兩類。複雜指令集以 X86 為代表，精簡指令集以 MIPS、ARM、RISC-V 為代表。CPU 有一個重要的特徵是其三級快取。在優化時必須要先了解其軟硬體結構，才能選取更適合的優化方法。
圖中描述了 CPU 計算的流程，要完成計算首先要取資料，需要拿一個虛擬地址去記憶體管理單元通過 TBL 查表定址，如果命中可以直接從 Cache 裡面取資料進行計算，這樣的效率非常高，如果沒有找到（Cache miss），就需要通過匯流排（效率較低）去訪問主存甚至磁碟來載入資料，這種情況下對功耗、效能、延時影響都非常大，在做優化時必須重點考慮。
由此引出了 CPU 的優化方法。大體上分為程式碼級別、迴圈級別，記憶體級別，指令級別和執行緒級別。程式碼級別需要儘量減少記憶體的讀寫、儘量選用小的資料型別，還需要結構體對齊以及分枝優化。
迴圈級別常用的方法為迴圈展開，迴圈合併，迴圈拆分。記憶體級別主要遵循時間區域性性和空間區域性性原理，保證一次讀取資料可以為多條計算指令用到。
另外需要儘量減少記憶體的頻繁申請和釋放，以及保證對記憶體的連續訪問、對齊訪問、合併訪問、強制對齊載入、快取預取、記憶體複用等。指令級別要減少資料依賴、優化乘除法、充分利用系統暫存器資源、利用指令流水隱藏訪存和指令延時執行、SIMD 指令優化等。
關於 SIMD 指令優化，對於 ARM 有 NEON，對於 X86 有 SSE/AVX 等。所謂向量化，例如一個矩陣計算 A×B+C=D，用標量計算的話需要多次訪存和計算，但是如果使用向量計算，可以大幅減少訪存和計算次數。
在 CPU 的指令流水裡面，一條指令的執行需要經過取指、譯碼、執行和回寫幾個過程。可以在上一條指令取指完成開始譯碼的同時啟動下一條指令的取值操作，迴圈往復，通過這樣的方法不僅可以最大化 CPU 的吞吐量，還可以隱藏訪存和計算延時。執行緒級別的優化，包括資料分塊多執行緒、計算分支多執行緒以及非同步處理多執行緒。
編譯和彙編可以採用利用編譯器自動優化、內聯彙編或者手寫彙編等方式。CPU 繫結方面，如果經常在 CPU Core 之間切換會導致上下文切換頻繁，對效能的影響非常大，因此可以選擇性的繫結 Core 來提升效能。手機端存在大核和小核的區別，要根據需要繫結不同效能的核以得到最優的效能。
下面來看下 GPU 的軟硬體架構，伺服器 GPU 主要廠商是英偉達和 AMD，PC 端 GPU 主要是英特爾的 HD 系列以及 AMD 的 APU 系列以及 Radeon 系列。移動 GPU 主流的是高通驍龍 Adreno 系列、ARM 的 Mali 系列以及蘋果的 A 系列，Imagination PowerR 系列現在使用的相對較少。
GPU 軟體標準主要包括微軟的 DirectX 系列、Khronos Group 維護的 OpenGL、Vulkan、OpenGL ES、OpenCL 等、Apple 的 Metal、AMD 的 Mantle 以及 Intel 的 ONE API 等。
通過這張圖簡單瞭解 GPU 的軟硬體結構。在硬體層面分為主裝置和從裝置。主裝置一般來說是 CPU 端，從裝置一般來說是 GPU 端。這裡以 OpenCl 和 CUDA 為例來介紹下軟硬體層面的架構。
CUDA 的硬體層面主要包括多流處理器 SM、眾多的流處理器 SP 和一些暫存器等，Open CL 包含 CU 和 PE。從記憶體角度看，CPU 端主存，GPU 端視訊記憶體。視訊記憶體也分為全域性記憶體、常量記憶體、紋理記憶體、區域性記憶體和共享記憶體、私有記憶體等。從執行緒執行角度，CUDA 分為 Grid、Block、Thread 三個層次，OpenCL 分為 WorkGroup 和 WorkItem。
瞭解 GPU 的基本結構後，現在來介紹下 GPU 的優化方式。
程式碼級別，序列計算儘量使用 CPU，大量平行計算儘量使用 GPU。CPU 和 GPU 之間儘量採用非同步方式，減少直接互動，否則會受到訪存和 IO 的限制而影響效能。大規模順序的讀寫資料、單次 Load 多指令計算、使用向量化 load 和 store、減少除法運算、低位元量化和使用內建函式也可以劃歸程式碼級別優化的方法。
Kernel 級別優化方式包括根據 kernel 合理調整執行緒分組、用大量執行緒數隱藏指令執行延時和多次試驗確定最優 kernel 等。
執行緒級別的分組優化在 OpenCL 中可以由系統自動決定如何劃分 WorkGroup size。根據經驗通常也可以將 WorkGroup size 設定為 NDRange size 的因子或 2 的冪次方。保底的方法是 Auto-Tuning 找到最優分組方式。
CUDA 方面，SM 的配置會影響其所支援的執行緒塊和 warp 併發數量，另外，由於 warp 的大小一般為 32，所以 block 所含的 thread 的大小一般要設定為 32 的倍數。
記憶體級別優化，包括使用線性訪問和高區域性性的資料結構、優化資料排布最大化 Cache 利用率、最大化空間區域性性和時間區域性性、合併訪存、Zero Copy、Image 和 buffer 的區分使用等。
理論上，在高通驍龍系列中，Image-object 效能更優，ARM Mali 系列，Buffer-object 更有優勢，但這不是絕對的，可以提前試跑得到記憶體模式推理效能的更優者。另外要避免 bank 衝突、減少片外記憶體訪問，充分利用 Local Memory 以及資料的分片複用。
GPU 的資料塊片複用和 CPU 類似，適當增大資料分塊可以在計算複雜度不變的前提下，有效的降低資料記憶體訪問次數，對於提升效能有很重要的作用。
如何根據軟體特性設計更為輕量的運算元，我列出了以下 6 點：
第一， 運算量較小、並行度較低的模型適合 CPU 計算。
第二， 大量並行的模型適合 GPU 計算。
第三， 減少低計算量、無計算量和高訪存運算元的使用，可以採取和其他運算元融合的方法減少訪存次數。
第四， 避免使用不好並行的運算元。
第五， 卷積核不宜太大，必要時可用多個小卷積核替代。例如 1 個 5x5 可用 2 個 3x3 代替，引數量可以減少到原來 18/25；1 個 7×7 的卷積核可以用 3 個 3×3 的卷積核來代替，引數量可以減少為原來的 27/49。
第六， 通道數對齊要結合硬體和推理框架來調整。MNN 推理時資料一般是按照 NC4H4W4 組織，華為的 HiAI 對應的排布一般選擇 16 對齊。如果不瞭解這些框架的底層實現，就會造成計算資源的浪費。
對於深度學習來說，計算圖優化是十分核心的部分。這裡包括節點的替換、分支優化、子圖變換和運算元融合，其中運算元融合相對來說使用最多。右邊是卷積和 BN 融合的例子，從數學上可以通過公式推匯出 BN 可以和卷積完全融合，簡化成一個卷積來使用，從而減少推理階段的訪存和計算消耗。
下面另外一個例子，可以將多個 1x1 卷積合併，之後再進行 3 x3 和 5 x5 的卷積，由於最後的 concat 是純訪存操作，因此可以和卷積操作融合到一起，在記憶體釋放前同步完成 concat 操作。
卷積和矩陣乘法是使用頻率最高的兩個運算元。卷積有很多種實現方式，它可以採用滑窗的方式直接實現，通過迴圈展開、資料分塊多執行緒以及指令集並行等進行優化。還可以通過矩陣乘實現，但需要先進行 img2col 然後再進行矩陣乘法。
FFT 現在用到的比較少，FFT 適合大 kernel 的卷積，小 kernel 的卷積採取直接實現的方法會比 FFT 更快。Winograd 是現在用的比較多的一種優化方式，它的思路也很簡單，就是利用加法比乘法消耗的指令週期較短的優勢，儘量合併計算把一些常量算式提前計算好，並用加法代替乘法，以減少訪存和計算總量。
右邊是矩陣乘法的 Strassen 演算法優化方法，主要是對矩陣進行分塊計算，簡化掉很多乘法，再引入一個用於輔助計算的中間矩陣，使得計算量進一步降低。該演算法可以通過 7 次乘法和 18 次加法，將矩陣乘的演算法複雜度降低到了 。
這是演算法層面的優化，最終工程優化層面還需要從以下幾方面著手，包括迴圈優化、資料分塊和重排、增加資料複用度、減少 cache miss、向量化、浮點轉定點、低位元量化、多執行緒等。
整個演算法優化的過程大概如圖中所述，先設計好輕量化的演算法模型，然後進行軟體優化，包括各種前後處理所用到的 CV-Filter 和 Inference Engine 的優化，再往下就是需要各種平臺作業系統的適配，最後是硬體加速。
OpenCL 框架下首先需要建立很多個 kernel 將計算任務分發至各個硬體上執行，執行緒和指令的執行會通過佇列的方式來管理，這個佇列也存在一定優化策略，可以依賴 OpenCL 系統的最優化排程，也可以利用 OpenCL 提供的 flush 介面，在排程上加入人為的動態佇列重新整理機制來提高效能。
優化業務 pipline，減少 host 和 device 資料拷貝。關注效能瓶頸在訪存還是計算，確定之後再選擇優化策略。關注 CPU 大小核切換、降頻等的影響。關注業務流程或其他演算法對資源的搶佔。關注系統資源佔用率、功耗、音視訊卡頓率。異構裝置在優化時可以考慮進行計算效能 Pre-Tuning 來選擇最佳的計算方式。還可以藉助開源工具進行效能優化。
以上就是我關於演算法和軟硬體層面的優化方法的分享，下面我們來一起展望下未來。
四、未來展望
隨著音視訊技術的發展，人們的互動方式在逐漸進化，線上和線下、虛擬和現實會越來越緊密的融合。新的互動方式必然出現催生全新一代雲邊端一體、軟硬一體的實時音視訊處理架構。並且會對軟硬體的發展和演算法的優化提出了更低延時、更大算力、更低功耗的極致挑戰。
這是阿里雲視訊雲 “雲端一體” 的解決方案。考慮到端側裝置計算資源有限，將一些對算力和延時要求比較高的演算法可以放在雲端 GRTP 引擎進行處理和渲染，處理完成之後端上只需要做普通的渲染即可，真正做到端側 “零處理”。右邊是我們雲端一體實時換背景 + 構建虛擬主播 + 美聲變聲的視訊演示效果。
未來 AI、AR、VR、XR、元宇宙等對算力的要求會越來越高，單純依靠演算法和軟體優化本質上是有侷限性的，因此必須共同推動硬體的快速發展，真正開啟算力和效能的天花板。我們判斷未來需要雲邊端更加深度融合、通過軟硬一體的方案進一步降本增效，如此演算法才能真正賦能千行百業。
以上是我本次的分享，謝謝大家！
「視訊雲技術」你最值得關注的音視訊技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。公眾號後臺回覆【技術】可加入阿里雲視訊雲產品技術交流群，和業內大咖一起探討音視訊技術，獲取更多行業最新資訊。