來源：Alibaba F2E
作者：林晚
随着B站、抖音、快手、淘寶直播等直播視訊平台的快速崛起，前端衍生出了多媒體技術方向，各公司的傳統前端團隊裡陸續出現了一支新軍：Web多媒體團隊。光看團隊Title，這應該是一個擁有前端×多媒體交叉領域稀有技能的群體。阿裡巴巴内部也存在衆多Web多媒體團隊，在内部我們針對新人整理了一份多媒體前端技術入門指南，今天将這份入門指南也對外分享出來，讓大家了解我們近幾年在該領域有哪些方向的工作，有哪些實踐和落地，本文将從以下幾個方面帶着大家一窺究竟：
- 什麼是多媒體前端？
- W3C标準的媒體技術
- 播放場景和解決方案
- 面向消費：直播視訊裡的業務體系
- 面向生産：直播推流、視訊剪輯等工具
- 阿裡巴巴前端委員會多媒體方向的發展和規劃
利用專業的前端能力，解決多媒體場景下各類技術和業務問題的前端，稱之為多媒體前端。目前的多媒體前端主要從兩類人群轉化而來，一類是學數字媒體專業後從事前端開發的，一類是專業做前端後再學習多媒體的。這是兩個成熟的知識體系交叉碰撞後的一個新的工作領域，需要具備高度還原、體驗把控、跨端、工程化等前端開發能力，又要具有音視訊基礎、流媒體協定、播放技術、Web媒體技術等多媒體能力，目前這類人才的缺口還非常大。
W3C 标準的媒體技術
最開始接觸多媒體前端開發，一般場景比較簡單，比如在網頁上播放一個視訊/音頻，實作基礎的播放控制（播放、暫停、進度條、音量大小、靜音等）。在HTML5标準之前如果要在浏覽器裡播放視訊内容，需要使用Adobe Flash或微軟的Silverlight等插件，但是插件存在需要使用者安裝的不便捷和不安全等問題，是以W3C的HTML5标準中定義了一系列新的媒體元素來避免使用插件。以下是媒體開發者常用的HTML元素:
HTML元素
- <
video
-
audio
-
source
audio
video
-
track
audio
video
浏覽器提供的媒體播放功能都是相當簡單的，一個 video 或者 audio 标簽再加上src就搞定了，但這缺少了諸如視訊分段加載、視訊碼率切換、部分加載、記憶體管理等現代播放器應該有的功能，需要更定制化的播放需求，或者更豐富的多媒體應用，就要使用媒體API：
媒體API
- 媒體源擴充API
MSE (Media Source Extension) 擴充了浏覽器的媒體播放功能，允許用JS動态構造媒體流MediaSource對象，然後喂給<
video
>和<
audio
>标簽進行更精細化的播放控制。也可以用JS把一些不支援的視訊流格式轉封裝為支援的格式，B站開源的flv.js就是這個技術的一個典型實作，使用MSE技術将FLV源用JS實時轉封裝成HTML5支援的視訊格式。更多資訊會在下一節播放場景和解決方案中介紹。
- 網絡音頻 API
Web Audio API 用于處理和合成Web應用程式中的音頻，允許開發者進行聲音合成、添加音頻特效、音頻可視化等，使用Web Audio API 我們幾乎可以完成一個專業的Web音頻處理軟體（如節拍器、調音器等）。
- 媒體捕獲和流媒體API
Media Stream API 讓開發者可以使用本地攝像頭和麥克風來采集錄制音視訊，或者捕獲電腦螢幕，或者讀取本地視訊做合成，常用于Web攝像頭、拍照、錄屏、視訊通話等，下文視訊剪輯章節也有1688使用該技術實作web視訊剪輯的案例。MediaStream 是連接配接 WebRTC API 和底層實體流的中間層，WebRTC将音視訊經過Vocie / Video engine進行處理後，再通過MediaStream API暴露給上層使用。
- WebRTC
WebRTC 是一套支援浏覽器進行實時音視訊對話的 W3C Javascript API，它包括了音視訊的采集、編解碼、網絡傳輸、顯示等功能，使網際網路上任意兩位使用者在無需伺服器的情況下實作實時的音頻、視訊和任意資料的通信。在2010年左右，實時通信隻能使用專有軟體、插件或Adobe Flash進行；2013年，Chrome 和 Firefox 之間進行了首次跨浏覽器視訊通話，開啟浏覽器之間無插件化的音視訊通話的序幕。現在WebRTC的使用場景非常豐富，在音視訊通信、直播推流、雲剪輯、雲遊戲等場景都可以看到WebRTC的使用。
除了這些媒體API，還有一些技術通常與媒體API共同使用：
與媒體 API 共同使用的技術
- Canvas API
Canvas API 允許在 <
canvas
> 上繪畫、操縱并改變圖像内容。這樣可以與媒體以多種方式使用，包括設定 <
canvas
> 元素作為視訊播放或攝像頭捕獲的節點以捕獲或操縱視訊幀。
- WebGL
WebGL 在已存在的 Canvas API 上提供了與 OpenGL ES 相容的 API，使得在 Web 上制作強大的 3D 圖像成為可能。通過一張畫布，用于為媒體内容添加 3D 圖像。
- WebVR
Web Virtual Reality API 支援虛拟現實 (VR) 裝置，使開發人員能夠将使用者的位置和移動轉換為 3D 場景中的移動，然後在裝置上顯示。WebVR 有望逐漸被 WebXR 所取代，後者涵蓋了更廣泛的用例。
- WebXR
WebXR 旨在最終取代 WebVR，是一種支援建立虛拟現實 (VR) 和增強現實 (AR) 内容的技術。混合現實内容可以顯示在裝置的螢幕上，或者是顯示在眼鏡或耳機内。
前文提到浏覽器裡通過<
video
>就能實作視訊播放了，那還需要我們前端做些什麼呢？其實<
video
>也存在很多限制，我們要先從媒體内容的封裝格式和編碼格式說起。
媒體内容源檔案都是比較大的，為了便于傳輸和存儲，需要對原視訊檔案通過編碼來壓縮檔案大小，再通過容器封裝将壓縮後的視音頻、字幕組合到一個容器内，這就是 編碼 和 容器封裝 的過程（可以用 壓縮餅幹 和 封袋包裝 來了解，會出現很多不同的壓縮工藝和包裝規格）。
那麼在播放端進行播放時，就要進行相應的 解封裝 和 解碼 （先拆開包裝拿出餅幹，享用餅幹可以直接吃、也可以碾碎了吃、也可以泡着牛奶吃）。浏覽器自帶的播放器<
video
>标簽擁有解封裝和解碼功能，但對媒體内容的格式是有所限制的（浏覽器隻會拆開特定的包裝方式，隻能消化特定的餅幹吃法）。那浏覽器碰到“不會拆、不消化的餅幹”，我們要怎麼喂給<
video
>呢？
除了容器格式、編碼格式，還有流媒體協定、渲染容器、多執行個體播放等等問題需要多媒體前端一一解決，下面來分别介紹：
多協定、多容器格式
随着流媒體業務發展，出現了很多新的傳輸協定，媒體内容進一步包含在一層傳輸協定中（以HLS協定為例，增加了m3u8索引檔案，并将源檔案内容分片後封裝到了一個個 TS 容器格式中），這樣<
video
>就無法識别了。要支援多協定、多容器格式的播放，開發者可以通過 MSE 來幫助浏覽器識别并處理，将媒體内容 轉封裝 成可識别的容器格式（如MP4），這樣<
video
>就可以識别并播放各種媒體内容了。
上文提到的B站的flv.js以及社群的hls.js都是利用 MSE 來解決多協定、多容器格式的播放器庫。
- flv.js
flv.js是Bilibili網站開源的HTML5 flv播放器，基于HTTP-FLV流媒體協定，通過純JS實作FLV轉封裝，使flv格式檔案能在Web上進行播放。
但是flv.js也不是所有的flv格式視訊都能播放，并且對浏覽器環境也有一定的要求，以下是flv.js的使用限制:
- 視訊必須是AVC（H.264）編碼，音頻必須為AAC或者MP3編碼
- 浏覽器環境必須支援MSE，檢視支援清單： https://caniuse.com/#feat=mediasource ，值得注意的是，ie浏覽器中，ie11以上才能正常使用，而ie11浏覽器必須在win8系統以上才能運作；移動端上，ios僅支援在iPadOS 13以上系統，ios手機端完全不可運作；android則要求4.4以上系統
- 浏覽器必須支援video，fetch api、xhr和websocket支援其一便可
- hls.js
hls.js是基于Http Live Stream協定開發，利用Media Source Extension，用于實作HLS在web上播放的一款js播放庫。
由于HLS協定由蘋果提出，并且在移動端裝置上廣泛支援，是以可以被廣泛應用于直播場景。而hls.js在pc端隻需要支援MSE便可以應用，移動端使用原生video标簽設定src便可完成播放。hls.js會先請求m3u8檔案，然後讀取到檔案的分片清單，以及視訊的編碼格式、時長等。随後會按照順序去對TS分片進行請求，然後借助MSE将二進制buffer内容進行合流，組成一個可播的媒體資源檔案。
阿裡内部也有多個團隊有類似播放器産品，如阿裡雲的Aliplayer、淘系的VideoX、優酷的KPlayer，實作思路都基本一緻。
- 阿裡雲 Aliplayer
Aliplayer 經過幾個版本的疊代演進，整個架構更加合理，賦予本身和使用者更多的擴充能力，具有獨立增加播放類型和功能的能力，比如要h5支援flv的播放能力，隻需要新增Flv Extend功能擴充子產品，而不用修改其他子產品的代碼，比如HLS Extend等等，確定不影響其他功能的正常工作，保持每個版本釋出的穩定性。
- 淘系 VideoX
Videox 底層的播放層也經曆了幾次變化，從最開始簡單的 <
video
>标簽，到通過MSE來擴充各種格式的<
video
>标簽，到通過WebAssembly來對編解碼格式進行擴充的<
canvas
> + Web Audio API的方式，未來可能還有底層通信的擴充及上層互動能力的增強。
- 優酷 KPlayer
KPlayer 目前的方案拆分的較細，包括多個庫群組件，主要有KMux 轉封裝庫、KDRM WebDRM插件、KCTRL 播放器控制行為的核心抽象、MediaEngine 解碼&渲染&播放的核心抽象、KUI 嵌入式UI架構。KPlayer播放核心設計如下：
多編碼格式
上一小節解決了浏覽器<
video
>不支援的協定和格式(不會拆餅幹包裝)的問題，那遇到不支援的編碼格式(不能消化的壓縮工藝)該怎麼辦呢？
新的視訊編碼标準H.265、AV1等比傳統H.264擁有更高壓縮率，但浏覽器<
video
>本身并不支援，而業務為了降低成本都全鍊路切換新的編碼格式如H.265，那多媒體前端就要自己實作浏覽器端的JS播放器。由于Javascript是一種動态解釋型語言，性能比C++等語言差很多，處理多媒體資料時性能短闆就展現出來，WebAssembly的出現解決了Javascript的性能短闆，極大擴充浏覽器端的多媒體處理能力和場景。
對于Web端H.265播放器，阿裡内部有多個團隊都進行了相應的嘗試，包括優酷、阿裡雲、淘系、ICBU等，思路基本一緻，都是通過FFmpeg + Webassembly來實作一個JS播放器，使用JS拉流、解封裝，将FFmpeg的265解碼能力編譯成wasm子產品供JS調用，視訊經過FFmpeg解碼出來YUV幀資料，通過WebGL繪制圖像幀資料，而音頻方面因為浏覽器支援AAC、MP3等主流音頻格式，音頻資料直接通過Web Audio API進行播放。設計思路如下：
多渲染容器
上面描述的場景主要是PC的Web浏覽器，但我們更多的業務場景在移動端，面向消費者的場景對播放的體驗和性能要求非常高，于是引入了播放器的跨端支援問題，尤其是跨渲染容器（Webview/Weex/小程式）。端側的播放器主要使用Native播放器，前端封裝成Weex/同層渲染元件，在各渲染容器中運作。
在端側如果采用原生video方案，存在相容性及性能問題，播放器本身占用記憶體高，業務不規範使用會帶來穩定性風險，甚至導緻APP Crash。以端内H5為例，采用的是和Rax團隊、用戶端基礎團隊、用戶端播放器團隊一起打造的同層渲染方案：
- Native播放器：負責播放器的基礎能力，播放器核心fetch流位址後，解封裝(demux)後解碼(decode)，然後輸出到上層Naitve同層元件層，Native播放器提供了點播/直播能力
- Native同層元件：為底層播放器執行個體封裝，主要負責聯通通信連接配接層，并控制渲染
- 通信連接配接層：通過windmix管理渲染通道，再通過windvane綁定事件，傳遞屬性，api能力調動，連接配接到前端播放器
- 前端播放器核心：擔任前端播放器輸出，将下層提供的事件/api/屬性抹平成W3C制定的播放器标準，同時負責播放器穩定性相關能力
- 業務播放器封裝：對下層的前端播放器核心封裝播控協定，通過事件中心，管理各個播放器播放能力；同時從業務角度出發，對網絡和裝置性能進行監測，判斷是否降級
多執行個體控制
前面提到的都是單個視訊播放的場景，實際業務中還有同一個頁面中多個播放器的場景，比如清單流、版頭等，這時候就引入了播放器多執行個體控制的問題，需要保證頁面内隻有一個播放器播放（播放甜區）、記憶體管理等。
播放器需要具備強大的播控能力，即播放排程能力：
- 事件中心驅動
- 播放器内部維護一份待播放隊列，由rax-view的onAppear和onDisappear實作，當執行onAppear時，待播放隊列将對應播放器唯一id存入到隊列中，當對應播放器執行onDisappear時，從隊列中剔除
- 隊列中的播放形式主要分為3種：1，滾動播放；2，指定id播放；3，onAppear場景播放；均由事件管控。再由事件中心分發到不同播放器，告知哪個播放器可播放，哪個不可播放
- 播放器存在于pcom庫，無論是對于會場場景或是源碼開發場景，均可保證事件中心通知到所有播放器
2.播控排程
- 播放器執行個體記憶體占用大概在20-40MB，對于一個H5頁面來說，記憶體占用過高，極容易引發頁面記憶體占用過大，導緻crash等嚴重問題。是以在事件驅動播放同時，事件中心會保證有且僅有一個播放器執行個體正在播放
前面提到的都是單純的播放功能，但實際的業務場景是直播間或者短視訊全屏頁，從播放器到直播間/短視訊，還有很重要的一個部分就是使用者互動層，這就引入了直播視訊裡的業務體系。
以直播為例，對于觀衆有兩個訴求：觀看直播、參與互動。一般直播的設計如下：
通常的直播間架構分為三種：Web直播間、Hybrid直播間、小程式直播間，比如釘釘公開課直播采用的是Web直播間架構，螞蟻、天貓精靈等采用的是小程式直播間架構，其他絕大多數的業務采用的是Hybrid直播間架構。
Web 直播間架構
純Web直播間，是指主要運作在Web浏覽器上的H5直播間，主要包括H5播放器、事件通道、UI元件等。但移動端浏覽器相容性較差，移動端播放延時較高，是以一般對體驗和性能要求高的業務場景，都會選擇Hybrid直播間架構。
Hybrid直播間使用原生的播放器能力，相容性更好，體驗更流暢；同時事件通道是Native通道，相對于Web直播間 websocket更安全。
Hybrid 直播間架構
Hybrid直播間的宿主是Native，使用原生播放器，互動玩法是在播放器上面蓋了一層互動層（Webview或WEEX容器），并且能夠和播放器通信。
Hybrid架構中互動層方案也經曆了幾個階段的演變，從最開始的每個玩法元件一個獨立層，到所有玩法元件打包到一個層，再到定義出直播容器來動态加載元件：
直播容器具有以下幾個特征：
- 統一規範的元件消息協定：包括元件包名、元件行為、業務自定義字段等
- 支援動态加載：直播間不同于其他詳情頁，互動的發送依賴主播操作，也依賴使用者進入直播間的時機，每個使用者參與到的互動可能都不一樣，是以互動元件的動态加載對首屏性能很關鍵
- 緩存及依賴去重：同一個互動，主播可以多次推送，各個互動依賴的基礎庫（rax-xxx、universal-xxx）也存在較多重複，是以設計合理的緩存和依賴去重機制對性能提升也很重要
- HOC高階元件：直播間裡的業務開發不同于其他獨立的源碼頁面，比如直播間資料擷取、消息和事件監聽、橫豎屏狀态擷取、帶小窗跳轉、直播觀看時長等等都依賴直播間環境或者用戶端API，業務元件都需要這些基礎能力，需要通過HOC來增強業務元件
在Hybrid架構下開發調試元件，需要一個完整的直播間環境和直播容器才能開發調試，沒有配套的工程體系，元件開發很低效。是以這種架構下還需要配套的工程體系，主要包含以下幾個部分：
- def 套件：直播間元件開發腳手架，增強調試能力，包括直播間模拟、調試代理、熱更新、編譯檢測等功能
- 直播間 Debug 工具：基于直播容器開發一個Debug元件，提供日志調試、容器化API調用、資料Mock、消息Mock等功能
- VS Code 插件：直播間Debug工具在PC端的同等方案，結合模拟器可以獨立在PC端開發調試
多媒體前端團隊通過打造直播容器和工程體系，才能高效、穩定的建構出直播視訊裡的業務體系。
當然Hybrid架構因為其聯合Native和前端帶來了架構上的複雜度，特别是在直播和視訊上下滑時直播間的狀态管理、播放器執行個體和webview執行個體管理等，會導緻一些狀态問題，比如某直播平台曾出現過“神奇三串”bug：薇娅 直播間裡播放的是 李佳琦 的直播流，但展示的是 葉一茜 的商品：
基于Hybrid架構我們可以考慮進一步更新，讓播放器和互動層更加融合，形成「超級Video」，或者叫可互動的Video方案，甚至定義新的 <
video
> 标準。
小程式直播間架構
随着跨端業務的出現，尤其是跨APP的場景，Hybrid直播間架構就像個大胖子，天然沒有跨端優勢（用戶端內建、維護SDK成本極高），在這個背景下小程式直播間架構出現了。小程式直播間設計上分為以下幾層：
- 直播插件：插件裡除了包含最基本的播放器、無限清單、官方元件，還封裝了元件布局規則、事件中心、容器api子產品等基礎能力
- 跨端通信層：由于插件和小程式宿主執行個體之間的js上下文完全隔離，是以@alipay/armer-x借助了appx對特定函數的聲明不做序列化的特性進行了插件和宿主小程式之間的通信橋接，如給插件
- 賦予函數onConnectEmitter，在appx裡是不做會做序列化的，是以資料可以通過該函數給予插件通知資訊
- 小程式元件：二方、三方定制的小程式元件，滿足特定的接入規則就可以借助直播間的容器能力進行定制
- 小程式執行個體：在擁有了二方元件、直播插件後，我們可以将二者進行整合、打包建構，生成一個新的小程式執行個體，執行個體的生成方式可以通過IDE建構，也可以通過搭建平台，如：「閃蝶」，目前的政策是支付寶側通過閃蝶的方式建構生成執行個體，而百川側，則通過IDE上傳，并且借助淘寶開發平台進行百川投放
由螞蟻和淘寶直播聯合打造的小程式直播方案，在多個APP端（包括外部媒體APP）得到了廣泛應用。
前面提到的更多的是面向消費側的場景，随着業務的發展，各個多媒體團隊開始更加關注生産側的能力建設，畢竟内容的生産是整個内容生态的血液供給。作為開發者，需要給商家、主播、達人等創作者提供高效、好用的生産工具。在生産側主要有兩個方向，一個是面向直播的直播推流工具，一個是面向視訊的視訊剪輯工具。
直播推流
直播推流前端主要有兩種方案:
- 桌面用戶端：采用Electron + OBS方案（OBS是一個用于錄制和進行網絡直播的自由開源軟體包，OBS使用C和C++語音編寫，提供實時源和裝置捕獲、場景組成、編碼、錄制和廣播等）。在設計上，OBS不負責業務功能，僅作為一個純推流SDK。通過IPC通信将OBS的接口封裝成V8的接口，再通過CMake或者GYP打包成Node子產品供前端調用。播放區域（大小、padding等）、元素的互動行為（旋轉、縮放等）、推流參數等全部封裝成接口暴露給前端。整個APP為Electron中的一個BrowerView，采用React支撐視圖，Mobx管理資料，跨頁面通信以及相應的資料流轉、緩存和視窗管理都由Electron主程序進行管理，前端通過将webview視窗句柄提供給OBS程序來保證推流畫面的流暢顯示
淘寶直播主播工作台 和 1688直播伴侶 都是采用的這個方案:
- Web浏覽器端：采用WebRTC方案，相對于桌面端推流清晰度低、性能吃緊。比如融媒體團隊由于業務特性，不能使用第三方的OBS開源軟體，選擇了該方案，産出了PC網頁采集推流混流SDK，支援攝像頭、電腦畫面和墊片推流
視訊剪輯
相對于直播的生産，視訊的生産覆寫度更廣，參與到這個方向建設的團隊也更多，包括阿裡媽媽、淘系、盒馬、1688、阿裡小蜜、螞蟻等。生産文章内容需要用富文本編輯器，那生産視訊内容就需要視訊剪輯工具，當然這兩者的複雜度是完全不一樣的。我們打造或智能生産、或高效好用的深度剪輯工具，都是期望降低生産成本，能像編輯文章一樣友善地剪輯視訊。
傳統的桌面剪輯軟體是提供一個GUI界面，給使用者提供所見既所得的編輯效果回報，并在編輯完成之後産生編輯描述資料，最後交由圖形圖像子產品、音頻處理子產品以及視訊編碼子產品去生成最終視訊檔案。參考大部分開源剪輯軟體實作，前半部分GUI通過作業系統圖形界面或跨平台如QT、SDL、SWT方式實作，這部分我們稱之為 “GUI前端”，而後面涉及圖形圖像、音頻、編碼相關部分，大部分都會有一套媒體編輯核心來支撐，例如Linux下著名的MLT、GStreamer等等，這裡我們稱之為 “編輯核心”。
基于以上 GUI前端 + 編輯核心 的思路之下，多媒體前端在剪輯工具上通常有以下幾種實作方案：
- 桌面端剪輯：Electron方案，GUI前端在Webview，編輯核心在Native，打包成Node子產品供前端調用（和上述Electron直播推流類似）。采用該方案的有淘系的Marvel剪輯工具，用于親拍業務
- 純Web剪輯：浏覽器方案，GUI前端和編輯核心都在浏覽器。編輯核心提供的編輯、渲染、合成等能力通過 Media Stream API 或 者 FFmepg + WebAssembly 來實作。采用該方案的有1688視訊編輯器(幻雀）、阿裡小蜜的小蜜視訊創作工具，以小蜜的方案為例：
- Web雲剪輯：浏覽器+服務端方案，GUI前端在浏覽器，編輯核心在服務端。因為GUI前端和編輯核心分開在兩端，是以還需要解決GUI如何呈現編輯核心内容的問題。通常有浏覽器主動拉取渲染效果和WebRTC直播串流推給使用者界面兩種方案，後者的延時較低，體驗更好。采用雲剪輯方案的有阿裡媽媽的Aliwood、盒馬的盒作社視訊編輯器、淘系的PC淘拍、螞蟻的FMS短視訊生産工具，以Aliwood的方案為例：
但目前采用Web雲剪輯都是浏覽器主動拉取渲染效果的方案，筆者還沒有看到WebRTC的方案（類似雲遊戲），目前淘系正在建設WebRTC的雲剪輯方案。
玩法生産
除了直播推流和視訊剪輯，還有結合流媒體識别的玩法生産，比如人臉檢測、手勢檢測、物體識别等疊加濾鏡、貼紙、美顔美型、文字等特效，實作直播和視訊的媒體智能玩法。外界有Facebook的AR Studio、Snapchat的Lens Studio、抖音的Effect Creator，内部有淘系的MAI(MediaAI Studio)，廣泛應用于淘寶直播、逛逛等業務。
随着近幾年多媒體業務發展，阿裡巴巴集團内已經有較多的多媒體前端團隊，包括Lazada、CBU 1688、ICBU、阿裡媽媽、阿裡雲、本地生活、阿裡學習、菜鳥、融媒體、螞蟻、優酷、來瘋、淘寶直播、釘釘等。随着音視訊廣泛運用和硬體更新，前端委員會今年把多媒體領域作為了面向未來布局和突破的方向之一，開始布局Web标準下的多媒體領域。
我們摸底了阿裡集團各個BU多媒體技術團隊現狀，包括主要的業務場景、面臨的主要問題、可以向經濟體輸出的技術方案、對前端委員會多媒體方向的訴求等，根據摸底資訊，确定了優先級較高的Web視訊剪輯和播放的方向建設，我們的目标是：深入多媒體行業，拉通集團 Web 多媒體技術，建立先進的Web視訊剪輯和播放解決方案，布局至少一個具有前瞻性的多媒體技術方向（如WebXR相關）。
如有疑問，歡迎與我交流，微信号：JovenPan。