【hackathon】OneMoreFace做品小計

時間 2019-11-10

標籤 hackathon onemoreface 小計简体版

原文原文鏈接

本文首發我的博客 blog.eastpiger.com。SF留檔。前端

例行廢話

1024那天，應wph的邀（guai）約（pian）帶着小夥伴們一行七人到杭州參加SegmentFault Hackathon。這是我第一次參加這種活動，估計他們六個也是。幸虧半路抓來了一個同校研究僧學長墊背。學長是參加過相似比賽的，好歹能帶帶咱們。當時是這麼想的——最後事情也就是這麼發展的。git

Hackathon的主題是「科技改變生活」，通過咱們的討論，咱們一致認爲，這個題目並無什麼卵用。固然也不是徹底沒有用處，好歹指導咱們把腦洞開向了一個詞「吃喝玩（piao）樂（du）」。github

因此，OneMoreFace項目就這麼誕生了。canvas

Describe

咱們官方提交的項目說明是這樣的：後端

基於面部識別和 WebRTC 的多人同步匿名娛樂聊天服務。提供多人同時在線，文本發送，視頻識別覆蓋個性化數字面具等功能。本項目使用了 clmtrackr 項目和實時貓 WebRTC 大廳服務。安全

其實他是這樣的服務器

本項目的目的在於在現有的匿名交（yue）友（pao）平臺之上，添加一種既能保證安全性和隱私性，又能像面對面溝通同樣能夠準確傳達表情和情感的技術手段。也就是說，數字換臉，順帶同步真實表情的效果。網絡

技術關鍵詞

兩個實現關鍵點：session

在線視頻通信app
圖像處理

對應了兩個咱們最終選擇的技術手段：

WebRTC
開源項目clmtrackr

前者是Google提出的在線流媒體傳輸的框架，這個技術目前應該仍是Draft狀態，不過基本功能Webkit等一干內核應該都支持得能夠（因而咱們就被坑了……）

後者是學長推薦給咱們的一我的臉定點識別的開源框架，這個框架實際上已經作好了很大一部分人臉識別以及三維建模的工做，甚至已經提供了換臉這個基本demo的樣式，對於時間要求比較緊的咱們來講確實頗有用處。

實現流程

面部處理交給scientist和makeapp作去了，表示並不知道他們作了什麼……

我主要是作二者的結合工做，一來是先調通WebRTC流通信，二來是接入咱們面部的處理工做，最後爭取讓整個項目看起來還像是那麼回事。

調WebRTC其實蠻簡單，咱們直接調用了實時貓的技術就實現了雙人對通的效果。因爲後面的一些情況，我實際上在現場把實時貓的代碼反混淆以後差很少從新讀了一遍了，總體感受他的前端API差很少就是WebRTC上封裝了簡單地一層，實際上的這種封裝和直接調用WebRTC進行通信沒多大差異。固然咱們看中他的緣由也是有的，好比指望直接拿他的Demo代碼修改修改就能夠運行，雖然過後證實咱們想多了……不過使用實時貓也爲咱們提供了一些方便，不用單獨去部署後端服務，Session和Token的機制實時貓都已經作好了，這在當時那種【時間短】【網絡不穩定】【我懶】的特殊狀況下仍是很是有用的。

實時貓官方給的Demo仍是0.1版本的，很是不穩定和不許確，他給的多用戶鏈接甚至是手工建立兩個頁面手工寫入Token來實現的。而圖像的Stream則直接來自於MediaDevices.getUserMedia()函數，並簡單粗暴的輸出到LocalVideo標籤。clmtrackr那邊也並不順利，他的Demo代碼兼容性實際上能夠認爲就是沒有……對多圖同步處理毫無辦法，也與WebRTC很難接入。

基於上述的問題，我繼承了在中科院無線中心實習的時候練就的一項粗暴的思路，勞資重構一個數據類型幹掉他╭(′▽`)╯

構造一個數據類型Clmtrackr，內部仿照Clmtrackr的面部模擬Demo封裝了面部替換的構建邏輯，堅決地向着鬆耦合的方向邁步，也就爲了最終可以實現多視頻獨立處理提供了先決條件了。

以後即是在實時貓的Demo代碼之上作修改，先是用Clmtrackr類替代了localStream.play("localMediaContainer");這句本地播放的語句，其次基本從新修改了「stream-subscribed」的event函數。

接下來就畫畫前端咯，加一下msgstream的功能咯，而後就哈哈哈哈得作完咯……

而後咱們就如願以償的掛了……

主要的難點有幾個，首先，是根據咱們的想法，確定是要作好私密性爲上，那麼最基本的想法就是客戶端將本身的視頻數據識別處理以後再廣播出去。這樣咱們就須要HTMLCanvasElement.captureStream()這個函數幫助咱們將canvas轉換到tream以後發給廣播。然而……特麼這個函數竟然都是Not supported……

最終的解決方案其實是咱們特別特別不爽的，也就是實際發送的是每一個人的攝像頭獲取的原始圖像，廣播出去後接受方在本地進行匹配和識別。這致使了嚴重的性能問題、沒法承擔過多人數同時在線、瘋狂的內存泄露.

第一個問題致使咱們卡了兩個多小時，甚至一度準備更換方向。然然後面這個更是一個大坑，簡單來講，就是實時貓的「stream-message-received」事件收不到數據，一開始我覺得是發送函數有問題，又懷疑是網絡問題，還懷疑是否是必須單獨去開messagestream來傳輸數據，所有無效。也就促成我直接去擼實時貓的前端SDK源代碼去了~>_<~