作者 | 林晚
點選檢視視訊
大家好，我是來自阿裡巴巴淘系多媒體前端的潘佳，花名林晚，很榮幸能參加第十五屆D2給大家做一個分享交流。
目錄
今天給大家帶來的分享主題是《媒體智能-淘寶直播流媒體互動實踐》，内容分為5個部分，首先看看在淘寶直播的直播間裡主播可以怎樣給使用者拜年；然後具體講如何制作一個手勢拜年的特效；接着介紹我們媒體智能整體的方案設計以及其中核心的工作之一，MediaAI Studio這樣一款編輯器的實作；最後講講我們後續的建設方向。
直播間裡怎麼拜年？
馬上又要過年了，每次過年我們都會給親朋好友拜年。那在直播間裡，主播怎麼給使用者拜年呢？今年年初春節，我們做了一個項目，就是讓主播可以在直播間裡給自己的粉絲拜年，然後在直播間裡出一些春節的氛圍特效。
具體的設計方案就是主播在直播的過程中，實時識别主播的拜年手勢，來觸發一些春節氛圍特效的渲染，同時實時識别主播的臉部，來跟随渲染一些人臉道具。
可以看到上面的幾個效果示意，比如主播可以通過做一個愛心或者拜年的手勢，來觸發直播間的花字、對聯或者禮花，也可以給主播的面部加上财神帽等人臉道具，增強直播間裡的節日氛圍。
制作手勢拜年特效
那麼要在直播的過程中做到這些效果，需要怎麼來制作呢。接下來就詳細介紹如何在直播間裡制作這樣一個手勢拜年的特效。
大體上分為4個步驟，第一步是設計師通過一些設計軟體制作好靜态或動态的素材，比如财神帽及相關的微動效，傳遞物可以是一個序列幀動畫；第二步是設計師在我們自研的MAI編輯器裡制作完整的素材包，在這個編輯器裡可以做畫幅的适配、人臉識别跟随、設定手勢觸發條件，實時的本地效果預覽等；編輯好素材之後打包上傳到内容素材平台；最後是前台的使用，也就是我們的主播在推流端選擇開啟一些素材玩法包，然後推流的過程中實時識别和渲染合流，分發給使用者端觀看。
比如在編輯器裡設定識别一個手勢，來觸發特定的特效，大概的操作流程是這樣的：首先添加一個素材貼紙，上傳替換素材圖檔，可以是一個序列幀，然後調整貼紙的位置和大小，播放效果裡選擇觸發條件，通過拜年手勢觸發。怎麼看效果呢？在右側的預覽效果裡選擇我們預制好的視訊，就可以看到通過拜年手勢觸發了一個花字特效：
再比如我們想給主播戴一個财神帽，大概的操作流程是這樣的：首先還是添加素材貼紙，選擇财神帽的序列幀動畫，調整大小和位置，在跟随位置裡選擇跟随人臉的前額部位。預覽效果，選擇我們預制好的視訊，可以看到主播在點頭的時候，财神帽也會跟着移動，這樣就像是給主播戴上了帽子：
素材制作好之後，後面就是上傳、分發、使用，我們可以看看在直播間裡最終的實際效果：
媒體智能方案設計
前面我們介紹了一個單點的case，那我們定義的媒體智能流媒體玩法到底是什麼，接下來我們具體介紹下媒體智能整體的方案設計。我們再來看一個case：
直播間裡傳統的紅包雨互動，是在視訊流上蓋了一層普通的H5頁面，和流内容是割裂的；我們想做的媒體智能流媒體互動，是在視訊流中渲染素材，并且主播可以通過手勢來控制紅包雨的發放，将直播内容和互動深度結合，提升直播的互動率和停留時長。
我們定義的媒體智能，就是在直播和視訊流上，結合AI/AR玩法，形成新型的流媒體互動。作為前端，我們的目标是建構從生産到消費的媒體智能方案，同時形成工程化鍊路，将流媒體互動的生産周期提效至「7+3+1」的模式，即7天算法開發、3天玩法編寫、1天素材制作就可以上線一個全新的玩法。比如今年雙11花「7+3+1」開發一個全新的玩法，在明年的日常，我們隻需要1天制作新素材，或者花3天改一下玩法邏輯，就能變種出一個新的玩法。
接下來我們對方案進行了鍊路拆解，包括4個步驟，玩法生産、玩法管理、玩法使用和玩法展示。
生産者通過編輯器來生産玩法，通過素材平台來管理素材包，打通ALive平台做元件管理，主播通過多媒體生産端來使用玩法，在中控台做玩法配置和開啟，在推流端做玩法執行和合流輸出，同時通過SEI關鍵幀傳輸素材的位置、熱區等資訊，在直播間裡通過直播容器來監聽SEI和互動響應。
媒體智能的方案設計分為兩個方面，智能素材和互動玩法。智能素材是面向産品、營運和設計師的，提供一站式的智能素材制作平台，互動玩法是面向開發者的，提供一個支援代碼編寫、調試、預覽、部署的流媒體互動IDE。
什麼是智能素材，比如釘釘的Real如我，通過MediaAI Studio生産了大量的智能素材，給使用者拍攝場景提供了很多人臉道具；今年春節我們也生産了一些春節氛圍應用在直播場景，比如直播間頂部和底部的這些春節氛圍動效，以及通過識别主播的拜年手勢來觸發的特效。
智能素材的技術方案其實比較簡單，核心是約定了一套JSON協定的子產品配置，底層依托人臉檢測、手勢檢測、物體識别等算法能力，在配置層抽象出子產品，包括濾鏡、貼紙、美顔美型、文字模闆等，每個子產品會做一些配置，包括樣式、播放效果、動畫等等，最後在終端上進行素材下載下傳，完成配置解析，底層的渲染計算引擎根據配置做渲染計算，最後合流輸出。
下面是我們定義的子產品JSON配置的案例，可以看到裡面有編輯器版本、畫幅、子產品類型配置，以及素材的資源、位置大小資訊、播放設定、觸發設定、動畫設定等。
什麼是互動玩法，比如今年雙11在淘寶直播裡的一些案例，左邊是小米超大杯挑戰賽，可以看到主播通過身體來控制超大杯的移動，來接收螢幕上方掉落的道具，右邊是泡泡瑪特的出道挑戰賽，可以看到主播通過臉部來控制小人的運動，經過一些碰撞檢測可以獲得道具積分，來完成一些遊戲邏輯。
要在直播過程中實作這樣一套流媒體互動玩法，大緻的技術方案是這樣的。結合前面提到的紅包雨的case，我們做一下鍊路串聯。首先通過MediaAI Studio這樣一款編輯器來生成玩法素材和腳本，然後在ALive裡建立一個紅包雨元件并綁定玩法，主播通過中控台開啟玩法，推流端下載下傳、執行玩法腳本，把紅包素材合在流裡，使用者播放端通過流裡的SEI關鍵幀資訊擷取紅包的位置，在ALive元件裡消費這次互動，通過繪制熱區響應使用者操作。
編輯器 MediaAI Studio
前面多次提到了玩法編輯器，在媒體智能的鍊路裡我們的核心工作之一就是要建構一個玩法生産的編輯器。
基于Electron我們打造了MediaAI Studio這樣一個玩法生産的編輯器，底層依賴用戶端的跨平台渲染計算引擎RACE，RACE內建了算法推理架構MNN和算法平台PixelAI，提供了基礎的算法識别、渲染計算的能力。
Electron的主程序負責視窗管理、更新服務等，渲染程序裡負責子產品樹等一些工具和編輯面闆，以及實時渲染。同時渲染程序裡開了一個worker線程，負責和RACE的node子產品通信及一些圖像處理。功能層面提供了工程管理、素材制作、玩法開發、賬戶管理等功能。
我們把RACE的c子產品封裝成一個.node的c擴充，通過N-API的方式做一些畫幅解析、背景設定、渲染輸出等功能，通過JSBinding調用c++子產品實作js腳本能力。渲染部分會涉及大量的畫布像素交換和輸出，在渲染層抽象了worker層，包括背景更新、畫幅更新、子產品更新、Buffer更新等。worker和render之間是通過一些JSON協定和二進制的資料協定進行通信，來實作實時渲染的能力。
這是我們實作的編輯器效果，
從設計師視角可以生産智能素材，這裡用到了底部的固定貼紙、頭上的人臉貼紙，和手勢觸發的貼紙：
以及開發者視角可以在編輯器裡編寫玩法腳本，這個case裡是通過臉部識别來控制小鳥運動軌迹，來實作的一個智能互動：
後續建設
媒體智能我們也才剛開始探索，目前主要是工具視角，核心通過MediaAI Studio這款PC桌面端工具提供智能素材和互動玩法的生産，後續會更多的和平台打通，包括和算法平台、素材平台、釋出平台的打通，比如我們的互動玩法裡js腳本也需要符合前端安全生産的規範，是以在編輯器裡需要和釋出平台打通完成項目建立、調試、CR、釋出部署等能力。最後是基于工具和平台，提供設計師和ISV生态，甚至是商業化運作，快速擴充直播流媒體互動的體量、豐富玩法類型。
後記：D2直播QA
Q1: 前端在玩法特效這塊承擔了哪些工作（除素材編輯平台）
A1: 玩法鍊路主要分為4個環節：玩法生産、玩法管理、玩法使用、玩法展示。玩法生産的核心是MediaAI Studio這款編輯器，前端基于Electron打造的PC用戶端；玩法管理主要是ALive平台；玩法使用是主播推流工具，我們提供了PC和APP兩個場景的工具，其中PC推流工具我們也啟動了Electron項目，把推流能力和特效玩法兩部分更深度結合；玩法展示主要是直播間和短視訊裡的互動元件，這塊整體的開放技術方案也是前端主導的。是以在各個環節，前端都承擔了一些工作，其中生産、使用、展示環節前端承擔了比較核心的工作。
Q2: 特效檢測頻率如何選取？
A2: 推流本身的性能消耗比較大，包括音視訊采集、編碼、美顔濾鏡等等，是以在玩法特效的算法檢測部分，我們做了兩層頻率控制：一是整個玩法包的開啟和關閉，隻有當主播或助理明确開啟某個玩法時，才會做相應的算法檢測；二是不同的算法也有不同的檢測設定，算法内部也分檢測幀和跟随幀，來盡量減少玩法檢測的性能開銷。
Q3: 識别、合流分别在哪個端實作的? 流用的是什麼技術和協定？
A3: 識别、合流目前都是在主播推流端實作的，包括PC和APP。流就是傳統的直播技術和協定，推流rtmp、拉流hls和http-flv。
Q4: 直播有延遲，合流是否會增加延時？怎麼保障推流畫面和使用者互動之間的資料延遲？
A4: 合流不會增加直播延時，如果算法執行太慢，一幀處理不完，會導緻直播幀率變低，對于使用者體感就是畫面變卡。這裡問的使用者互動我了解是C端使用者的互動，一般C端使用者的互動和響應都是在C端完成的，目前沒有碰到C端使用者互動後還需要推流端實時響應的case。如果是答題這類對流畫面和内容同步度要求很高的場景，我們會通過SEI+CDN的方案來保障畫面和資料的同步。
Q5: 能推薦下手勢監聽的開源庫嗎？
A5: Google Research 開源的MediaPipe
https://github.com/google/mediapipeQ6: 識别會不會顯著增加前端包的大小？
A6: 不會，前端包的大小主要是素材資源和js腳本，算法模型和識别能力是在端側的，不會打到前端的包裡。
Q7: 編輯器裡的算法部分具體是用什麼實作的？TFjs嗎？
A7: 不是TFjs，算法的能力是MNN推理架構和PIXAI算法平台的能力，跨平台渲染計算架構RACE內建的也是這部分的能力。
Q8: 紅包雨中，紅包位置是不是随機的嗎？如何預定義熱區呢？
A8: 是随機的，推流端腳本執行後将紅包繪制的位置、大小、形變等資訊通過SEI關鍵幀傳到播放端，播放端經過SEI解析後，前端還原出相應的熱區，來響應使用者操作事件。
Q9: 遊戲部分的代碼執行效率如何保證？
A9: 目前遊戲部分是将RACE c++代碼通過jsbinding的方式供js調用，遊戲畫面由用戶端進行渲染，而且RACE底層會做JS調用優化機制，是以執行效率上接近原生。但是目前提供的api較少，随着業務複雜度越來越高，遊戲的開發效率倒是成了瓶頸，接下來我們在考慮通過RACE canvas提供的WebGL協定接口，适配淘内主流H5遊戲引擎，借助H5遊戲完善的互動能力和引擎生态，再結合多媒體互動特有api，進行流媒體互動開發，實作一次開發，多渲染引擎運作。
最後感謝D2！也歡迎對多媒體前端領域感興趣的同學和我取得聯系，一起學習、交流、探讨。郵箱：[email protected]、微信：Jovenpan
🔥第十五屆 D2 前端技術論壇 PPT 集合已放出，馬上擷取
關注「Alibaba F2E」
回複 「PPT」一鍵擷取大會完整PPT