--------點選螢幕右側或者螢幕底部“+訂閱”，關注我，随時分享機器智能最新行業動态及技術幹貨----------
如果你在追劇時喜歡看彈幕、發彈幕，那你一定知道有些劇裡彈幕甚至比劇情還要精彩，比如上過熱搜的出自《東宮》的那一句“談戀愛嗎？滅你全族的那種”。正是由于這些神一般的網友頻頻曝出精句，讓某些劇集精彩程度翻了幾倍，甚至有大量網友來追劇是被彈幕吸引來的。
喜歡用優酷看視訊發彈幕的同學應該已經發現，最新版本上很多劇都上線了全新的基于 AI 人臉識别的跟随彈幕，以往的普通彈幕或進階彈幕都是在播放器頂端自右向左以跑馬燈式的效果展示，而這種跟随彈幕是以氣泡樣式挂在人物頭像旁邊，随着人物移動而移動。這種跟随彈幕可玩性更高，有才網友可發揮餘地更大，下面就列舉幾個例子。
結合人物動作的玩法：
從幾個視訊 demo 中可以看出，相比普通彈幕，這種跟随彈幕是以一種類似劇中人物的内心 OS 的方式展示出來的，與視訊無割離感，更有趣更新穎更精彩，有更多玩法。
本文主要講訴一下跟随彈幕是如何展示的，從構架圖開始講解實作流程；再由開發過程中遇到的棘手問題，分享技術政策；最後分享未來規劃。
一、跟随彈幕架構圖
整個流程自下而上，分成算法側、服務端、用戶端三層：
- 首先，算法側按每秒 25 幀的頻率進行視訊抽幀，對每一幀進行人臉識别，配合人臉跟蹤和平滑處理，生成每一幀的人臉中繼資料；
- 其次，服務端将多個幀的人臉中繼資料通過降噪、防抖、合并後組合成一組組的人臉組資料，将該資料與跟随彈幕資料一起下發給用戶端；
- 最後，用戶端在互動 SDK 中将每組人臉資料生成一個腳本，腳本中完成彈幕跟随該人臉軌迹的移動而移動。
下面着重介紹下每個子產品或子子產品完成的任務：
1、算法側
- 1）視訊抽幀子產品：将視訊流按每秒 25 幀（可配置）的頻率抽幀。抽幀頻率越高，人臉移動軌迹越平滑，但後面人臉識别算法耗時也随之增加；
- 2）模型訓練子產品：提供多張多角度劇中出現的人物圖像，給模型訓練子產品來訓練，生成對應人臉庫，再配合已訓練完成的明星庫，這兩個庫可以大大提高人臉檢測的準确度；
- 3）人臉檢測：識别每一幀圖像中的人臉，并給出坐标；
- 4）人臉跟蹤：為友善服務端生成人臉的運動軌迹，需要把連續幾幀中的相同人臉标記出來；
- 5）平滑處理：由于每幀中識别出的人臉坐标有一定的偏移量，是以整段人臉軌迹中會出現抖動現象，平滑處理就是通過微調每幀人臉坐标讓整個人臉移動軌迹更平滑；
2、服務端
- 1）降噪：算法側不關心每一幀上到底哪張人臉重要或不重要，是以會有大量的路人臉是出現一秒不到就消失的，這種無意義的噪點需要直接過濾掉，即降噪處理；
- 2）防抖：如果算法側平滑處理未達到要求，人臉在運動過程中還是有抖動，服務端可以對中繼資料進行二次加工，讓人臉移動更平滑；
- 3）合并：算法側吐出的都是每一幀的中繼資料，但用戶端關心的是一張人臉由出現到消失的整個軌迹過程，服務端會把中繼資料合并成一組組人臉的軌迹資料，即人臉組資料；
- 4）氣泡彈幕資料：跟随彈幕的資料，每條彈幕都對應着一張人臉，也指定了彈幕開始展示的時刻。
3、用戶端
- 1）互動 SDK 子產品：加載各種互動腳本，每個腳本都是一個小的互動，比如電影評分、百科 tips、雙流酷看等。利用了互動 SDK 的基礎能力，這裡把每張人臉由出現到消失的整個過程當做一個小的互動腳本；
- 2）人臉腳本：人臉腳本中包含着該張人臉的軌迹坐标和對應該張人臉的彈幕氣泡資料，腳本中有個定時器在輪詢，查找着目前時刻對應人臉的坐标，如果該時刻有跟随彈幕資料則把該資料展示在人臉旁邊，繼續輪詢即達到了彈幕氣泡跟随人臉移動的效果。
二、為什麼不通過用戶端直接識别人臉？
1、實時觀看對于時間要求太高。
對于用戶端來說，最終需要知道的是一張張人臉由出現到消失整個軌迹過程，如果用戶端做識别，目前隻能識别到某一幀中人臉資料，追蹤、平滑處理、防抖、過濾、合并，這整個過程下來耗時太大，根本無法滿足使用者實時觀看的需求。
2、端側識别準确度達不到要求。
先前做彈幕穿人時，iOS 端接入過 AliNN 提供的 SDK，人臉檢測還是偶而出現未檢測到的情況，如果人臉檢測準确度上不能達到要求，必須自己做補幀處理，這個補幀處理很難做到實時。
3、端側識别影響使用者體驗。
端側識别時手機 cup 消耗增大，即耗電量會增大，同時可能也影響到播放器卡頓率。
三、棘手的問題
1、在即将切鏡頭時發跟随彈幕，如何停留的問題
使用者發彈幕的時刻恰好在人臉馬上消失的時刻（比如馬上要切鏡頭），這時由于人臉會馬上消失，而其它人臉會馬上出來，問題來了，如果為了保證使用者能看到自己發的彈幕，那這條跟随彈幕就需要強制在螢幕上停留幾秒，但就因為這幾秒鐘導緻切鏡頭後這條跟随彈幕很尴尬。測試同學回報說彈幕在切鏡頭後很奇怪，給人一種“天空飄來一句話”的感覺。
對這個問題，最終我們的解決辦法是切鏡頭前一刻發的跟随彈幕，在切鏡頭後直接跑漸隐效果，這樣即保證了使用者能看清自己的彈幕又保證不會尴尬地挂在下一個鏡頭的人臉上。視訊效果如下：
2、大劇熱綜頻繁剪輯導緻人臉資料時間軸錯亂的問題
我們知道一個視訊特别是綜藝上線後，會時不時地多次剪輯，一旦剪輯後，人臉資料和進度條時間會錯位，營運同學可能會給出一個大概時間比如在一分二十秒位置剪掉十秒這樣的資料，但人臉資料必須與進度條時間在毫秒級機關上對應，否則會出現明顯延遲或超前。如果重跑資料，可能需要幾個小時下線掉該功能（不能接受），如果要複用資料就必須知道精确的毫秒值，然後剪切部分之後的人臉及彈幕資料全部做偏移處理，是以問題就是如何擷取精确的剪切時長。
按照如下方式，隻需要跑新視訊剪切點前後一小段人臉資料，即可計算出剪切的毫秒級時間，然後将原視訊中在剪切點後的人臉資料及彈幕資料全部偏移對應時間即解決了資料錯位問題。
四、未來展望
劇中的人臉資料如果隻應用在跟随彈幕中就大材小用了，下一步我們準備把帶有人臉資料和人體資料的腳本做為基本腳本，後面除了跟随彈幕腳本，還會有彈幕穿人腳本等等。後續用戶端這部分架構可能會調整，見下圖。友善大家通過外部注入等方式，建構自己想要的腳本。
是以當你有了創新點子，也需要使用到人臉人體資料時，可以繼承自基本腳本拿到資料後直接定制自己想要的功能，借助成熟的優化過的人臉人體資料，快速地完成 demo。
比如 YY 一個場景，由于某些原因，需要給明星 A 所出現的鏡頭打上馬賽克，或下掉明星 A 參演的電影。下掉電影肯定不能接受，畢竟花了大價錢買版權；靠人工對大量鏡頭重新剪輯又不現實，這就到了考驗各視訊 APP 技術能力的時候了。我們借助互動 SDK 提供的能力，通過已經下發的人臉 ID 判斷出是明星 A 時給下發的人臉框打上馬賽克，問題就解決了。
原文連結：
https://www.infoq.cn/article/gOJNxhy5eF8zoKjfIpdw